From yaronf@checkpoint.com Mon Aug 3 12:37: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 D362B3A6E95 for ; Mon, 3 Aug 2009 12:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.463, 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 sTi9qgP+e8p0 for ; Mon, 3 Aug 2009 12:37:22 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7003A3A6E7F for ; Mon, 3 Aug 2009 12:37:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B353E200E09; Mon, 3 Aug 2009 22:37:41 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6F69E200409 for ; Mon, 3 Aug 2009 22:37:41 +0300 (IDT) X-CheckPoint: {4A773ACF-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 n73JbM3d002216 for ; Mon, 3 Aug 2009 22:37:22 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 3 Aug 2009 22:37:22 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 3 Aug 2009 22:37:19 +0300 Thread-Topic: IETF-75 meeting - draft minutes Thread-Index: AcoUcc/kw9gc15BsQHCOh+VD4g2Z5Q== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D03C@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_006B_01CA148A.F582E8C0" MIME-Version: 1.0 Subject: [IPsec] IETF-75 meeting - draft minutes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 03 Aug 2009 19:37:22 -0000 ------=_NextPart_000_006B_01CA148A.F582E8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have uploaded the minutes of last Monday's meeting, as taken by David Black and Rich Graveman. I'd like to thank them both. The minutes are available here: http://www.ietf.org/proceedings/75/minutes/ipsecme.txt (but not yet on the WG pages). I have done a bit of editing on the minutes, which makes me responsible for any errors :-) Please let me know if there are any. Thanks, Yaron ------=_NextPart_000_006B_01CA148A.F582E8C0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwMzE5MzcxOVowIwYJKoZIhvcNAQkEMRYEFP+acb6XQT1k NrNWkI+kL4oSqSIMMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Nl33ikdU9aP+tevUhJuWp1zEAr8jk6TybfpcXDV1p6CKrw3VSEkNQGeStb/l39SoAV2nv1YC5b4t jTXOpqMEfYfjNjUef6r86xpzkZW9h+z4I5/oV0M5QgXRKEL+Pi0e4zWRLSBfcqYJ6ag+y7UuRBo9 /dvAFYGuB5rDVZehBe4CLW1pwLbqZownXekE+NnZxvkB8uSRxKN9ydO/0q/y027Fu1xHnQkL7ZzJ NbJDcJGwrSTToCJn4gcYPqncewgTfwFqi1H/r2fsniBqe40WF5T9gMEMX84ghegsn/g1jb4eYwwG FZO8O5INTSUuZ+5CfvYPnCyb/RqgV6s/Q7P2uQAAAAAAAA== ------=_NextPart_000_006B_01CA148A.F582E8C0-- From root@core3.amsl.com Tue Aug 4 15:30:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 277773A6983; Tue, 4 Aug 2009 15: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: <20090804223002.277773A6983@core3.amsl.com> Date: Tue, 4 Aug 2009 15:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-13.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, 04 Aug 2009 22: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-13.txt Pages : 15 Date : 2009-08-04 IKEv2 is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension 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. 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-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-04151746.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Aug 6 10:15: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 BBDC33A6E26; Thu, 6 Aug 2009 10:15: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: <20090806171501.BBDC33A6E26@core3.amsl.com> Date: Thu, 6 Aug 2009 10:15:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 17:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-06.txt Pages : 14 Date : 2009-08-06 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-06100612.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Mon Aug 10 14:05: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 04D993A6881 for ; Mon, 10 Aug 2009 14:05: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=[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 t6RV4w2s2ofO for ; Mon, 10 Aug 2009 14:05:09 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 875923A6E39 for ; Mon, 10 Aug 2009 14:05:08 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CA2A729C004; Tue, 11 Aug 2009 00:05:31 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7E5F929C002 for ; Tue, 11 Aug 2009 00:05:31 +0300 (IDT) X-CheckPoint: {4A80898A-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 n7AL5A3d027179 for ; Tue, 11 Aug 2009 00:05:10 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 11 Aug 2009 00:05:10 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 11 Aug 2009 00:05:07 +0300 Thread-Topic: WG Last Call: draft-ietf-ipsecme-roadmap-03 Thread-Index: Acn84GccXdkwAkW2QlWsL8kxCqVagwdG+9MQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@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_0022_01CA1A17.62B80EC0" MIME-Version: 1.0 Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 10 Aug 2009 21:05:10 -0000 ------=_NextPart_000_0022_01CA1A17.62B80EC0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable This is the beginning of a two-week WG Last Call, which will end August = 24. The target status for this document is Informational (to obsolete RFC = 2411). The current document is at http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03. If you have not read the document before now, please do so. Having fresh eyes on the document often brings up important issues. This document is = very much a survey, so please also review it for completeness: are there documents that should be mentioned but aren't. Send any comments to the list, even if they are as simple as "I read it and it seems fine". Please clearly indicate the position of any issue in the Internet Draft, = and if possible provide alternative text. 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. Thanks, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yaron ------=_NextPart_000_0022_01CA1A17.62B80EC0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxMDIxMDUwN1owIwYJKoZIhvcNAQkEMRYEFDZuugSz1YhF DEJvtdKemkkbm+vXMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA MUxd4jfFGaE2fTiE6cL/z0QY1TfdYQsK22hsnQ+9kMYI32K1uLX16KMRGQbASSTn2fuxmZhXiURJ TdMIqPVmddHevV6oFtfrmCJEJPKBLFlA6+uuhP6hXCRvj4ohcwFHYc33tahs962bB1qSuk5P2Wm+ WKxn/wbJXtKQYPAJBDYrPTLFvYpHtCmTay/tyC8mNRYrIr2i/5v+736XE0ZfbvzQk+hLwdnKdVDT YHE1XGS0MqrSsVPjnK+PRkaeToNr4dLzbL+kSluB1HsZCmjagKHFqn9ArGf3PGCEylY/plzKm6TL S498gKnWYqftpyhlSnXG5nwvkrEHgbWWrqJVIAAAAAAAAA== ------=_NextPart_000_0022_01CA1A17.62B80EC0-- From root@core3.amsl.com Mon Aug 10 16: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 D0BF03A6E8C; Mon, 10 Aug 2009 16: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: <20090810234501.D0BF03A6E8C@core3.amsl.com> Date: Mon, 10 Aug 2009 16:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 23: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 : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-07.txt Pages : 14 Date : 2009-08-10 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-10164154.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Mon Aug 10 22:49: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 211D13A68EB for ; Mon, 10 Aug 2009 22:49:44 -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 s5iuqK9ppBdJ for ; Mon, 10 Aug 2009 22:49:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2BD353A69AF for ; Mon, 10 Aug 2009 22:49:38 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2271929C005; Tue, 11 Aug 2009 08:49:59 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C637829C004 for ; Tue, 11 Aug 2009 08:49:58 +0300 (IDT) X-CheckPoint: {4A810470-2-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7B5mV3f022264 for ; Tue, 11 Aug 2009 08:49:37 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 11 Aug 2009 08:48:34 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 11 Aug 2009 08:48:32 +0300 Thread-Topic: ipsecme virtual interim meeting Thread-Index: AcoaCzTgSCsMe5QpRjGyjkxGW4sbBQAO6kBA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A82C@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_0065_01CA1A60.816F7B70" MIME-Version: 1.0 Subject: [IPsec] ipsecme virtual 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: Tue, 11 Aug 2009 05:49:44 -0000 ------=_NextPart_000_0065_01CA1A60.816F7B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, As we announced in Stockholm, we will have a virtual interim WG meeting in September. We propose a conference call on Tuesday September 22, 15:00 GMT (18:00 Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Technical details here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls. Let us know in the next few days if you have any major issues with the time and/or the format. Thanks, Yaron ------=_NextPart_000_0065_01CA1A60.816F7B70 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxMTA1NDgzMlowIwYJKoZIhvcNAQkEMRYEFPL2Q5ISTjb2 MS1+eHgKlY8RcBtMMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA GQRgk9aJ3rkAxQ0eLAxvMnVG6kDM+GKfL/HLvbtxgp38iZ8TPD1ZAoPf7xvTWcoA8Ldh03S5iOva eTmgxy6ew9pq9a3m1fMtz5lWR4kR1bNB4vmszxZOibphjB8eyviFF0GgM1yBuEOMLhtxLA9UmMlr BtLnM42ztToLiu3hw8s9ADH2pLaEH4VpbLrswO3ax/Q96HEPAnutbecSZt2zNj62Twu/Q33mvF0U YahmsHLANyAzIXx8koSS0Hr8+gB6hL/x1ucP1KHlV+jFkt2s0Ok7g+GNwlmd9L4erWjRTRseYBYT sXEeqCH1PGXMdEPjzuM9qSSI/O60MBWMySldTwAAAAAAAA== ------=_NextPart_000_0065_01CA1A60.816F7B70-- From yaronf@checkpoint.com Tue Aug 11 06:04: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 CECDD3A70E9 for ; Tue, 11 Aug 2009 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7bb6quni3J0 for ; Tue, 11 Aug 2009 06:04:47 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 169203A715D for ; Tue, 11 Aug 2009 06:04:42 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E1C2F29C02D; Tue, 11 Aug 2009 16:04:08 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9B44229C008 for ; Tue, 11 Aug 2009 16:04:08 +0300 (IDT) X-CheckPoint: {4A816A2E-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 n7BD3l3d002403 for ; Tue, 11 Aug 2009 16:03:47 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 11 Aug 2009 16:03:47 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 11 Aug 2009 16:03:44 +0300 Thread-Topic: Relating the two ESP-null documents Thread-Index: AcoaCU7flAIQ2SPQSLGtPDsGLRShMgAO5ZnQAA+IIRA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@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_00BC_01CA1A9D.4D8B6890" MIME-Version: 1.0 Subject: [IPsec] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 11 Aug 2009 13:04:47 -0000 ------=_NextPart_000_00BC_01CA1A9D.4D8B6890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, As we near publication of the WESP and Heuristics drafts, we'd like to make sure that the WG consensus is clearly expressed in both documents. So we propose to include the following note as a section in both documents. Please let us know if this works for you: -- begin text Applicability: Heuristic Traffic Inspection and Wrapped ESP ----------------------------------------------------------- There are two ways to enable intermediate security devices to distinguish between encrypted and unencrypted ESP traffic: - The heuristics approach [heuristics I-D] has the intermediate node inspect the unchanged ESP traffic, to determine with extremely high probability whether or not the traffic stream is encrypted. - The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP endpoints to be modified to support the new protocol. WESP allows the intermediate node to distinguish encrypted and unencrypted traffic deterministically, using a simpler implementation for the intermediate node. Both approaches are being documented simultaneously by the IPsecME Working Group, with WESP being put on Standards Track while the heuristics approach is being published as an Informational RFC. While endpoints are being modified to adopt WESP, we expect both approaches to coexist for years, because the heuristic approach is needed to inspect traffic where at least one of the endpoints has not been modified. In other words, intermediate nodes are expected to support both approaches in order to achieve good security and performance during the transition period. -- end text [Note: both references are non-normative.] Currently both documents have direct or indirect references to one another, but they are not exactly in line with the consensus we have reached. In both cases the emphasis is on the two solutions competing with one another, rather than complementing each other. Thanks, Yaron ------=_NextPart_000_00BC_01CA1A9D.4D8B6890 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxMTEzMDM0NFowIwYJKoZIhvcNAQkEMRYEFMvWZqlc/6x6 5TPsgi9HE7Dy2UtcMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ezlTvmWEXPEe5aS2VFD4lakjh413nZ6yErSlbjI/FRMIEjLFkCd5eFNjxOkvCvVRn6u14hRmQNSm 0M5OlarEYZ3KvGG5nG8909p9g2si/W9fcM5cyZ8qd0T8/jclPbodTQyzhqTKUU4uMX6CTOZR+UEe w36He19/ZWU7UXDBcQY01VwJKSvP07o+/vi27NaBg+eAspVNcC4FHi9nDf/l1SabIc6PbUXrv3Uq 2UcyHTv8PGur1myfh0l3t8rpjsMrsW6OFhOUXrypGFh/4TNNSSkCO6l7OoGnwUuqf7kgJ0dVxL7e Z4LSg3wW55akXpJPNnITYU813xfU5fGPyFrORQAAAAAAAA== ------=_NextPart_000_00BC_01CA1A9D.4D8B6890-- From Nicolas.Williams@sun.com Wed Aug 12 12:55:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F253A6826 for ; Wed, 12 Aug 2009 12:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.232, 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 gza9dhmNNwsx for ; Wed, 12 Aug 2009 12:55:26 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id BC6193A67B7 for ; Wed, 12 Aug 2009 12:55:26 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7CJ7vXf000886 for ; Wed, 12 Aug 2009 19:07:57 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7CJ7vDp054933 for ; Wed, 12 Aug 2009 13:07:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7CIvJRo013131 for ; Wed, 12 Aug 2009 13:57:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CIvJF4013130 for ipsec@ietf.org; Wed, 12 Aug 2009 13:57:19 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 12 Aug 2009 13:57:19 -0500 From: Nicolas Williams To: ipsec@ietf.org Message-ID: <20090812185718.GJ10982@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Subject: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 12 Aug 2009 19:55:27 -0000 Over at BTNS WG we're wondering how hard it is for off-path attackers to cause a node to think that a peer is dead. We'd appreciate your input. See forwarded post. Thanks, Nico ----- Forwarded message from Nicolas Williams ----- Date: Wed, 12 Aug 2009 13:06:08 -0500 From: Nicolas Williams Subject: Re: [btns] Q: How to deal with connection latch breaks? To: Michael Richardson Cc: btns@ietf.org On Fri, Aug 07, 2009 at 12:36:16PM -0400, Michael Richardson wrote: > 2) system W's SA with system C expires (or is deleted by > INITIAL-CONTACT), and system W sees that has a broken latch. Just one clarification: "system W's SA with system C expires" does not mean that "system W sees that has a broken latch". That's because the current I-D says that latch breaks occur only as a result of conflicts; dead peer detection does not cause latch breaks. It might be useful to say that dead peer detection does cause latch breaks now that we have chosen to reset faster, so to speak. But I wouldn't want to have to specify any specific timeouts, or, really, any details of dead peer detection -- those would take time to work out. Fortunately we could leave those details to IKEv2 and just add that "if IKEv2 DPD concludes a given peer is dead then all latches with that peer SHOULD be transitioned to the BROKEN state". Possible wrinkle: - Is it possible for an off-path attacker to DoS IKEv2 between two peers? If so then we must not allow DPD to cause latch breaks! DNS poisoning is not an issue here, but ICMP redirects and ARP spoofing are. If you can spoof ARP you're on link, so that's not an issue. And ICMP redirects should be getting ignored. Any other ways to trigger IKEv2 DPD via an off-path attack? My preference: leave the text as-is on this; don't allow DPD to break latches, or perhaps allow it as a MAY, but not a SHOULD, much less a MUST. Rationale: a) there's a fairly strong distinction between "dead peer" and "SA/policy conflict", with the latter being an absolutely necessary cause of latch breaks while the former is not; b) it's easy to show that to cause such an SA conflict one must be on-path (or be able to spoof routing protocol updates) and policies must permit the conflict to arise (e.g., BTNS is in use), whereas it's harder to show the same for IKEv2 DPD -- we'd have to spend some time working that out; c) ULP/app timeout timers will generally result in DPD at the ULP/app layer anyways; d) we can always add DPD->latch break rules later if we need them, or we could let it be a MAY now and later upgrade it to SHOULD or even MUST if it proves useful. Nico -- _______________________________________________ btns mailing list btns@ietf.org https://www.ietf.org/mailman/listinfo/btns ----- End forwarded message ----- From ynir@checkpoint.com Wed Aug 12 23:34: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 308693A6950 for ; Wed, 12 Aug 2009 23:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6tpB5dznuOeH for ; Wed, 12 Aug 2009 23:34:44 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CE7CB3A69A3 for ; Wed, 12 Aug 2009 23:34:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8FA3C29C004; Thu, 13 Aug 2009 09:34:04 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3885429C002; Thu, 13 Aug 2009 09:34:04 +0300 (IDT) X-CheckPoint: {4A83B36B-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 n7D6Xg3d028373; Thu, 13 Aug 2009 09:33:43 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 13 Aug 2009 09:33:42 +0300 From: Yoav Nir To: "'Nicolas Williams'" , "ipsec@ietf.org" Date: Thu, 13 Aug 2009 09:33:41 +0300 Thread-Topic: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) Thread-Index: AcobhtzZTVc0ewjLQqeKW1FAILOzJQAWMutg Message-ID: <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> References: <20090812185718.GJ10982@Sun.COM> In-Reply-To: <20090812185718.GJ10982@Sun.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] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 06:34:45 -0000 Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as RFC = 4306 calls it, "liveness check"). These messages are very easy to spoof. But liveness check is just one round trip between the peers and it's suppos= ed to be rate-limited. I don't think an off-path attacker can cause the liv= eness check to fail. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of N= icolas Williams Sent: Wednesday, August 12, 2009 9:57 PM To: ipsec@ietf.org Subject: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: Ho= w to deal with connection latch breaks?]) Over at BTNS WG we're wondering how hard it is for off-path attackers to cause a node to think that a peer is dead. We'd appreciate your input. See forwarded post. Thanks, Nico ----- Forwarded message from Nicolas Williams --= --- Date: Wed, 12 Aug 2009 13:06:08 -0500 From: Nicolas Williams Subject: Re: [btns] Q: How to deal with connection latch breaks? To: Michael Richardson Cc: btns@ietf.org On Fri, Aug 07, 2009 at 12:36:16PM -0400, Michael Richardson wrote: > 2) system W's SA with system C expires (or is deleted by > INITIAL-CONTACT), and system W sees that has a broken latch. Just one clarification: "system W's SA with system C expires" does not mean that "system W sees that has a broken latch". That's because the current I-D says that latch breaks occur only as a result of conflicts; dead peer detection does not cause latch breaks. It might be useful to say that dead peer detection does cause latch breaks now that we have chosen to reset faster, so to speak. But I wouldn't want to have to specify any specific timeouts, or, really, any details of dead peer detection -- those would take time to work out. Fortunately we could leave those details to IKEv2 and just add that "if IKEv2 DPD concludes a given peer is dead then all latches with that peer SHOULD be transitioned to the BROKEN state". Possible wrinkle: - Is it possible for an off-path attacker to DoS IKEv2 between two peers? If so then we must not allow DPD to cause latch breaks! DNS poisoning is not an issue here, but ICMP redirects and ARP spoofing are. If you can spoof ARP you're on link, so that's not an issue. And ICMP redirects should be getting ignored. Any other ways to trigger IKEv2 DPD via an off-path attack? My preference: leave the text as-is on this; don't allow DPD to break latches, or perhaps allow it as a MAY, but not a SHOULD, much less a MUST. Rationale: a) there's a fairly strong distinction between "dead peer" and "SA/policy conflict", with the latter being an absolutely necessary cause of latch breaks while the former is not; b) it's easy to show that to cause such an SA conflict one must be on-path (or be able to spoof routing protocol updates) and policies must permit the conflict to arise (e.g., BTNS is in use), whereas it's harder to show the same for IKEv2 DPD -- we'd have to spend some time working that out; c) ULP/app timeout timers will generally result in DPD at the ULP/app layer anyways; d) we can always add DPD->latch break rules later if we need them, or we could let it be a MAY now and later upgrade it to SHOULD or even MUST if it proves useful. Nico --=20 _______________________________________________ btns mailing list btns@ietf.org https://www.ietf.org/mailman/listinfo/btns ----- End forwarded message ----- _______________________________________________ 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 Nicolas.Williams@sun.com Thu Aug 13 09:17: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 AE94128C0FF for ; Thu, 13 Aug 2009 09:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.195, 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 VeQsjV+pr4YW for ; Thu, 13 Aug 2009 09:17:03 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id B37E628C0FD for ; Thu, 13 Aug 2009 09:17:03 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DGFoEj001680 for ; Thu, 13 Aug 2009 16:15:50 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7DGFoRV059146 for ; Thu, 13 Aug 2009 10:15:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DFvZ7V013541; Thu, 13 Aug 2009 10:57:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DFvYT5013540; Thu, 13 Aug 2009 10:57:34 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 13 Aug 2009 10:57:34 -0500 From: Nicolas Williams To: Yoav Nir Message-ID: <20090813155734.GV10982@Sun.COM> References: <20090812185718.GJ10982@Sun.COM> <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 16:17:04 -0000 On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote: > Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as > RFC 4306 calls it, "liveness check"). These messages are very easy to > spoof. > > But liveness check is just one round trip between the peers and it's > supposed to be rate-limited. I don't think an off-path attacker can > cause the liveness check to fail. Thanks! That's all I needed. Nico -- From smoonen@us.ibm.com Thu Aug 13 11:09: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 97BB13A68D2 for ; Thu, 13 Aug 2009 11:09:52 -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 8fMKpsuM22zx for ; Thu, 13 Aug 2009 11:09:51 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 8E4F43A68C8 for ; Thu, 13 Aug 2009 11:09:51 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7DI5FY3029447 for ; Thu, 13 Aug 2009 12:05:15 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7DI9RHw139328 for ; Thu, 13 Aug 2009 12:09:31 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n7DIAPxq015026 for ; Thu, 13 Aug 2009 12:10:25 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n7DIAPYv015020 for ; Thu, 13 Aug 2009 12:10:25 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: F337DF79:1F094E37-85257611:0060AFD9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/13/2009 01:53:29 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/13/2009 01:53:29 PM, Serialize complete at 08/13/2009 01:53:29 PM, S/MIME Sign failed at 08/13/2009 01:53:29 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_07072009|July 07, 2009) at 08/13/2009 12:09:23, Serialize complete at 08/13/2009 12:09:23 Message-ID: Date: Thu, 13 Aug 2009 14:09:23 -0400 Content-Type: multipart/alternative; boundary="=_alternative 0062481885257611_=" Subject: [IPsec] AES-GCM IV length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 18:09:52 -0000 This is a multipart message in MIME format. --=_alternative 0062481885257611_= Content-Type: text/plain; charset="US-ASCII" RFC 4106 says: The AES-GCM-ESP IV field MUST be eight octets. NIST publication 800-38D says: For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design. There are no errata for RFC 4106, so I assume that ESP with ENCR-AES_GCM_nn uses an 8-byte IV. Unfortunately, this goes against the NIST recommendation and also prevents the use of the RBG-based IV construction method outlined in the NIST document (which requires a minimum IV length of 96 bits). Does anyone have any observations or comments on this? Is it correct that existing ESP AES_GCM implementations are using 128-bit IVs? Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 0062481885257611_= Content-Type: text/html; charset="US-ASCII"
RFC 4106 says:

   The AES-GCM-ESP IV field MUST be eight octets.

NIST publication 800-38D says:

  For IVs, it is recommended that implementations restrict support to
  the length of 96 bits, to promote interoperability, efficiency, and
  simplicity of design.

There are no errata for RFC 4106, so I assume that ESP with ENCR-AES_GCM_nn uses an 8-byte IV.  Unfortunately, this goes against the NIST recommendation and also prevents the use of the RBG-based IV construction method outlined in the NIST document (which requires a minimum IV length of 96 bits).

Does anyone have any observations or comments on this?  Is it correct that existing ESP AES_GCM implementations are using 128-bit IVs?

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 0062481885257611_=-- From sfluhrer@cisco.com Thu Aug 13 11:35: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 CD4493A69BF for ; Thu, 13 Aug 2009 11:35:17 -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 PLFKpSA+6vda for ; Thu, 13 Aug 2009 11:35:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C2D283A68D2 for ; Thu, 13 Aug 2009 11:35:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHf5g0qrR7MV/2dsb2JhbACCKC2ISrBUiCuREQWEGQ X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208,217";a="366854911" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2009 18:35:21 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7DIZLVt013197; Thu, 13 Aug 2009 11:35:21 -0700 Received: from sfluhrerwxp (stealth-10-32-244-84.cisco.com [10.32.244.84]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7DIZKxC029140; Thu, 13 Aug 2009 18:35:20 GMT From: "Scott Fluhrer" To: "'Scott C Moonen'" , References: Date: Thu, 13 Aug 2009 14:35:19 -0400 Message-ID: <04c701ca1c44$d03ad1b0$54f4200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C8_01CA1C23.492931B0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcocQUY3xLHMHW/ISaqOACI6wpevPAAAsn3A In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5830; t=1250188521; x=1251052521; 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]=20AES-GCM=20IV=20length |Sender:=20; bh=ZRbDJOkJh48f6weeJzwfcISaQJk7X36xjGi1ZFz4Hz8=; b=h8z/g0FTi4nkDxKCOkxiKpX+q929KU+AbTMCuPtHzjwM5xVGBD3MfpLh3H vfbPRm1LksyYHQqfurb+gUrbQmLbkQakGfdOI54VNKTjYPOfJs+p4lpxeV6d MNIEPJJaRt5gxxSeIA5mZPZoHM9g3WVew8aZVe20C0gja4UGGYj3k=; Authentication-Results: sj-dkim-1; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [IPsec] AES-GCM IV length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 18:35:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04C8_01CA1C23.492931B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen Sent: Thursday, August 13, 2009 2:09 PM To: ipsec@ietf.org Subject: [IPsec] AES-GCM IV length RFC 4106 says: The AES-GCM-ESP IV field MUST be eight octets. NIST publication 800-38D says: For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design. See section 4 of RFC 4106: there's also a 4 octet 'salt' which is negotiated (and fixed for a particular SA); the nonce (IV) that is passed to the underlying GCM primitive is made of the of the 4 octet salt concatenated with the 8 byte IV from the packet. This concatenated nonce is 96 bits in length, matching the above guideline... There are no errata for RFC 4106, so I assume that ESP with ENCR-AES_GCM_nn uses an 8-byte IV. Unfortunately, this goes against the NIST recommendation and also prevents the use of the RBG-based IV construction method outlined in the NIST document (which requires a minimum IV length of 96 bits). Does anyone have any observations or comments on this? Is it correct that existing ESP AES_GCM implementations are using 128-bit IVs? If they are, they are not following RFC 4106... Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen ------=_NextPart_000_04C8_01CA1C23.492931B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C=20 Moonen
Sent: Thursday, August 13, 2009 2:09 PM
To: = ipsec@ietf.org
Subject: [IPsec] AES-GCM IV=20 length


RFC 4106 says: =

   The AES-GCM-ESP IV field MUST = be eight=20 octets.

NIST = publication 800-38D=20 says:

  For IVs, = it is=20 recommended that implementations restrict support to
  the length of 96 bits, to promote=20 interoperability, efficiency, and
  simplicity of design. 
See section 4=20 of RFC 4106: there's also a 4 octet 'salt' which is negotiated (and = fixed for a=20 particular SA); the nonce (IV) that is passed to the underlying GCM = primitive is=20 made of the of the 4 octet salt concatenated with the 8 byte IV from the = packet.  This concatenated nonce is 96 bits in length, matching the = above=20 guideline...
 

There are no errata for RFC 4106, so I = assume that ESP=20 with ENCR-AES_GCM_nn uses an 8-byte IV.  Unfortunately, this goes = against=20 the NIST recommendation and also prevents the use of the RBG-based IV=20 construction method outlined in the NIST document (which requires a = minimum IV=20 length of 96 bits).

Does anyone=20 have any observations or comments on this?  Is it correct that = existing=20 ESP AES_GCM implementations are using 128-bit IVs? 
If they are,=20 they are not following RFC 4106...
 

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications = Server=20 TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen
= ------=_NextPart_000_04C8_01CA1C23.492931B0-- From andreas.steffen@strongswan.org Thu Aug 13 11:46: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 7C02E3A6D15 for ; Thu, 13 Aug 2009 11:46:42 -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 cqp9DYsf8gy7 for ; Thu, 13 Aug 2009 11:46:41 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 5917B28C131 for ; Thu, 13 Aug 2009 11:46:41 -0700 (PDT) Received: from [10.10.0.1] (koala.strongsec.com [10.10.0.1]) by strongswan.org (Postfix) with ESMTP id B470FEFA6A; Thu, 13 Aug 2009 20:46:41 +0200 (CEST) Message-ID: <4A845F91.9060100@strongswan.org> Date: Thu, 13 Aug 2009 20:46:41 +0200 From: Andreas Steffen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Scott Fluhrer References: <04c701ca1c44$d03ad1b0$54f4200a@amer.cisco.com> In-Reply-To: <04c701ca1c44$d03ad1b0$54f4200a@amer.cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] AES-GCM IV length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 18:46:42 -0000 Yes, this is correct: 4 octets of salt are derived the IKEv2 SKEYSEED, so they don't have to be transmitted and 8 octets is the size of the actual IV prepended to the encrypted ESP payload. Together with the 4 octet counter a 128 bit block input is formed for the AES block cipher using the 128 bit output as a stream cipher. Regards Andreas Scott Fluhrer wrote: > > > ------------------------------------------------------------------------ > *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On > Behalf Of *Scott C Moonen > *Sent:* Thursday, August 13, 2009 2:09 PM > *To:* ipsec@ietf.org > *Subject:* [IPsec] AES-GCM IV length > > > RFC 4106 says: > > The AES-GCM-ESP IV field MUST be eight octets. > > NIST publication 800-38D says: > > For IVs, it is recommended that implementations restrict support to > the length of 96 bits, to promote interoperability, efficiency, and > simplicity of design. > > See section 4 of RFC 4106: there's also a 4 octet 'salt' which is > negotiated (and fixed for a particular SA); the nonce (IV) that is > passed to the underlying GCM primitive is made of the of the 4 octet > salt concatenated with the 8 byte IV from the packet. This concatenated > nonce is 96 bits in length, matching the above guideline... > > > > There are no errata for RFC 4106, so I assume that ESP with > ENCR-AES_GCM_nn uses an 8-byte IV. Unfortunately, this goes against > the NIST recommendation and also prevents the use of the RBG-based > IV construction method outlined in the NIST document (which requires > a minimum IV length of 96 bits). > > Does anyone have any observations or comments on this? Is it > correct that existing ESP AES_GCM implementations are using 128-bit > IVs? > > If they are, they are not following RFC 4106... > > > > Thanks, > > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://scott.andstuff.org/ > http://www.linkedin.com/in/smoonen ====================================================================== 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 Nicolas.Williams@sun.com Thu Aug 13 14:55: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 76A6B3A6CAD for ; Thu, 13 Aug 2009 14:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.178, 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 qE88wdK7g4PG for ; Thu, 13 Aug 2009 14:55:47 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id AD93A3A6971 for ; Thu, 13 Aug 2009 14:55:47 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DLtp72027183 for ; Thu, 13 Aug 2009 21:55:51 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7DLtpOJ012610 for ; Thu, 13 Aug 2009 15:55:51 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DLbi8k013749; Thu, 13 Aug 2009 16:37:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DLbhOI013748; Thu, 13 Aug 2009 16:37:43 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 13 Aug 2009 16:37:43 -0500 From: Nicolas Williams To: Yoav Nir Message-ID: <20090813213743.GE10982@Sun.COM> References: <20090812185718.GJ10982@Sun.COM> <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 21:55:48 -0000 On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote: > Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as > RFC 4306 calls it, "liveness check"). These messages are very easy to > spoof. Also, my reading of RFC4306 is that unprotected INVALID_IKE_SPI or INVALID_SPI messages can trigger DPD, but the ensuing liveness check should be cryptographically protected. Can you confirm? From julienl@qualcomm.com Thu Aug 13 16:57: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 9020628C131 for ; Thu, 13 Aug 2009 16:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.716 X-Spam-Level: X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78F+Gv4WEuPw for ; Thu, 13 Aug 2009 16:57:24 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A332628C0D0 for ; Thu, 13 Aug 2009 16:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1250207849; x=1281743849; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Nicolas=20Williams=20, =0D=0A=20=20=20=20=20=20=20=20Yoav=20Nir=0D=0A=09|CC:=20"ipsec@ietf.org"=20 |Date:=20Thu,=2013=20Aug=202009=2016:57:23=20-0700 |Subject:=20RE:=20[IPsec]=20Can=20off-path=20attackers=20 trigger=20DPD=20([FWD:=20Re:=20[btns]=20Q:=0D=0A=09How=09 to=20deal=20with=20connection=20latch=20breaks?]) |Thread-Topic:=20[IPsec]=20Can=20off-path=20attackers=20t rigger=20DPD=20([FWD:=20Re:=20[btns]=0D=0A=20Q:=09How=09t o=20deal=20with=20connection=20latch=20breaks?]) |Thread-Index:=20AcocYNl7MZoUwBR9SIa4B9RnGUIM9gAEL9bQ |Message-ID:=20|References:=20<20090812185 718.GJ10982@Sun.COM>=0D=0A=09<006FEB08D9C6444AB014105C9AE B133F906D312AA9@il-ex01.ad.checkpoint.com>=0D=0A=20<20090 813213743.GE10982@Sun.COM>|In-Reply-To:=20<20090813213743 .GE10982@Sun.COM>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5708"=3B=20a=3D"22093778"; bh=X9hnSvvlt2t3tfmcZQZlJboWwZTUjxCAglHoy1kYlvg=; b=EQTif1oUC2TWRz0dyY7nLm1gG957w4DGeMVqXkX/tOJLvyctxnCpJoOv X8WennMaObFqaFabvL48jN1KpMflXFxLH1f0J+zVQ2zzIZN5lwLdIT8Dz ml7/dfKq2AtPnSVXl5JFl665V4lSqq1hyWO9BcSLfClzHVRVN1aqbVXPt g=; X-IronPort-AV: E=McAfee;i="5300,2777,5708"; a="22093778" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Aug 2009 16:57:29 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7DNvSoJ026316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2009 16:57:28 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7DNvPLN027966 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Aug 2009 16:57:26 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 13 Aug 2009 16:57:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 13 Aug 2009 16:57:25 -0700 From: "Laganier, Julien" To: Nicolas Williams , Yoav Nir Date: Thu, 13 Aug 2009 16:57:23 -0700 Thread-Topic: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) Thread-Index: AcocYNl7MZoUwBR9SIa4B9RnGUIM9gAEL9bQ Message-ID: References: <20090812185718.GJ10982@Sun.COM> <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> <20090813213743.GE10982@Sun.COM> In-Reply-To: <20090813213743.GE10982@Sun.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" Subject: Re: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 13 Aug 2009 23:57:25 -0000 Nicolas Williams wrote: > Sent: Thursday, August 13, 2009 2:38 PM > To: Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: > [btns] Q: How to deal with connection latch breaks?]) >=20 > On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote: > > Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, > as > > RFC 4306 calls it, "liveness check"). These messages are very easy to > > spoof. >=20 > Also, my reading of RFC4306 is that unprotected INVALID_IKE_SPI or > INVALID_SPI messages can trigger DPD, but the ensuing liveness check > should be cryptographically protected. Can you confirm? FWIW this is what I understand as well from the RFC4306 excerpt below: Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its CHILD_SAs. --julien From Pasi.Eronen@nokia.com Fri Aug 14 02:23: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 9115C3A689E for ; Fri, 14 Aug 2009 02:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 plGckRK8seyP for ; Fri, 14 Aug 2009 02:23:36 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4852B3A67B5 for ; Fri, 14 Aug 2009 02:23:35 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7E8dvpu003638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Aug 2009 11:39:58 +0300 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7E8acpx001532 for ; Fri, 14 Aug 2009 11:36:41 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 11:36:46 +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, 14 Aug 2009 11:36:23 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 14 Aug 2009 10:36:13 +0200 From: "Pasi.Eronen@nokia.com" To: Date: Fri, 14 Aug 2009 10:36:12 +0200 Thread-Topic: AD review comments for draft-ietf-ipsecme-ikev2-resumption Thread-Index: Acocukd09TOCj3jjQhmhV9FEPu8dUg== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A724C955D@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: 14 Aug 2009 08:36:23.0358 (UTC) FILETIME=[4E1E3DE0:01CA1CBA] X-Nokia-AV: Clean Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 09:23:37 -0000 I've now done my AD review for draft-ietf-ipsecme-ikev2-resumption-06. Most of my comments are about clarifying text (so that readers who didn't participate in the WG discussions can understand this unambiguously), plus couple of nits.=20 Yaron and Hannes, could you post a new version addressing these comments before we start IETF Last Call? - The document uses the terms "ticket by value" and "ticket by reference", but never really explains what those mean. Perhaps 4th paragraph of Section 1 could be rephrased something like this? The client (IKEv2 initiator) stores the state about the previous IKE SA locally. The gateway (IKEv2 responder) has two options for maintaining the IKEv2 state about the previous IKE SA: o In "ticket by reference" approach, the gateway stores the state locally, and gives the client an opaque reference (e.g., an index to the gateway's table) that the gateway can later use to find the state. The client includes this opaque reference when it resumes the session. o In "ticket by value", the gateway stores its state in a ticket (data structure) that is encrypted and integrity-protected by a key known only to the gateway. The ticket is passed to the client (who treats the ticket as an opaque string), and sent back to the gateway when the session is resumed. The gateway can then=20 decrypt the ticket and recover the state. Note that the client behaves identically in both cases, and in general, does not know which approach the gateway is using. Since the ticket (or reference) is only interpreted by the same party that created it, this document does not specify the exact format for it. However, Appendix A contains examples for both "ticket by reference" and "ticket by value" formats. - Section 4.3.2 talks about setting SPIi or SPIr "to a random value". Probably this should be "to a new (unused) SPI value" or something, since it's perfectly OK to use non-random SPIs (e.g. if you support maximum five simultaneous IKE_SAs, the SPI could be just index 1..5=20 to your local table). - Section 5, "compiled by Pasi Eronen" -- this kind of stuff belongs in the "Acknoledgements" section, not in the main text (but my name is already there). - Section 5: Peer vendor IDs cannot be "implementation specific" -- if the old gateway sent Vendor ID "FOO", the client has to unambiguously know whether it's allowed to FOO vendor-specific payloads to the new gateway or not. Probably this should be "Not resumed, Vendor ID payloads are resent in new exchange if required". - Section 8 is not very clear about what IANA is asked to do. Suggested text: "Section 7 defines several new IKEv2 notifications whose values are to be allocated (have been allocated) from the "IKEv2 Notify Message Types - Status Types" registry. Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME, whose value is to be allocate (has been allocated) from the "IKEv2 Exchange Types" registry." - Section A.1 should say that the notation used for the example ticket formats is intended to be pseudo-code, and does not specify exact octet-by-octet format. (And probably things like "reserved[3]" should be removed, since they don't really belong in pseudo-code like this.) Best regards, Pasi From kivinen@iki.fi Fri Aug 14 04:12:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD623A67B5 for ; Fri, 14 Aug 2009 04:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 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 5vmYTXp25Dih for ; Fri, 14 Aug 2009 04:11:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFF73A6765 for ; Fri, 14 Aug 2009 04: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 n7E9cFoX013919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 12:38:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7E9cEqI002771; Fri, 14 Aug 2009 12:38:14 +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: <19077.12422.575220.652961@fireball.kivinen.iki.fi> Date: Fri, 14 Aug 2009 12:38:14 +0300 From: Tero Kivinen To: Nicolas Williams In-Reply-To: <20090813213743.GE10982@Sun.COM> References: <20090812185718.GJ10982@Sun.COM> <006FEB08D9C6444AB014105C9AEB133F906D312AA9@il-ex01.ad.checkpoint.com> <20090813213743.GE10982@Sun.COM> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 14 Aug 2009 11:12:00 -0000 Nicolas Williams writes: > On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote: > > Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as > > RFC 4306 calls it, "liveness check"). These messages are very easy to > > spoof. > > Also, my reading of RFC4306 is that unprotected INVALID_IKE_SPI or > INVALID_SPI messages can trigger DPD, Yes. As can sending ESP packets with unknown SPI or sending ICMP host/protocol unreachable etc... I.e. if other end feels that the other end might not be there because it receives some messages from the net which would give that kind of hints, it trigger DPD. > but the ensuing liveness check > should be cryptographically protected. Can you confirm? The actual DPD is cryptographically protected, and will cause the IKE/IPsec SAs to be deleted only after "It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules." (from 4306). -- kivinen@iki.fi From emreertekin.ietf@gmail.com Fri Aug 14 14:54: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 9550D3A6C89 for ; Fri, 14 Aug 2009 14:54:25 -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 WtABPZ2nmnNS for ; Fri, 14 Aug 2009 14:54:24 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id 1D2F428C1D6 for ; Fri, 14 Aug 2009 14:54:01 -0700 (PDT) Received: by yxe3 with SMTP id 3so2454090yxe.29 for ; Fri, 14 Aug 2009 14:54:00 -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=C2CCOxt5bF5MIY8WNjlUo7ePV0kmzm0f+drUS0wvZ3U=; b=H5FLxUTw0AkSg0YXUkpO2CyPCIjuRZpHptEcUBEhn7OBUQZJHB0CBOkP8PwiFb5+Fm LPi4hLLh8wzPxF+PQ31gQKxIXMoEvVYLPwhRv1CF/6H/Br/inseGbuHuV85IIhVBJpXM OAG2ZXNGH97tN8NmNmvF2PFcDOklkthyY8fSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Yl33AAHwJepuWKOiZlcZo2BdR1tXyEQ+ynqpsVzYJCLhWFasGd70ara8G1y+6fz4a0 FUAviZBokYS2IYAvXwmfd141nHSwe4p7cSjSqRUqXQiy8fhzMbU4Wzx3MswdgZ3IuZGF YjvGJZXWfKW1U9wOkJwVkk6Ly5Clt//6gxvHI= MIME-Version: 1.0 Received: by 10.101.80.3 with SMTP id h3mr2114429anl.65.1250286840109; Fri, 14 Aug 2009 14:54:00 -0700 (PDT) Date: Fri, 14 Aug 2009 14:54:00 -0700 Message-ID: From: Emre Ertekin To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636ed6dc5f8d9920471211699 Subject: [IPsec] Comment/Request on IKEv2bis Draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 14 Aug 2009 21:56:21 -0000 --001636ed6dc5f8d9920471211699 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, One comment/request on the IKEv2bis draft. One of the differences between RFC 4306 and the IKEv2bis draft is in Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the IKEv2bis draft indicates the following: In Section 2.17, removed "If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet" because multiple IPsec protocols cannot be negotiated at one time. Is it possible to leave the quoted text in the spec? I agree that multiple IPsec protocols cannot be negotiated at one time; however, the text is useful for ROHCoIPsec implementers, where multiple keys may need to be generated for a ROHC-enabled Child SA. For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec encryption/authentication keying material will be taken, then an additional key will be taken for the algorithm used to verify the proper decompression of packet headers. BR, Emre --001636ed6dc5f8d9920471211699 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,

=A0

One comment/request on the IKEv2bis draft.

=A0

One of the differences between RFC 4306 and the I= KEv2bis draft is in Section 2.17, Generating Key Material for Child SAs.=A0 Appendix E.2 of the IKEv2bis draft indicates the following:

=A0

=A0=A0 In Section 2.17, removed "If multiple IPsec protocols are negotiated,

=A0=A0 keying material is taken in the order in which the protocol headers

=A0=A0 will appear in the encapsulated packet" because multiple IPsec

=A0=A0 protocols cannot be negotiated at one time.

=A0

Is it possible to leave the quoted text in the sp= ec?=A0 I agree that multiple IPsec protocols cannot be negotiated at one time; however, the text is useful for ROHCoIPsec implementers, where multiple keys may need to be generated for a ROHC-enabl= ed Child SA.=A0

=A0

For example, if a ROHC-enabled Child-SA with ROHC= _INTEG [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the I= Psec encryption/authentication keying material will be taken, then an additional= key will be taken for the algorithm used to verify the proper decompression of = packet headers.

=A0

BR,

Emre

--001636ed6dc5f8d9920471211699-- From yaronf@checkpoint.com Sat Aug 15 02:52: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 C873128C223 for ; Sat, 15 Aug 2009 02:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WuGQSLJk2Npk for ; Sat, 15 Aug 2009 02:52:37 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5D3CB28C219 for ; Sat, 15 Aug 2009 02:52:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B543B200E09; Sat, 15 Aug 2009 12:52:57 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 64947200360; Sat, 15 Aug 2009 12:52:57 +0300 (IDT) X-CheckPoint: {4A8684E1-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 n7F9qZ3d028911; Sat, 15 Aug 2009 12:52:35 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 15 Aug 2009 12:52:35 +0300 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Sat, 15 Aug 2009 12:52:32 +0300 Thread-Topic: AD review comments for draft-ietf-ipsecme-ikev2-resumption Thread-Index: Acocukd09TOCj3jjQhmhV9FEPu8dUgAzjApA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120ADAB@il-ex01.ad.checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A724C955D@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_0296_01CA1DA7.41286230" MIME-Version: 1.0 Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 09:52:37 -0000 ------=_NextPart_000_0296_01CA1DA7.41286230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pasi, Thanks for the useful comments. I'm OK with all of them, except for the last one: > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Friday, August 14, 2009 11:36 > To: ipsec@ietf.org > Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2- > resumption > [snip] > > - Section A.1 should say that the notation used for the example ticket > formats is intended to be pseudo-code, and does not specify exact > octet-by-octet format. (And probably things like "reserved[3]" should > be removed, since they don't really belong in pseudo-code like this.) > This is an example only, but it can still be precise. It *does* specify an octet-by-octet format, except you're free to implement something else, or change whatever you feel like. In general, I think an implementer is better off starting from a precise definition than from a vague pseudo-code description. So, I propose to change the section preamble to: This document does not specify a mandatory-to-implement or a mandatory-to-use ticket format. The formats described in the following sub-sections are provided as useful examples, and implementers are free to adopt them as-is on change them in any way necessary. Thanks, Yaron ------=_NextPart_000_0296_01CA1DA7.41286230 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxNTA5NTIzMlowIwYJKoZIhvcNAQkEMRYEFH5d8QY50YJW Dwy7bS/f5a8YgHonMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA n7gIyHaAjjjVI4vKD0CJyPX9dEOV9GZ+I9T3PEBkHpk5pnTJIqb6dipMTUib5OfIFNXdpDEYCksp jk43f1Qtx3GL1WqOuHrpi/qk/4A8VePll28CQISfDP/KURdk5pzu3+dDA1mNGjhdqUHm7+2bIH2u KOMY/omnyIuyMwtiTQKxDbiw2kiBbcLcaz+hTWqASRPIlbwlB3ez28ukuRQVDty3hrb4MMVBUJNM 6EZjvW9ioRItreEuDkhkbw9CTgq6tsAkiVLsU4zO6plHP6j42N97XPq5RcpB1CkCzVlDGveNE4dn LXAD6OdSzsrf2BdtHT7kJABie60bmL6HHvx2/wAAAAAAAA== ------=_NextPart_000_0296_01CA1DA7.41286230-- From kent@bbn.com Sat Aug 15 13:11: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 39FEC3A6B62 for ; Sat, 15 Aug 2009 13:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Lqb+UVA0h3Oh for ; Sat, 15 Aug 2009 13:11:50 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9C62F3A68E4 for ; Sat, 15 Aug 2009 13:11:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.2]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1McOfN-0004dH-Fe; Sat, 15 Aug 2009 15:11:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120ADAB@il-ex01.ad.checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120ADAB@il-ex01.ad.checkpoint.com> Date: Sat, 15 Aug 2009 15:33:12 -0400 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 20:11:51 -0000 At 12:52 PM +0300 8/15/09, Yaron Sheffer wrote: >C >This document does not specify a mandatory-to-implement or a >mandatory-to-use ticket format. The formats described in the following >sub-sections are provided as useful examples, and implementers are free to >adopt them as-is on change them in any way necessary. > I though the agreement was that the ticket content, as well as format, was entirely up to the implementer. If so, the text above is misleading, as it suggests that the content is prescribed and only the format is up for grabs. Steve From paul.hoffman@vpnc.org Sat Aug 15 18:03: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 12AB73A6B54 for ; Sat, 15 Aug 2009 18:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 h3ABYUFNpt3W for ; Sat, 15 Aug 2009 18:03:47 -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 CD3F73A6900 for ; Sat, 15 Aug 2009 18:03:42 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7G13UE0097946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Aug 2009 18:03:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120ADAB@il-ex01.ad.checkpoint.com> Date: Sat, 15 Aug 2009 18:03:29 -0700 To: Stephen Kent , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 01:03:48 -0000 At 3:33 PM -0400 8/15/09, Stephen Kent wrote: >At 12:52 PM +0300 8/15/09, Yaron Sheffer wrote: >>C >>This document does not specify a mandatory-to-implement or a >>mandatory-to-use ticket format. The formats described in the following >>sub-sections are provided as useful examples, and implementers are free to >>adopt them as-is on change them in any way necessary. >> > >I though the agreement was that the ticket content, as well as format, was entirely up to the implementer. If so, the text above is misleading, as it suggests that the content is prescribed and only the format is up for grabs. I disagree that the text suggests that the content is prescribed, but agree that this is a good place to remind the reader that the content is also implementation-specific. Proposed change: This document does not specify a particular ticket format nor even the suggested contents of a ticket: both are entirely up to the implementer. The formats described in the following ... --Paul Hoffman, Director --VPN Consortium From Pasi.Eronen@nokia.com Mon Aug 17 00:59: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 5CB273A6B77 for ; Mon, 17 Aug 2009 00:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 Aw0b7rcAPWuG for ; Mon, 17 Aug 2009 00:59:29 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CBE703A6C2C for ; Mon, 17 Aug 2009 00:58:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7H7wWiP031218; Mon, 17 Aug 2009 02:58:33 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 10:58:07 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 10:58:07 +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); Mon, 17 Aug 2009 10:57:53 +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; Mon, 17 Aug 2009 09:57:52 +0200 From: To: , Date: Mon, 17 Aug 2009 09:57:51 +0200 Thread-Topic: AD review comments for draft-ietf-ipsecme-ikev2-resumption Thread-Index: Acocukd09TOCj3jjQhmhV9FEPu8dUgAzjApAAGHhZUA= Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72E285C4@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120ADAB@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120ADAB@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: 17 Aug 2009 07:57:53.0751 (UTC) FILETIME=[6CB96E70:01CA1F10] X-Nokia-AV: Clean Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 07:59:30 -0000 Yaron Sheffer wrote: > > - Section A.1 should say that the notation used for the example > > ticket formats is intended to be pseudo-code, and does not specify > > exact octet-by-octet format. (And probably things like > > "reserved[3]" should be removed, since they don't really belong in > > pseudo-code like this.) > > >=20 > This is an example only, but it can still be precise. It *does* > specify an octet-by-octet format, except you're free to implement > something else, or change whatever you feel like. In general, I > think an implementer is better off starting from a precise > definition than from a vague pseudo-code description. The text never specifies how e.g. "opaque state_ref" would be encoded (e.g. if it's variable length, there's probably some kind of length field somewhere), so IMHO it does not specify octet-by-octet format (two persons reading this would very likely end up with different octets). Best regards,=20 Pasi From Pasi.Eronen@nokia.com Mon Aug 17 03:56:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A34528C251 for ; Mon, 17 Aug 2009 03:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 aia5E5iK-kYn for ; Mon, 17 Aug 2009 03:56:05 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1B98728C114 for ; Mon, 17 Aug 2009 03:56:04 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7HAtgIu017417; Mon, 17 Aug 2009 13:55:55 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 13:55:49 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 13:55:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 13:55:35 +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; Mon, 17 Aug 2009 12:55:30 +0200 From: To: , Date: Mon, 17 Aug 2009 12:55:29 +0200 Thread-Topic: [IPsec] Comment/Request on IKEv2bis Draft Thread-Index: AcodKhsh/sQrKD5RR06hDvS37AdAHQB/hZVA Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72E287F0@NOK-EUMSG-01.mgdnok.nokia.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Aug 2009 10:55:35.0431 (UTC) FILETIME=[3F94B170:01CA1F29] X-Nokia-AV: Clean Subject: Re: [IPsec] Comment/Request on IKEv2bis Draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 17 Aug 2009 10:56:06 -0000 The original text in RFC 4306 was slightly confusing, but I think we should leave room for ROHCoIPsec here. Perhaps adding something like this after the bulleted list? If the Child SA negotiation includes some future IPsec protocol(s) in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then (1) all keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction, and (2) keying material for the IPsec protocols are taken in the order in which the protocol headers will appear in the encapsulated packet. Best regards, Pasi=20 (not wearing any hats) > -----Original Message----- > From: Emre Ertekin > Sent: 15 August, 2009 00:54 > To: ipsec@ietf.org > Subject: [IPsec] Comment/Request on IKEv2bis Draft > Hi All, > =A0 > One comment/request on the IKEv2bis draft. >=20 > > One of the differences between RFC 4306 and the IKEv2bis draft is in > Section 2.17, Generating Key Material for Child SAs.=A0 Appendix E.2 > of the IKEv2bis draft indicates the following: > >=A0=A0 In Section 2.17, removed "If multiple IPsec protocols are > negotiated, keying material is taken in the order in which the > protocol headers will appear in the encapsulated packet" because > multiple IPsec protocols cannot be negotiated at one time. >=A0 > Is it possible to leave the quoted text in the spec?=A0 I agree that > multiple IPsec protocols cannot be negotiated at one time; however, > the text is useful for ROHCoIPsec implementers, where multiple keys > may need to be generated for a ROHC-enabled Child SA.=A0 > > For example, if a ROHC-enabled Child-SA with ROHC_INTEG > [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, > first the IPsec encryption/authentication keying material will be > taken, then an additional key will be taken for the algorithm used > to verify the proper decompression of packet headers. > =A0 > BR, > Emre From kivinen@iki.fi Mon Aug 17 04:33: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 4807E28C2D1 for ; Mon, 17 Aug 2009 04:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lJkpmmNz4K1 for ; Mon, 17 Aug 2009 04:33:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9442528C2C3 for ; Mon, 17 Aug 2009 04:33:31 -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 n7HBXVoo003969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 14:33:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7HBXUSo016410; Mon, 17 Aug 2009 14:33:30 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19081.16394.715433.157178@fireball.kivinen.iki.fi> Date: Mon, 17 Aug 2009 14:33:30 +0300 From: Tero Kivinen To: "Pasi.Eronen@nokia.com" In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:33:33 -0000 Pasi.Eronen@nokia.com writes: > - Section 5: Peer vendor IDs cannot be "implementation specific" -- if > the old gateway sent Vendor ID "FOO", the client has to unambiguously > know whether it's allowed to FOO vendor-specific payloads to the new > gateway or not. Probably this should be "Not resumed, Vendor ID > payloads are resent in new exchange if required". As we are resuming back to the same GW (failover from one GW to another was specific non-goal for this document), I think we can safely assume that GW support exactly same vendor IDs which it did last time we connected it (or if the GW version was changed and support for some vendor IDs were removed, then resumption tickets were also invalidated). So in this case the "implementation specific" is quite ok. I.e if server and client support extension "FOO" indicated by vendor ID "FOO", which requires some external data to be stored, then that information that "FOO" was supported and that information was stored to ticket needs to be stored to ticket. If the extension "FOO" does not need any data to be stored across the resumptions, then there is no need to modify ticket, thus there is not really need to store information whether "FOO" was supported in the first place or not. Then there is this second case whether client is allowed to "remember" that gateway supported extension "FOO" without sending any Vendor ID payloads, or whether they need to be resent. I think we should require them to be resent, as you said there. But there is still cases where ticket might need to store extra information depending whether vendor ID was originally used or not. So I think we need two separate cases one for "Supported Vendor IDs" which is "Not resumed, Vendor ID payloads are resent in new exchange if required", and some kind of "Vendor ID specific data", which is "Implementation specific (needed in ticket only, if vendor-specific state is required)". BTW, the table would be much more readable if there would be some kind of separators between items, i.e. change to be: +------------------------------------+------------------------------+ | State Item | After Resumption | +------------------------------------+------------------------------+ | IDi | From the ticket (but must | | | also be exchanged in | | | IKE_AUTH). See also Note 1 | +------------------------------------+------------------------------+ | IDr | From the ticket (but must | | | also be exchanged in | | | IKE_AUTH) | +------------------------------------+------------------------------+ | Authentication method (PKI, | From the ticket | | pre-shared secret, EAP, PKI-less | | | EAP | | | [I-D.eronen-ipsec-ikev2-eap-auth] | | | etc.) | | +------------------------------------+------------------------------+ | Certificates (when applicable) | From the ticket, see Note 2 | +------------------------------------+------------------------------+ | Local IP address/port, peer IP | Selected by the client, see | | address/port | Note 3 | +------------------------------------+------------------------------+ | NAT detection status | From new exchange | +------------------------------------+------------------------------+ | SPIs | From new exchange, see Note | | | 4 | +------------------------------------+------------------------------+ | Which peer is the "original | Determined by the initiator | | initiator"? | of IKE_SESSION_RESUME | +------------------------------------+------------------------------+ | IKE SA sequence numbers (Message | Reset to 0 in | | ID) | IKE_SESSION_RESUME, and | | | subsequently incremented | | | normally | +------------------------------------+------------------------------+ | IKE SA algorithms (SAr) | From the ticket | +------------------------------------+------------------------------+ | IKE SA keys (SK_*) | The old SK_d is obtained | | | from the ticket and all keys | | | are refreshed, see | | | Section 5.1 | +------------------------------------+------------------------------+ | IKE SA window size | Reset to 1 | +------------------------------------+------------------------------+ | Child SAs (ESP/AH) | Created in new exchange, see | | | Note 7 | +------------------------------------+------------------------------+ | Internal IP address | Not resumed, but see Note 5 | +------------------------------------+------------------------------+ | Other Configuration Payload | Not resumed | | information | | +------------------------------------+------------------------------+ | Peer vendor IDs | Implementation specific | | | (needed in the ticket only | | | if vendor-specific state is | | | required) | +------------------------------------+------------------------------+ | Peer supports MOBIKE [RFC4555] | From new exchange | +------------------------------------+------------------------------+ | MOBIKE additional addresses | Not resumed, should be | | | resent by client if | | | necessary | +------------------------------------+------------------------------+ | Time until re-authentication | From new exchange (but | | [RFC4478] | ticket lifetime is bounded | | | by this duration) | +------------------------------------+------------------------------+ | Peer supports redirects | From new exchange | | [I-D.ietf-ipsecme-ikev2-redirect] | | +------------------------------------+------------------------------+ Also it is bit funny that there is notes 6 and 8, which are not referenced anywhere. As those are generic rules for processing data not covered explictly here, it might be better to make them separate paragraph after the table, instead of hiding such important information to the non-referenced notes. There is also missing closing parenthesis in the end of section 3, i.e. change Moreover, this document requires the client to destroy the ticket when the user explicitly "logs out" (Section 6.2. to Moreover, this document requires the client to destroy the ticket when the user explicitly "logs out" (Section 6.2). -- kivinen@iki.fi From kivinen@iki.fi Mon Aug 17 04:43: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 D46D83A6B8E for ; Mon, 17 Aug 2009 04:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_12=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 FKfj1mAZzRPI for ; Mon, 17 Aug 2009 04:43:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A58B228C114 for ; Mon, 17 Aug 2009 04:43:28 -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 n7HBhWn6017989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Aug 2009 14:43:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7HBhWiA021370; Mon, 17 Aug 2009 14:43:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19081.16996.45125.775911@fireball.kivinen.iki.fi> Date: Mon, 17 Aug 2009 14:43:32 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Subject: [IPsec] draft-ietf-ipsecme-ikev2-redirect-13.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, 17 Aug 2009 11:43:29 -0000 I read through this document, and it seems to be mostly ok. Only think that might require clarification is the section "11. IANA Considerations". It currently says that "A specification that extends this registry MUST also mention which of the new values are valid in which Notification payload.", but looking at the initial IANA table, that does not give that information. It would be much better if the initial table would be specified correctly already in this document i.e give initial table as: ---------------------------------------------------------------------- Registry: Value Description Used In Reference ------- ----------------------------------- ------- --------- 1 IPv4 address of the new VPN gateway R,RF [RFCXXXX] 2 IPv6 address of the new VPN gateway R,RF [RFCXXXX] 3 FQDN of the new VPN gateway R [RFCXXXX] 4-240 Unassigned [RFCXXXX] 241-255 Private Use [RFCXXXX] R = REDIRECT notify RF = REDIRECTED_FROM notify ---------------------------------------------------------------------- This kind of method is already used in IANA registries, for example IKEv2 Transform Type registry lists which values are used in IKE and which are used in ESP/AH (http://www.iana.org/assignments/ikev2-parameters). -- kivinen@iki.fi From kivinen@iki.fi Mon Aug 17 04:45: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 8EED43A6C6D for ; Mon, 17 Aug 2009 04:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDgTUsWhcMiP for ; Mon, 17 Aug 2009 04:45:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 76C903A6E76 for ; Mon, 17 Aug 2009 04:45: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 n7HBj9W4022008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 14:45:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7HBj8wn022381; Mon, 17 Aug 2009 14:45: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: <19081.17092.959523.482042@fireball.kivinen.iki.fi> Date: Mon, 17 Aug 2009 14:45:08 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A72E287F0@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A72E287F0@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: emreertekin.ietf@gmail.com, ipsec@ietf.org Subject: Re: [IPsec] Comment/Request on IKEv2bis Draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 17 Aug 2009 11:45:08 -0000 Pasi.Eronen@nokia.com writes: > The original text in RFC 4306 was slightly confusing, but I think we > should leave room for ROHCoIPsec here. Perhaps adding something like > this after the bulleted list? > > If the Child SA negotiation includes some future IPsec protocol(s) > in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then > (1) all keys for SAs carrying data from the initiator to the > responder are taken before SAs going in the reverse direction, and > (2) keying material for the IPsec protocols are taken in the order > in which the protocol headers will appear in the encapsulated > packet. That looks good for me. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Mon Aug 17 04:52: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 E85F93A6EED for ; Mon, 17 Aug 2009 04:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 QPJXm7u7887T for ; Mon, 17 Aug 2009 04:52:40 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 499FC3A6EEC for ; Mon, 17 Aug 2009 04:52:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7HBqNWl016059; Mon, 17 Aug 2009 14:52: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, 17 Aug 2009 14:52:24 +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, 17 Aug 2009 14:52:19 +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; Mon, 17 Aug 2009 13:52:19 +0200 From: To: Date: Mon, 17 Aug 2009 13:52:17 +0200 Thread-Topic: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption Thread-Index: AcofLpb9WjQAHZDlQ4WvE9Y6YFiaYgAAfhAA Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72E28877@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A724C955D@NOK-EUMSG-01.mgdnok.nokia.com> <19081.16394.715433.157178@fireball.kivinen.iki.fi> In-Reply-To: <19081.16394.715433.157178@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: 17 Aug 2009 11:52:19.0977 (UTC) FILETIME=[2CD92F90:01CA1F31] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:52:42 -0000 For most other features (e.g. whether peer supports MOBIKE or not), the draft already says that the relevant payloads (e.g. MOBIKE_SUPPORTED) are sent in the new exchange (instead of assuming everything has remained the same). IMHO the simplest alternative would be to use the same approach for Vendor IDs, too. This is needed even when no vendor-specific data is stored in the ticket, because vendor IDs define how to interpret numbers from the "private use" range... Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of ext Tero Kivinen > Sent: 17 August, 2009 14:34 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2- > resumption >=20 > Pasi.Eronen@nokia.com writes: > > - Section 5: Peer vendor IDs cannot be "implementation specific" -- > if > > the old gateway sent Vendor ID "FOO", the client has to unambiguously > > know whether it's allowed to FOO vendor-specific payloads to the new > > gateway or not. Probably this should be "Not resumed, Vendor ID > > payloads are resent in new exchange if required". >=20 > As we are resuming back to the same GW (failover from one GW to > another was specific non-goal for this document), I think we can > safely assume that GW support exactly same vendor IDs which it did > last time we connected it (or if the GW version was changed and > support for some vendor IDs were removed, then resumption tickets were > also invalidated). >=20 > So in this case the "implementation specific" is quite ok. I.e if > server and client support extension "FOO" indicated by vendor ID > "FOO", which requires some external data to be stored, then that > information that "FOO" was supported and that information was stored > to ticket needs to be stored to ticket. >=20 > If the extension "FOO" does not need any data to be stored across the > resumptions, then there is no need to modify ticket, thus there is not > really need to store information whether "FOO" was supported in the > first place or not. >=20 > Then there is this second case whether client is allowed to "remember" > that gateway supported extension "FOO" without sending any Vendor ID > payloads, or whether they need to be resent. I think we should require > them to be resent, as you said there. >=20 > But there is still cases where ticket might need to store extra > information depending whether vendor ID was originally used or not. >=20 > So I think we need two separate cases one for "Supported Vendor IDs" > which is "Not resumed, Vendor ID payloads are resent in new exchange > if required", and some kind of "Vendor ID specific data", which is > "Implementation specific (needed in ticket only, if vendor-specific > state is required)". >=20 > BTW, the table would be much more readable if there would be some kind > of separators between items, i.e. change to be: >=20 > +------------------------------------+------------------------------ > + > | State Item | After Resumption > | > +------------------------------------+------------------------------ > + > | IDi | From the ticket (but must > | > | | also be exchanged in > | > | | IKE_AUTH). See also Note 1 > | > +------------------------------------+------------------------------ > + > | IDr | From the ticket (but must > | > | | also be exchanged in > | > | | IKE_AUTH) > | > +------------------------------------+------------------------------ > + > | Authentication method (PKI, | From the ticket > | > | pre-shared secret, EAP, PKI-less | > | > | EAP | > | > | [I-D.eronen-ipsec-ikev2-eap-auth] | > | > | etc.) | > | > +------------------------------------+------------------------------ > + > | Certificates (when applicable) | From the ticket, see Note 2 > | > +------------------------------------+------------------------------ > + > | Local IP address/port, peer IP | Selected by the client, see > | > | address/port | Note 3 > | > +------------------------------------+------------------------------ > + > | NAT detection status | From new exchange > | > +------------------------------------+------------------------------ > + > | SPIs | From new exchange, see Note > | > | | 4 > | > +------------------------------------+------------------------------ > + > | Which peer is the "original | Determined by the initiator > | > | initiator"? | of IKE_SESSION_RESUME > | > +------------------------------------+------------------------------ > + > | IKE SA sequence numbers (Message | Reset to 0 in > | > | ID) | IKE_SESSION_RESUME, and > | > | | subsequently incremented > | > | | normally > | > +------------------------------------+------------------------------ > + > | IKE SA algorithms (SAr) | From the ticket > | > +------------------------------------+------------------------------ > + > | IKE SA keys (SK_*) | The old SK_d is obtained > | > | | from the ticket and all keys > | > | | are refreshed, see > | > | | Section 5.1 > | > +------------------------------------+------------------------------ > + > | IKE SA window size | Reset to 1 > | > +------------------------------------+------------------------------ > + > | Child SAs (ESP/AH) | Created in new exchange, see > | > | | Note 7 > | > +------------------------------------+------------------------------ > + > | Internal IP address | Not resumed, but see Note 5 > | > +------------------------------------+------------------------------ > + > | Other Configuration Payload | Not resumed > | > | information | > | > +------------------------------------+------------------------------ > + > | Peer vendor IDs | Implementation specific > | > | | (needed in the ticket only > | > | | if vendor-specific state is > | > | | required) > | > +------------------------------------+------------------------------ > + > | Peer supports MOBIKE [RFC4555] | From new exchange > | > +------------------------------------+------------------------------ > + > | MOBIKE additional addresses | Not resumed, should be > | > | | resent by client if > | > | | necessary > | > +------------------------------------+------------------------------ > + > | Time until re-authentication | From new exchange (but > | > | [RFC4478] | ticket lifetime is bounded > | > | | by this duration) > | > +------------------------------------+------------------------------ > + > | Peer supports redirects | From new exchange > | > | [I-D.ietf-ipsecme-ikev2-redirect] | > | > +------------------------------------+------------------------------ > + >=20 > Also it is bit funny that there is notes 6 and 8, which are not > referenced anywhere. As those are generic rules for processing data > not covered explictly here, it might be better to make them separate > paragraph after the table, instead of hiding such important > information to the non-referenced notes. >=20 > There is also missing closing parenthesis in the end of section 3, > i.e. change >=20 > Moreover, this document requires the client to destroy the ticket > when the user explicitly "logs out" (Section 6.2. >=20 > to >=20 > Moreover, this document requires the client to destroy the ticket > when the user explicitly "logs out" (Section 6.2). > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From emreertekin.ietf@gmail.com Mon Aug 17 09: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 3CD5F3A6C1E for ; Mon, 17 Aug 2009 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.865, 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 KNCSue8L3bdK for ; Mon, 17 Aug 2009 09:49:57 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 0967228C2B5 for ; Mon, 17 Aug 2009 09:49:48 -0700 (PDT) Received: by gxk17 with SMTP id 17so3918631gxk.19 for ; Mon, 17 Aug 2009 09:49:51 -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=lGMx3z8ooVXhVySaBR0kOalYPoxLnhunDoRQNyhwt3M=; b=LHG5Rrlm777fHOOtP+cubmwUfguzXlG8TXYl7V9oZ47qXhTjwpH618WlczL9tr9htR /ObZNNct+t7cDvUXVjiiSTiK9X0Y64bjYIDV+foLH/RMU1K0QpKa+ZQsrylmPKDVL01b yXzESPPX+TlkukHWsRDga4d13jS7zno/5Qwq0= 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=VaIDKg8WCb3BZNOjzN+AHwyVSiwf/Gh/VfUrcB+Kmfaum44wGPc33l3vpjhuH1c9uW vUuxDp7HO+9E2sDgM9gR4DJeZQ7OL3EapD+n3Af0cYseYQy9xaANsnZf0TCq4MSITOmh CaA4Luc1pAS0ZMVjeEgwZ6+z6n6P2bnhyT2hA= MIME-Version: 1.0 Received: by 10.101.81.15 with SMTP id i15mr3661004anl.131.1250527791084; Mon, 17 Aug 2009 09:49:51 -0700 (PDT) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A72E287F0@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A72E287F0@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 17 Aug 2009 09:49:51 -0700 Message-ID: From: Emre Ertekin To: Pasi.Eronen@nokia.com Content-Type: multipart/alternative; boundary=001636ed6776c4f4aa047159307f Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment/Request on IKEv2bis Draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 17 Aug 2009 16:49:58 -0000 --001636ed6776c4f4aa047159307f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Looks good! Thank you. BR, Emre On Mon, Aug 17, 2009 at 3:55 AM, wrote: > The original text in RFC 4306 was slightly confusing, but I think we > should leave room for ROHCoIPsec here. Perhaps adding something like > this after the bulleted list? > > If the Child SA negotiation includes some future IPsec protocol(s) > in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then > (1) all keys for SAs carrying data from the initiator to the > responder are taken before SAs going in the reverse direction, and > (2) keying material for the IPsec protocols are taken in the order > in which the protocol headers will appear in the encapsulated > packet. > > Best regards, > Pasi > (not wearing any hats) > > > -----Original Message----- > > From: Emre Ertekin > > Sent: 15 August, 2009 00:54 > > To: ipsec@ietf.org > > Subject: [IPsec] Comment/Request on IKEv2bis Draft > > > Hi All, > > > > One comment/request on the IKEv2bis draft. > > > > > > One of the differences between RFC 4306 and the IKEv2bis draft is in > > Section 2.17, Generating Key Material for Child SAs. Appendix E.2 > > of the IKEv2bis draft indicates the following: > > > > In Section 2.17, removed "If multiple IPsec protocols are > > negotiated, keying material is taken in the order in which the > > protocol headers will appear in the encapsulated packet" because > > multiple IPsec protocols cannot be negotiated at one time. > > > > Is it possible to leave the quoted text in the spec? I agree that > > multiple IPsec protocols cannot be negotiated at one time; however, > > the text is useful for ROHCoIPsec implementers, where multiple keys > > may need to be generated for a ROHC-enabled Child SA. > > > > For example, if a ROHC-enabled Child-SA with ROHC_INTEG > > [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, > > first the IPsec encryption/authentication keying material will be > > taken, then an additional key will be taken for the algorithm used > > to verify the proper decompression of packet headers. > > > > BR, > > Emre > > --001636ed6776c4f4aa047159307f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks good!=A0 Thank you.

BR,
Emre

On Mon, Aug 17, 2009 at 3:55 AM, <Pasi.Eronen@nokia.com> wrote:
The original text in RFC 4306 was slightly confusing, but I think we
should leave room for ROHCoIPsec here. Perhaps adding something like
this after the bulleted list?

=A0 If the Child SA negotiation includes some future IPsec protocol(s)
=A0 in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
=A0 (1) all keys for SAs carrying data from the initiator to the
=A0 responder are taken before SAs going in the reverse direction, and
=A0 (2) keying material for the IPsec protocols are taken in the order
=A0 in which the protocol headers will appear in the enc= apsulated
=A0 packet.

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: Emre Ertekin
> Sent: 15 August, 2009 00:54
> To: ipsec@ietf.org
> Subject: [IPsec] Comment/Request on IKEv2bis Draft

> Hi All,
> =A0
> One comment/request on the IKEv2bis draft.
>
>
> One of the differences between RFC 4306 and the IKEv2bis draft is in > Section 2.17, Generating Key Material for Child SAs.=A0 Appendix E.2 > of the IKEv2bis draft indicates the following:
>
>=A0=A0 In Section 2.17, removed "If multiple IPsec protocols are > =A0 negotiated, keying material is taken in the order in which the
> =A0 protocol headers will appear in the encapsulated packet" beca= use
> =A0 multiple IPsec protocols cannot be negotiated at one time.
>=A0
> Is it possible to leave the quoted text in the spec?=A0 I agree that > multiple IPsec protocols cannot be negotiated at one time; however, > the text is useful for ROHCoIPsec implementers, where multiple keys > may need to be generated for a ROHC-enabled Child SA.=A0
>
> For example, if a ROHC-enabled Child-SA with ROHC_INTEG
> [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated,
> first the IPsec encryption/authentication keying material will be
> taken, then an additional key will be taken for the algorithm used
> to verify the proper decompression of packet headers.
> =A0
> BR,
> Emre


--001636ed6776c4f4aa047159307f-- From root@core3.amsl.com Mon Aug 17 20: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 993D93A6D2D; Mon, 17 Aug 2009 20: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: <20090818030001.993D93A6D2D@core3.amsl.com> Date: Mon, 17 Aug 2009 20:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.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, 18 Aug 2009 03: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 : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, et al. Filename : draft-ietf-ipsecme-aes-ctr-ikev2-01.txt Pages : 17 Date : 2009-08-17 This document describes the usage of Advanced Encryption Standard Counter Mode (AES_CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-01.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-aes-ctr-ikev2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-17195119.I-D@ietf.org> --NextPart-- From sshen@huawei.com Mon Aug 17 21:04: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 03ACE3A6DB3 for ; Mon, 17 Aug 2009 21:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=2.214, 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 AAGOXmZdQ34i for ; Mon, 17 Aug 2009 21:04:47 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CB9A028C163 for ; Mon, 17 Aug 2009 21:04:08 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK00IXE0GRI4@szxga03-in.huawei.com> for ipsec@ietf.org; Tue, 18 Aug 2009 12:00:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK005N70GR2I@szxga03-in.huawei.com> for ipsec@ietf.org; Tue, 18 Aug 2009 12:00:27 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOK008A50GRUH@szxml04-in.huawei.com> for ipsec@ietf.org; Tue, 18 Aug 2009 12:00:27 +0800 (CST) Date: Tue, 18 Aug 2009 12:00:26 +0800 From: Sean Shen To: ipsec@ietf.org Message-id: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_MTejv5lvLRGXZGNE1/4HIA)" Thread-index: AcofsAYR4y8WM88yQZqijcr+2Cpv4gABc5oA Subject: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.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, 18 Aug 2009 04:04:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MTejv5lvLRGXZGNE1/4HIA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, IPSECME WG, The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The modification addressed comments we received so far and also include some other editing. Your comments will be appreciated. Regard, Sean > 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 : Using Advanced Encryption Standard > (AES) Counter Mode with IKEv2 > Author(s) : S. Shen, et al. > Filename : draft-ietf-ipsecme-aes-ctr-ikev2-01.txt > Pages : 17 > Date : 2009-08-17 > > This document describes the usage of Advanced Encryption > Standard Counter Mode (AES_CTR), with an explicit > initialization vector, by > IKEv2 for encrypting the IKEv2 exchanges that follow the > IKE_SA_INIT exchange. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr > -ikev2-01.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. Major changes are as following: #1. Section 2 Rearranged sentences at the beginning of section 2 to simplify and clarify AES and AES_CTR. #2 Section 2.1 Detailed description of counter mode was cited from corresponding section of rfc3686 #3 Section 2.2: old: All IKEv2 implementations MUST support the 128 key size. new: All IKEv2 implementations that implement AES-CTR MUST support the 128 key size. Because AES-CTR is a "SHOULD" requirement for IKEv2. #4 Section 3.2 Added clear reference to rfc4302 and rfc4307 for integrity requirement and algorithm choice. #5 Section 4 Rewrote second paragraph in section 4 to clarify the role of Counter Block. The Counter Block is same as that defined by rfc3686. #6 Section 4 Keep the Counter Block description in the same style as in rfc3686 --Boundary_(ID_MTejv5lvLRGXZGNE1/4HIA) Content-type: Message/External-body; name=draft-ietf-ipsecme-aes-ctr-ikev2-01.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-ietf-ipsecme-aes-ctr-ikev2-01.txt Content-Type: text/plain Content-ID: <2009-08-17195119.I-D@ietf.org> --Boundary_(ID_MTejv5lvLRGXZGNE1/4HIA) Content-type: text/plain; name=ATT00022.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00022.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_MTejv5lvLRGXZGNE1/4HIA)-- From kivinen@iki.fi Tue Aug 18 02:13: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 768A83A6AB9 for ; Tue, 18 Aug 2009 02:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 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 QKgFUw5BFTJS for ; Tue, 18 Aug 2009 02:13:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 592543A6A8D for ; Tue, 18 Aug 2009 02:13:47 -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 n7I99Vmj007650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 12:09:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7I99URT000131; Tue, 18 Aug 2009 12:09:30 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19082.28618.864503.882563@fireball.kivinen.iki.fi> Date: Tue, 18 Aug 2009 12:09:30 +0300 From: Tero Kivinen To: Sean Shen In-Reply-To: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> References: <002601ca1fb8$6ba9bcd0$800c6f0a@china.huawei.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 41 min Cc: ipsec@ietf.org Subject: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.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, 18 Aug 2009 09:13:49 -0000 Sean Shen writes: > Hi, IPSECME WG, > The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The > modification addressed comments we received so far and also include some > other editing. > Major changes are as following: > #4 > Section 3.2 > Added clear reference to rfc4302 and rfc4307 for integrity requirement and > algorithm choice. I do not think it is good idea to copy the table from RFC4307 as it is likely to change in the future, so better would be just to give reference to the document. On the other hand RFC4306 already says that "... implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm ..." (section 5. Security Considerations of RFC4306), thus AES-CTR cannot be used without integrity algorithm in this context anyways. One thing that is not 100% clear from the draft is that whether there is any padding in the encrypted payload. RFC4306 says that encrypted part is padded up to the block size of the cipher. In AES-CTR the block size is 1, thus that does not require any padding. Normal ESP requires padding for at least up to 4-byte boundary, regardless of the block size of the cipher, thus even AES-CTR uses padding up to 4-byte boundary. The IKEv2 SA does not require thus. I think it would be better to add text explictly saying this. I.e. add text like this to the end of 2.3: ... For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. For Encrypted Payload this means that Padding field is always empty, and Pad Length field will always be 0. -- kivinen@iki.fi From yaronf@checkpoint.com Tue Aug 18 02:16: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 C74A83A6A8D for ; Tue, 18 Aug 2009 02:16:42 -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 onSvK6-jxRoZ for ; Tue, 18 Aug 2009 02:16:38 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 527203A6966 for ; Tue, 18 Aug 2009 02:16:37 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BD32729C021; Tue, 18 Aug 2009 12:15:14 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5F1CD29C020 for ; Tue, 18 Aug 2009 12:15:14 +0300 (IDT) X-CheckPoint: {4A8A7054-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 n7I9Ep3d003568 for ; Tue, 18 Aug 2009 12:14:51 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 18 Aug 2009 12:14:52 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 18 Aug 2009 12:14:50 +0300 Thread-Topic: Comments on draft-ietf-ipsecme-esp-null-heuristics-00 Thread-Index: Acof5FabzW9HhMoESKKIDFx6bEkSlQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B065@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_0016_01CA1FFD.7BEFCAE0" MIME-Version: 1.0 Subject: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 18 Aug 2009 09:16:42 -0000 ------=_NextPart_000_0016_01CA1FFD.7BEFCAE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01CA1FFD.7BEFCAE0" ------=_NextPart_001_0017_01CA1FFD.7BEFCAE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, As a general comment, this document got me thinking whether pseudo-code can be made amenable to some minimal level of validation. For example, there is so much code here that I could never be sure that all "goto"s are referencing valid labels. If any member of this list is a aware of such a solution, I would be interested to know. - Sec. 5. In the definition of IPsec flows, how is this done for (typically tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow definition? This text belongs either here or in Sec. 8. - 5. "Unsure" - if we choose the option of dropping such packets, are there cases when retransmitted packets do not add any information and we will remain forever "unsure"? - 6, first paragraph. in to -> into - 6. This section seems to discuss the construction of an ESP-null detection engine out of an off-the-shelf DPI engine. If this is the case, please say so. - 9.1. 160, 192, and 256 bit algorithms are used -> 160, 192, and 256 field lengths are used - 9.1. "Payload Data" is starred for some reason, probably cut-and-paste. - 10. The Security Considerations needs to have an explanation of what this is good for, i.e. what security policy is enforced, what kind of DPI is done. Also, (malicious) traffic can be encrypted in multiple ways, e.g. simply by using TLS on top of TCP. In addition, we need to note the DOS potential of the ESP-null detection process. - Pseudocode: are we assuming one protocol per SPI? At a higher level, shouldn't we have processing for tunnel mode ESP as well? - Pseudocode: retreaved -> retrieved Thanks, Yaron ------=_NextPart_001_0017_01CA1FFD.7BEFCAE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

As a general comment, this document got me thinking = whether pseudo-code can be made amenable to some minimal level of validation. = For example, there is so much code here that I could never be sure that all = “goto”s are referencing valid labels. If any member of this list is a aware of = such a solution, I would be interested to know.

 

- Sec. 5. In the definition of IPsec flows, how is = this done for (typically tunnel mode) UDP-encapsulated ESP? Are port numbers part = of the flow definition? This text belongs either here or in Sec. = 8.

 

- 5. "Unsure" - if we choose the option of dropping such packets, are there cases when retransmitted packets do not = add any information and we will remain forever = "unsure"?

 

- 6, first paragraph. in to -> = into

 

- 6. This section seems to discuss the construction = of an ESP-null detection engine out of an off-the-shelf DPI engine. If this is = the case, please say so.

 

- 9.1. 160, 192, and 256 bit algorithms are used = -> 160, 192, and 256 field lengths are used

 

- 9.1. "Payload Data" is starred for some = reason, probably cut-and-paste.

 

- 10. The Security Considerations needs to have an explanation of what this is good for, i.e. what security policy is = enforced, what kind of DPI is done. Also, (malicious) traffic can be encrypted in = multiple ways, e.g. simply by using TLS on top of TCP. In addition, we need to = note the DOS potential of the ESP-null detection = process.

 

- Pseudocode: are we assuming one protocol per SPI? = At a higher level, shouldn't we have processing for tunnel mode ESP as = well?

 

- Pseudocode: retreaved -> = retrieved

 

Thanks,

         =    Yaron

------=_NextPart_001_0017_01CA1FFD.7BEFCAE0-- ------=_NextPart_000_0016_01CA1FFD.7BEFCAE0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxODA5MTQ0OVowIwYJKoZIhvcNAQkEMRYEFNTlLHRURvHi XBkYlSJfjMOVMESUMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA AuYBLbwNShQ1LCmXoZnI4GO4elu+8LLCCwxeN5g/JWULTc7iD+gn2HL4+eRIoVXtAmuvnAckmIum 3mrXqjh8kiKBdNdCsYA7D877vqT9BmSw+whZEmaGxVl/seV5+pIpIXtRofzHAeuVo3Pnq8RaO3+e zu+oCn7z+5Qq1Eom8ILVWYBrV7cRKu+JmIkttZ8G1l6lqIVq3l0lxc51qA7/cITW2waVm3pfqZPL JlQ00gNvPEDc5QYcKh42cSTeTdL5iGn0ot6f1kaLU2NPTRrHj9Rm6Pkktdi9FYH+rq2x+xkHHt+l ZPlPs3HIq6eJIEfGe3RYw6zeFtyhSa1c9gOaWQAAAAAAAA== ------=_NextPart_000_0016_01CA1FFD.7BEFCAE0-- From ken.grewal@intel.com Tue Aug 18 09:33:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2720228C271 for ; Tue, 18 Aug 2009 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdPp+hTBHlO3 for ; Tue, 18 Aug 2009 09:33:26 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 5F8E83A6E4A for ; Tue, 18 Aug 2009 09:33:26 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 18 Aug 2009 09:33:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.43,403,1246863600"; d="scan'208";a="177160690" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 18 Aug 2009 09:33:25 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Tue, 18 Aug 2009 10:33:24 -0600 From: "Grewal, Ken" To: Yaron Sheffer , "ipsec@ietf.org" Date: Tue, 18 Aug 2009 10:32:32 -0600 Thread-Topic: Relating the two ESP-null documents Thread-Index: AcoaCU7flAIQ2SPQSLGtPDsGLRShMgAO5ZnQAA+IIRABZ42RsA== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@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] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 18 Aug 2009 16:33:27 -0000 Works for me! Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Yaron Sheffer >Sent: Tuesday, August 11, 2009 6:04 AM >To: ipsec@ietf.org >Subject: [IPsec] Relating the two ESP-null documents > >Hi, > >As we near publication of the WESP and Heuristics drafts, we'd like to >make >sure that the WG consensus is clearly expressed in both documents. So we >propose to include the following note as a section in both documents. >Please >let us know if this works for you: > >-- begin text > >Applicability: Heuristic Traffic Inspection and Wrapped ESP >----------------------------------------------------------- > >There are two ways to enable intermediate security devices to >distinguish >between encrypted and unencrypted ESP traffic: > >- The heuristics approach [heuristics I-D] has the intermediate node >inspect >the unchanged ESP traffic, to determine with extremely high probability >whether or not the traffic stream is encrypted. > >- The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP >endpoints to be modified to support the new protocol. WESP allows the >intermediate node to distinguish encrypted and unencrypted traffic >deterministically, using a simpler implementation for the intermediate >node. > >Both approaches are being documented simultaneously by the IPsecME >Working >Group, with WESP being put on Standards Track while the heuristics >approach >is being published as an Informational RFC. While endpoints are being >modified to adopt WESP, we expect both approaches to coexist for years, >because the heuristic approach is needed to inspect traffic where at >least >one of the endpoints has not been modified. In other words, intermediate >nodes are expected to support both approaches in order to achieve good >security and performance during the transition period. > >-- end text > >[Note: both references are non-normative.] > >Currently both documents have direct or indirect references to one >another, >but they are not exactly in line with the consensus we have reached. In >both >cases the emphasis is on the two solutions competing with one another, >rather than complementing each other. > >Thanks, > Yaron From manav@alcatel-lucent.com Tue Aug 18 18:01: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 E71013A6987 for ; Tue, 18 Aug 2009 18:01:35 -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 WMo3cJruxAr4 for ; Tue, 18 Aug 2009 18:01:35 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 0688B3A6A4E for ; Tue, 18 Aug 2009 18:01:34 -0700 (PDT) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7J11ZX6008153; Tue, 18 Aug 2009 20:01:35 -0500 (CDT) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id n7J11Xb2022165; Tue, 18 Aug 2009 20:01:34 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n7J1FTX9009585; Wed, 19 Aug 2009 09:15:29 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 19 Aug 2009 06:31:31 +0530 From: "Bhatia, Manav (Manav)" To: Yaron Sheffer , "ipsec@ietf.org" Date: Wed, 19 Aug 2009 06:31:28 +0530 Thread-Topic: Relating the two ESP-null documents Thread-Index: AcoaCU7flAIQ2SPQSLGtPDsGLRShMgAO5ZnQAA+IIRABZ42RsAAR0wtA Message-ID: <7C362EEF9C7896468B36C9B79200D8350A1D1C6F79@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Subject: Re: [IPsec] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 19 Aug 2009 01:01:36 -0000 Works for me too! Cheers, Manav=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Grewal, Ken > Sent: Tuesday, August 18, 2009 10.03 PM > To: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Relating the two ESP-null documents >=20 > Works for me! >=20 > Thanks,=20 > - Ken > =20 >=20 > >-----Original Message----- > >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf > >Of Yaron Sheffer > >Sent: Tuesday, August 11, 2009 6:04 AM > >To: ipsec@ietf.org > >Subject: [IPsec] Relating the two ESP-null documents > > > >Hi, > > > >As we near publication of the WESP and Heuristics drafts,=20 > we'd like to > >make > >sure that the WG consensus is clearly expressed in both=20 > documents. So we > >propose to include the following note as a section in both documents. > >Please > >let us know if this works for you: > > > >-- begin text > > > >Applicability: Heuristic Traffic Inspection and Wrapped ESP > >----------------------------------------------------------- > > > >There are two ways to enable intermediate security devices to > >distinguish > >between encrypted and unencrypted ESP traffic: > > > >- The heuristics approach [heuristics I-D] has the intermediate node > >inspect > >the unchanged ESP traffic, to determine with extremely high=20 > probability > >whether or not the traffic stream is encrypted. > > > >- The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP > >endpoints to be modified to support the new protocol. WESP allows the > >intermediate node to distinguish encrypted and unencrypted traffic > >deterministically, using a simpler implementation for the=20 > intermediate > >node. > > > >Both approaches are being documented simultaneously by the IPsecME > >Working > >Group, with WESP being put on Standards Track while the heuristics > >approach > >is being published as an Informational RFC. While endpoints are being > >modified to adopt WESP, we expect both approaches to coexist=20 > for years, > >because the heuristic approach is needed to inspect traffic where at > >least > >one of the endpoints has not been modified. In other words,=20 > intermediate > >nodes are expected to support both approaches in order to=20 > achieve good > >security and performance during the transition period. > > > >-- end text > > > >[Note: both references are non-normative.] > > > >Currently both documents have direct or indirect references to one > >another, > >but they are not exactly in line with the consensus we have=20 > reached. In > >both > >cases the emphasis is on the two solutions competing with=20 > one another, > >rather than complementing each other. > > > >Thanks, > > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From sshen@huawei.com Tue Aug 18 18:46: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 672DD3A6A25 for ; Tue, 18 Aug 2009 18:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=1.660, 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 X4BTak8Ce2hp for ; Tue, 18 Aug 2009 18:46:32 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7B47B3A6837 for ; Tue, 18 Aug 2009 18:46:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOL0058AOX66F@szxga04-in.huawei.com> for ipsec@ietf.org; Wed, 19 Aug 2009 09:46:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOL000NPOX6FI@szxga04-in.huawei.com> for ipsec@ietf.org; Wed, 19 Aug 2009 09:46:18 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOL00FBFOX5FM@szxml04-in.huawei.com> for ipsec@ietf.org; Wed, 19 Aug 2009 09:46:18 +0800 (CST) Date: Wed, 19 Aug 2009 09:46:10 +0800 From: Sean Shen In-reply-to: <19082.28618.864503.882563@fireball.kivinen.iki.fi> To: 'Tero Kivinen' Message-id: <000f01ca206e$d8585740$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acof5+opGP/kIqFbQlm5fqIXHW+oTAAf600g Cc: ipsec@ietf.org Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 01:46:33 -0000 Hi, Tero, Thanks for the comments. Please check in lines: > Sean Shen writes: > > Hi, IPSECME WG, > > The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The > > modification addressed comments we received so far and also include > > some other editing. > > Major changes are as following: > > #4 > > Section 3.2 > > Added clear reference to rfc4302 and rfc4307 for integrity > requirement > > and algorithm choice. > > I do not think it is good idea to copy the table from RFC4307 > as it is likely to change in the future, so better would be > just to give reference to the document. > > On the other hand RFC4306 already says that "... > implementations MUST NOT negotiate NONE as the IKE integrity > protection algorithm ..." > (section 5. Security Considerations of RFC4306), thus AES-CTR > cannot be used without integrity algorithm in this context anyways. The point here is to say that integrity protection is needed with aes-ctr, not trying to specify which integrity algorithm to choose. rfc4306 already required integrity for ikev2 and we refered to 4306 here. The choice of integrity algorithm is up to rfc4307 or some update document, we just listed what rfc4307 chooses to make this document more rich of information. If you think the table gives misleading impression of only requiring these particular algorithms, we may add another sentence to hint that integrity algorithm requirement may change over time, please check 4307 and 4307's update, the following listed algorithm is just showing current 4307's requirement. > One thing that is not 100% clear from the draft is that > whether there is any padding in the encrypted payload. > RFC4306 says that encrypted part is padded up to the block > size of the cipher. In AES-CTR the block size is 1, thus that > does not require any padding. Normal ESP requires padding for > at least up to 4-byte boundary, regardless of the block size > of the cipher, thus even AES-CTR uses padding up to 4-byte > boundary. The IKEv2 SA does not require thus. > > I think it would be better to add text explictly saying this. > I.e. add text like this to the end of 2.3: > > ... For this > reason, AES-CTR does not require the plaintext to be padded to a > multiple of the block size. For Encrypted Payload this means that > Padding field is always empty, and Pad Length field will always be > 0. I don't agree with this. Specifying Padding field to be empty and Pad Length to be zero here is not proper, because rfc4306 requires that recipient MUST accept any lenght that results in proper alignment (section 3.14). Best, Sean From yaronf@checkpoint.com Wed Aug 19 02:23: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 D02333A69A6 for ; Wed, 19 Aug 2009 02:23:25 -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 VoHAOQUFf3-Z for ; Wed, 19 Aug 2009 02:23:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 64E5C3A6D23 for ; Wed, 19 Aug 2009 02:23:19 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 195C029C004; Wed, 19 Aug 2009 12:23:43 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B9EC929C002; Wed, 19 Aug 2009 12:23:42 +0300 (IDT) X-CheckPoint: {4A8BC3BE-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 n7J9NJ3d020567; Wed, 19 Aug 2009 12:23:20 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 19 Aug 2009 12:23:20 +0300 From: Yaron Sheffer To: Sean Shen , "'Tero Kivinen'" Date: Wed, 19 Aug 2009 12:23:18 +0300 Thread-Topic: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt Thread-Index: Acof5+opGP/kIqFbQlm5fqIXHW+oTAAf600gABF2+dA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B1CC@il-ex01.ad.checkpoint.com> References: <19082.28618.864503.882563@fireball.kivinen.iki.fi> <000f01ca206e$d8585740$800c6f0a@china.huawei.com> In-Reply-To: <000f01ca206e$d8585740$800c6f0a@china.huawei.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_0034_01CA20C7.D51E8B90" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 09:23:25 -0000 ------=_NextPart_000_0034_01CA20C7.D51E8B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sean, I agree with Tero that including the table in the document is redundant and confusing. Removing it would add clarity, more than your proposed text IMO. Regarding padding, you are right that the recipient should accept anything, but you can still repeat the sentence "AES-CTR does not require the plaintext to be padded to a multiple of the block size" (or better still: "the sender is not required to pad the plaintext") in the section that specifies the Encrypted Payload. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Sean Shen > Sent: Wednesday, August 19, 2009 4:46 > To: 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2- > 01.txt > > Hi, Tero, > Thanks for the comments. Please check in lines: > > > Sean Shen writes: > > > Hi, IPSECME WG, > > > The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The > > > modification addressed comments we received so far and also include > > > some other editing. > > > Major changes are as following: > > > #4 > > > Section 3.2 > > > Added clear reference to rfc4302 and rfc4307 for integrity > > requirement > > > and algorithm choice. > > > > I do not think it is good idea to copy the table from RFC4307 > > as it is likely to change in the future, so better would be > > just to give reference to the document. > > > > On the other hand RFC4306 already says that "... > > implementations MUST NOT negotiate NONE as the IKE integrity > > protection algorithm ..." > > (section 5. Security Considerations of RFC4306), thus AES-CTR > > cannot be used without integrity algorithm in this context anyways. > The point here is to say that integrity protection is needed with aes-ctr, > not trying to specify which integrity algorithm to choose. rfc4306 already > required integrity for ikev2 and we refered to 4306 here. The choice of > integrity algorithm is up to rfc4307 or some update document, we just > listed > what rfc4307 chooses to make this document more rich of information. If > you > think the table gives misleading impression of only requiring these > particular algorithms, we may add another sentence to hint that integrity > algorithm requirement may change over time, please check 4307 and 4307's > update, the following listed algorithm is just showing current 4307's > requirement. > > > > One thing that is not 100% clear from the draft is that > > whether there is any padding in the encrypted payload. > > RFC4306 says that encrypted part is padded up to the block > > size of the cipher. In AES-CTR the block size is 1, thus that > > does not require any padding. Normal ESP requires padding for > > at least up to 4-byte boundary, regardless of the block size > > of the cipher, thus even AES-CTR uses padding up to 4-byte > > boundary. The IKEv2 SA does not require thus. > > > > I think it would be better to add text explictly saying this. > > I.e. add text like this to the end of 2.3: > > > > ... For this > > reason, AES-CTR does not require the plaintext to be padded to a > > multiple of the block size. For Encrypted Payload this means that > > Padding field is always empty, and Pad Length field will always be > > 0. > I don't agree with this. Specifying Padding field to be empty and Pad > Length > to be zero here is not proper, because rfc4306 requires that recipient > MUST > accept any lenght that results in proper alignment (section 3.14). > > Best, > > Sean > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0034_01CA20C7.D51E8B90 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxOTA5MjMxN1owIwYJKoZIhvcNAQkEMRYEFBabsCE6LywY PK+RH1t5TUzCo6zWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA VpVBIVPdxjJqo7PunM7Ei/FiUwmVhPgiBp2KhRYb0SeVg0JiFBnx9JF0tPLglFqFZINxOU35f1Ep 16p/562JPh0oKjDiV3dfZ58E0viNVKkdPKyx8GtX1W2lUPSfDjRAN5tyDHlTEq9Jp1y+bdbGhK7b Yo0cfxzynOQw0Juxmw4RGkHWu6qKq19+QhcbmmUOrOGTG9h8OrqQCGL5bsK9kVS5AMP339lLBtz1 WXJPN3zMsX145cTwvF34ZvpBlnNTS5/LPHm5gSoglgIjz7hLk51adArOduDuKfmj/BnS1EADhmfe KBxec7XYJJWbADRVoJBxS7RZu4ekOFAeJPgTwwAAAAAAAA== ------=_NextPart_000_0034_01CA20C7.D51E8B90-- From kivinen@iki.fi Wed Aug 19 03:59:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9AC3A6D4D for ; Wed, 19 Aug 2009 03:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 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 L9RFllzqeJMQ for ; Wed, 19 Aug 2009 03:59:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B758F3A6876 for ; Wed, 19 Aug 2009 03:59:39 -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 n7JAxIKE023356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 13:59:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7JAxIWc004367; Wed, 19 Aug 2009 13:59: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: <19083.56070.499019.762366@fireball.kivinen.iki.fi> Date: Wed, 19 Aug 2009 13:59:18 +0300 From: Tero Kivinen To: Sean Shen In-Reply-To: <000f01ca206e$d8585740$800c6f0a@china.huawei.com> References: <19082.28618.864503.882563@fireball.kivinen.iki.fi> <000f01ca206e$d8585740$800c6f0a@china.huawei.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 10:59:41 -0000 Sean Shen writes: > The point here is to say that integrity protection is needed with aes-ctr, > not trying to specify which integrity algorithm to choose. rfc4306 already > required integrity for ikev2 and we refered to 4306 here. The choice of > integrity algorithm is up to rfc4307 or some update document, we just listed > what rfc4307 chooses to make this document more rich of information. If you > think the table gives misleading impression of only requiring these > particular algorithms, we may add another sentence to hint that integrity > algorithm requirement may change over time, please check 4307 and 4307's > update, the following listed algorithm is just showing current 4307's > requirement. I think it is better to remove the table, and just refer to RFC4307 directly. > > One thing that is not 100% clear from the draft is that > > whether there is any padding in the encrypted payload. > > RFC4306 says that encrypted part is padded up to the block > > size of the cipher. In AES-CTR the block size is 1, thus that > > does not require any padding. Normal ESP requires padding for > > at least up to 4-byte boundary, regardless of the block size > > of the cipher, thus even AES-CTR uses padding up to 4-byte > > boundary. The IKEv2 SA does not require thus. > > > > I think it would be better to add text explictly saying this. > > I.e. add text like this to the end of 2.3: > > > > ... For this > > reason, AES-CTR does not require the plaintext to be padded to a > > multiple of the block size. For Encrypted Payload this means that > > Padding field is always empty, and Pad Length field will always be > > 0. > I don't agree with this. Specifying Padding field to be empty and Pad Length > to be zero here is not proper, because rfc4306 requires that recipient MUST > accept any lenght that results in proper alignment (section 3.14). Yes, it MUST accept, and it says SHOULD set Pad Length to minimum value, which in this case is zero. I think it is important to note that no padding is required, thus Pad Length field can be zero, and if the SHOULD in the RFC4306 is followed it will be zero. As this is different from the ESP, I think it is important to note this difference. In ESP the padding length MUST be selected so that provides 4-byte alignment for the encrypted data, but for IKEv2 there is no such requirement, and this should be even more explictly mentioned in the draft. -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Aug 19 11: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 D24943A6AD9 for ; Wed, 19 Aug 2009 11:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=1.877, 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 55sdC2MSwORs for ; Wed, 19 Aug 2009 11:04:41 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 13B4A3A69C6 for ; Wed, 19 Aug 2009 11:04:40 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JI4j5o006700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Aug 2009 11:04:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> Date: Wed, 19 Aug 2009 11:04:43 -0700 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 19 Aug 2009 18:04:41 -0000 At 12:05 AM +0300 8/11/09, Yaron Sheffer wrote: >This is the beginning of a two-week WG Last Call, which will end August 24. >The target status for this document is Informational (to obsolete RFC 2411). >The current document is at >http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03. That was a week ago. >If you have not read the document before now, please do so. Having fresh >eyes on the document often brings up important issues. This document is very >much a survey, so please also review it for completeness: are there >documents that should be mentioned but aren't. Send any comments to the >list, even if they are as simple as "I read it and it seems fine". And, so far, we have heard nothing. *This is bad.* This is a WG document: that means it needs to have rough consensus of the WG. Silence is not consent. >Please clearly indicate the position of any issue in the Internet Draft, and >if possible provide alternative text. 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. ...and do so within the next week. If we do not get enough input during WG Last Call, we will have to reconsider how to handle this and future documents. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Thu Aug 20 17:15:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0EB323A6935; Thu, 20 Aug 2009 17:15: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: <20090821001502.0EB323A6935@core3.amsl.com> Date: Thu, 20 Aug 2009 17:15:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:15: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 : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-02.txt Pages : 34 Date : 2009-08-20 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-ipv6-config-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-20170544.I-D@ietf.org> --NextPart-- From julienl@qualcomm.com Thu Aug 20 17: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 D609D3A6949 for ; Thu, 20 Aug 2009 17:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 yxyiHCYPhCEx for ; Thu, 20 Aug 2009 17:37:42 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id F00EE3A68B0 for ; Thu, 20 Aug 2009 17:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1250815067; x=1282351067; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"ipsec@ietf.org"=20|Date:=20Thu, =2020=20Aug=202009=2017:37:44=20-0700|Subject:=20RE:=20WG =20Last=20Call:=20draft-ietf-ipsecme-roadmap-03 |Thread-Topic:=20WG=20Last=20Call:=20draft-ietf-ipsecme-r oadmap-03|Thread-Index:=20Acn84GccXdkwAkW2QlWsL8kxCqVagwd G+9MQAf4z7LA=3D|Message-ID:=20|References: =20<7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad .checkpoint.com>=0D=0A=20<7F9A6D26EB51614FBF9F81C0DA4CFEC 80158E120A80B@il-ex01.ad.checkpoint.com>|In-Reply-To:=20< 7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.c heckpoint.com>|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5715"=3B=20a=3D"22413784"; bh=+6yd+TIvT1q1u4xur86kRpFNZdVKZhWnKlMErF2Q0Os=; b=xJRYlD8TcExIcKWEUFoJo012v4cfAnI6I9tRmYqWklgWGBRx6/F7JIXY 4p5BD8Z6E9wDU1MuiDpALsnw8LItWE4PyPk0K1t6hBR0+h0k72EvH4Zy2 rDNIMdpWxpZ81sfnzaRTLiKyVMRvP0dP3toJy1NfCnpOVnURspmr7gx/4 E=; X-IronPort-AV: E=McAfee;i="5300,2777,5715"; a="22413784" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2009 17:37:47 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7L0blfu004331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Aug 2009 17:37:47 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7L0bkRC023535 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Aug 2009 17:37:47 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 20 Aug 2009 17:37:46 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Thu, 20 Aug 2009 17:37:46 -0700 From: "Laganier, Julien" To: "ipsec@ietf.org" Date: Thu, 20 Aug 2009 17:37:44 -0700 Thread-Topic: WG Last Call: draft-ietf-ipsecme-roadmap-03 Thread-Index: Acn84GccXdkwAkW2QlWsL8kxCqVagwdG+9MQAf4z7LA= Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Aug 2009 00:37:42 -0000 Greetings, I have reviewed this document and I think it's in good shape but I however = have one technical comment that I'd like to discuss. In Section 3.4. "Additions to IPsec", "RFC 4891, Using IPsec to Secure IPv6= -in-IPv4 Tunnels" is marked as optional. I do not understand the significan= ce of marking this as optional because: 1) 4891 is informational and only describes a set of configuration settings= rather than a protocol, and, 2) an IPsec traffic selector can discriminate based on "Next Layer Protocol= " and thus can be used to realize 4891. =20 So I'm thinking 4891 requirement level should be N/A rather than optional. The exact same reasoning seems to apply to "RFC 3884, Use of IPsec Transpor= t Mode for Dynamic Routing" which is also marked as optional. What do you think? --julien From hoskuld@hotmail.com Thu Aug 20 21:45: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 38DB03A6A58 for ; Thu, 20 Aug 2009 21:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, 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 2WQma8s-yPZe for ; Thu, 20 Aug 2009 21:45:16 -0700 (PDT) Received: from bay0-omc1-s28.bay0.hotmail.com (bay0-omc1-s28.bay0.hotmail.com [65.54.246.100]) by core3.amsl.com (Postfix) with ESMTP id 6925F3A6405 for ; Thu, 20 Aug 2009 21:45:16 -0700 (PDT) Received: from BAY114-W22 ([65.54.169.122]) by bay0-omc1-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 21:45:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_61c6c2e8-865f-42af-b01a-6c8cb33ec4e5_" X-Originating-IP: [203.8.7.222] From: Greg Daley To: , Date: Fri, 21 Aug 2009 14:45:22 +1000 Importance: Normal In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2009 04:45:22.0607 (UTC) FILETIME=[315BBBF0:01CA221A] Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Aug 2009 04:45:18 -0000 --_61c6c2e8-865f-42af-b01a-6c8cb33ec4e5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yaron=2C My reading of the document didn't have time to delve into specific issues r= egarding the individual sources=2C except in a few areas where my interest lies. Therefore my reading was focussed on the clarity of structure and text=2C a= nd the completeness of specifications described. S7.1 (really just an editing issue) s/provides losslesss compression/provides lossless compression/ S8.2 Is it worth mentioning that OSPF protection in RFC4552 works with manual ke= ying only=2C and that no key exchange protocols are specified? Most of the earlier document paragraphs describe the affinity of a protocol= to IKE/IKEv2 etc. Please note that I have already used this document myself as a reference (a= s someone becoming more familiar with current protocol development for IPSec/IKEv2) s= o I think that the document is useful and a good starting point for implementors/prot= ocol developers. Sincerely=2C=20 Greg Daley > From: yaronf@checkpoint.com > To: ipsec@ietf.org > Date: Tue=2C 11 Aug 2009 00:05:07 +0300 > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 >=20 > This is the beginning of a two-week WG Last Call=2C which will end August= 24. > The target status for this document is Informational (to obsolete RFC 241= 1). > The current document is at > http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03. >=20 > If you have not read the document before now=2C please do so. Having fres= h > eyes on the document often brings up important issues. This document is v= ery > much a survey=2C so please also review it for completeness: are there > documents that should be mentioned but aren't. Send any comments to the > list=2C even if they are as simple as "I read it and it seems fine". >=20 > Please clearly indicate the position of any issue in the Internet Draft= =2C and > if possible provide alternative text. Indicate the nature or severity of = the > error or correction=2C e.g. major technical=2C minor technical=2C nit=2C = so that we > can quickly judge the extent of problems with the document. >=20 > Thanks=2C > Yaron _________________________________________________________________ What goes online=2C stays online Check the daily blob for the latest on wha= t's happening around the web http://windowslive.ninemsn.com.au/blog.aspx= --_61c6c2e8-865f-42af-b01a-6c8cb33ec4e5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yaron=2C

My reading of the document didn't have time to delve int= o specific issues regarding
the individual sources=2C except in a few ar= eas where my interest lies.

Therefore my reading was focussed on the= clarity of structure and text=2C and the completeness
of specifications= described.

S7.1
(really just an editing issue)

s/provides= losslesss compression/provides lossless compression/

S8.2

Is= it worth mentioning that OSPF protection in RFC4552 works with manual keyi= ng
only=2C and that no key exchange protocols are specified?

Most= of the earlier document paragraphs describe the affinity of a protocol to = IKE/IKEv2 etc.

Please note that I have already used this document my= self as a reference (as someone
becoming more familiar with current prot= ocol development for IPSec/IKEv2) so I think
that the document is useful= and a good starting point for implementors/protocol developers.

Sin= cerely=2C

Greg Daley

>=3B From: yaronf@checkpoint.com
&= gt=3B To: ipsec@ietf.org
>=3B Date: Tue=2C 11 Aug 2009 00:05:07 +0300<= br>>=3B Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03
&= gt=3B
>=3B This is the beginning of a two-week WG Last Call=2C which = will end August 24.
>=3B The target status for this document is Inform= ational (to obsolete RFC 2411).
>=3B The current document is at
>= =3B http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03.
>=3B >=3B If you have not read the document before now=2C please do so. Havin= g fresh
>=3B eyes on the document often brings up important issues. Th= is document is very
>=3B much a survey=2C so please also review it for= completeness: are there
>=3B documents that should be mentioned but a= ren't. Send any comments to the
>=3B list=2C even if they are as simpl= e as "I read it and it seems fine".
>=3B
>=3B Please clearly ind= icate the position of any issue in the Internet Draft=2C and
>=3B if p= ossible provide alternative text. Indicate the nature or severity of the>=3B error or correction=2C e.g. major technical=2C minor technical=2C n= it=2C so that we
>=3B can quickly judge the extent of problems with th= e document.
>=3B
>=3B Thanks=2C
>=3B  =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B Yaron
Check the daily blob for the latest on what's happening aroun= d the web What goes online=2C stays online = --_61c6c2e8-865f-42af-b01a-6c8cb33ec4e5_-- From sshen@huawei.com Fri Aug 21 00:41: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 C3EF73A659C for ; Fri, 21 Aug 2009 00:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 Sxs2LqddzlKv for ; Fri, 21 Aug 2009 00:41:01 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C3C603A68D5 for ; Fri, 21 Aug 2009 00:41:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOP00GAJUO6E9@szxga03-in.huawei.com> for ipsec@ietf.org; Fri, 21 Aug 2009 15:40:54 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOP009H3UO59J@szxga03-in.huawei.com> for ipsec@ietf.org; Fri, 21 Aug 2009 15:40:53 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOP00ECRUO57T@szxml06-in.huawei.com> for ipsec@ietf.org; Fri, 21 Aug 2009 15:40:53 +0800 (CST) Date: Fri, 21 Aug 2009 15:40:53 +0800 From: Sean Shen In-reply-to: <19083.56070.499019.762366@fireball.kivinen.iki.fi> To: 'Tero Kivinen' Message-id: <004501ca2232$b66482b0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcogvEePvBlSuPy0RX2QteTjRwnBrABbygsw Cc: ipsec@ietf.org Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.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, 21 Aug 2009 07:41:02 -0000 > > The point here is to say that integrity protection is needed with > > aes-ctr, not trying to specify which integrity algorithm to choose. > > rfc4306 already required integrity for ikev2 and we refered to 4306 > > here. The choice of integrity algorithm is up to rfc4307 or some > > update document, we just listed what rfc4307 chooses to make this > > document more rich of information. If you think the table gives > > misleading impression of only requiring these particular > algorithms, > > we may add another sentence to hint that integrity algorithm > > requirement may change over time, please check 4307 and > 4307's update, > > the following listed algorithm is just showing current > 4307's requirement. > > I think it is better to remove the table, and just refer to > RFC4307 directly. Ok, we will remove he talbe and only keep reference. > > > One thing that is not 100% clear from the draft is that whether > > > there is any padding in the encrypted payload. > > > RFC4306 says that encrypted part is padded up to the > block size of > > > the cipher. In AES-CTR the block size is 1, thus that does not > > > require any padding. Normal ESP requires padding for at > least up to > > > 4-byte boundary, regardless of the block size of the cipher, thus > > > even AES-CTR uses padding up to 4-byte boundary. The > IKEv2 SA does > > > not require thus. > > > > > > I think it would be better to add text explictly saying this. > > > I.e. add text like this to the end of 2.3: > > > > > > ... For this > > > reason, AES-CTR does not require the plaintext to be > padded to a > > > multiple of the block size. For Encrypted Payload this > means that > > > Padding field is always empty, and Pad Length field > will always be > > > 0. > > I don't agree with this. Specifying Padding field to be > empty and Pad > > Length to be zero here is not proper, because rfc4306 requires that > > recipient MUST accept any lenght that results in proper > alignment (section 3.14). > > Yes, it MUST accept, and it says SHOULD set Pad Length to > minimum value, which in this case is zero. I think it is > important to note that no padding is required, thus Pad > Length field can be zero, and if the SHOULD in the RFC4306 is > followed it will be zero. > > As this is different from the ESP, I think it is important to > note this difference. In ESP the padding length MUST be > selected so that provides 4-byte alignment for the encrypted > data, but for IKEv2 there is no such requirement, and this > should be even more explictly mentioned in the draft. So, we will add sentences in section 3 (encrypted payload) to enphasize again that: sender is not required to pad plaintext; pad SHOULD be zero following the "SHOULD be minimun" in rfc4306; also the difference of pad requirement between ikev2 and esp will be helpful here. Thanks, Sean From smoonen@us.ibm.com Fri Aug 21 06:42: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 1269628C127; Fri, 21 Aug 2009 06:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa9qNVF9hjLn; Fri, 21 Aug 2009 06:42:04 -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 66A343A698B; Fri, 21 Aug 2009 06:42:04 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LDc2Ne002665; Fri, 21 Aug 2009 07:38:02 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LDflDn093370; Fri, 21 Aug 2009 07:41:48 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n7LDgjgs011285; Fri, 21 Aug 2009 07:42:45 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n7LDgiLr011260; Fri, 21 Aug 2009 07:42:44 -0600 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@il-ex01.ad.checkpoint.com> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: 1D5343AC:F6DBE706-85257619:003FAAD2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/21/2009 09:26:34 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/21/2009 09:26:34 AM, Serialize complete at 08/21/2009 09:26:34 AM, S/MIME Sign failed at 08/21/2009 09:26:34 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08092009|August 09, 2009) at 08/21/2009 07:41:39, Serialize complete at 08/21/2009 07:41:39 Message-ID: Date: Fri, 21 Aug 2009 09:41:38 -0400 Content-Type: multipart/alternative; boundary="=_alternative 0049D80185257619_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Aug 2009 13:42:06 -0000 This is a multipart message in MIME format. --=_alternative 0049D80185257619_= Content-Type: text/plain; charset="US-ASCII" I have the following comments. 1) Section 2.1, in both the text and the diagram, refers to combined-mode algorithms only in relation to ESP. However, RFC 4543 defines the use of AES-GMAC for both ESP and AH. 2) Nit -- there are a few places that don't hyphenate "combined mode" when used as an adjective: "combined mode algorithm[s]" should be "combined-mode algorithm[s]". 3) Section 2.3.1, nit -- "at time" should read "at times". 4) Section 2.3.1, second paragraph -- The first sentence refers to two SA pairs and then the following sentences refer to two SAs. Perhaps we should make this transition less abrupt? I suggest inserting a sentence after the first to indicate that "SA" can be used to refer not only to the unidirectional SA but also to the pair. 5) Section 2.3.1, second paragraph -- Is it worth noting that "phase 1 SA" and "phase 2 SA" are also common names for the IKEv1 SAs? 6) Nit -- there are a couple spots where we have unfortunate widow/orphan lines. E.g., between pp. 13/14 and 15/16. 7) Page 21 -- At the very top, the reference "psecme-2" should read "ipsecme-2". Also, I'm curious why this reference is linked and some earlier ones (e.g., "ipsecme-3") aren't. 8) Section 5.3 -- Under RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for IPsec. We should also mention that this truncation is done for IKEv2 as well. 9) Section 5.3 -- As above, AES-GMAC is a combined-mode algorithm. 10) Section 5.3 -- Under RFC 4543, it mentions that the salt "is generated by IKEv2". Now that there are IANA assignments for IKEv1 to negotiate AES-GMAC for AH/ESP (thanks, Tero!), it seems appropriate to generalize this statement about the salt. 11) Section 5.3 -- Under RFC 2403, as with RFC 2404, IKEv2 truncates the ICV as well. 12) Section 5.4 -- Under RFC 4106, as with RFC 4543 above, we should generalize the statements "is generated by IKEv2" and "IKEv2 negotiations" to refer simply to IKE. I glossed over some sections that aren't of significant interest to me. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman To: ipsec@ietf.org Date: 08/19/2009 02:05 PM Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 At 12:05 AM +0300 8/11/09, Yaron Sheffer wrote: >This is the beginning of a two-week WG Last Call, which will end August 24. >The target status for this document is Informational (to obsolete RFC 2411). >The current document is at >http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03. That was a week ago. >If you have not read the document before now, please do so. Having fresh >eyes on the document often brings up important issues. This document is very >much a survey, so please also review it for completeness: are there >documents that should be mentioned but aren't. Send any comments to the >list, even if they are as simple as "I read it and it seems fine". And, so far, we have heard nothing. *This is bad.* This is a WG document: that means it needs to have rough consensus of the WG. Silence is not consent. >Please clearly indicate the position of any issue in the Internet Draft, and >if possible provide alternative text. 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. ...and do so within the next week. If we do not get enough input during WG Last Call, we will have to reconsider how to handle this and future documents. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0049D80185257619_= Content-Type: text/html; charset="US-ASCII"
I have the following comments.

1) Section 2.1, in both the text and the diagram, refers to combined-mode algorithms only in relation to ESP.  However, RFC 4543 defines the use of AES-GMAC for both ESP and AH.
2) Nit -- there are a few places that don't hyphenate "combined mode" when used as an adjective: "combined mode algorithm[s]" should be "combined-mode algorithm[s]".
3) Section 2.3.1, nit -- "at time" should read "at times".
4) Section 2.3.1, second paragraph -- The first sentence refers to two SA pairs and then the following sentences refer to two SAs.  Perhaps we should make this transition less abrupt?  I suggest inserting a sentence after the first to indicate that "SA" can be used to refer not only to the unidirectional SA but also to the pair.
5) Section 2.3.1, second paragraph -- Is it worth noting that "phase 1 SA" and "phase 2 SA" are also common names for the IKEv1 SAs?
6) Nit -- there are a couple spots where we have unfortunate widow/orphan lines.  E.g., between pp. 13/14 and 15/16.
7) Page 21 -- At the very top, the reference "psecme-2" should read "ipsecme-2".  Also, I'm curious why this reference is linked and some earlier ones (e.g., "ipsecme-3") aren't.
8) Section 5.3 -- Under RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for IPsec.  We should also mention that this truncation is done for IKEv2 as well.
9) Section 5.3 -- As above, AES-GMAC is a combined-mode algorithm.
10) Section 5.3 -- Under RFC 4543, it mentions that the salt "is generated by IKEv2".  Now that there are IANA assignments for IKEv1 to negotiate AES-GMAC for AH/ESP (thanks, Tero!), it seems appropriate to generalize this statement about the salt.
11) Section 5.3 -- Under RFC 2403, as with RFC 2404, IKEv2 truncates the ICV as well.
12) Section 5.4 -- Under RFC 4106, as with RFC 4543 above, we should generalize the statements "is generated by IKEv2" and "IKEv2 negotiations" to refer simply to IKE.

I glossed over some sections that aren't of significant interest to me.


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


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: ipsec@ietf.org
Date: 08/19/2009 02:05 PM
Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03




At 12:05 AM +0300 8/11/09, Yaron Sheffer wrote:
>This is the beginning of a two-week WG Last Call, which will end August 24.
>The target status for this document is Informational (to obsolete RFC 2411).
>The current document is at
>http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03.

That was a week ago.

>If you have not read the document before now, please do so. Having fresh
>eyes on the document often brings up important issues. This document is very
>much a survey, so please also review it for completeness: are there
>documents that should be mentioned but aren't. Send any comments to the
>list, even if they are as simple as "I read it and it seems fine".

And, so far, we have heard nothing. *This is bad.* This is a WG document: that means it needs to have rough consensus of the WG. Silence is not consent.

>Please clearly indicate the position of any issue in the Internet Draft, and
>if possible provide alternative text. 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.

...and do so within the next week.

If we do not get enough input during WG Last Call, we will have to reconsider how to handle this and future documents.

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

--=_alternative 0049D80185257619_=-- From root@core3.amsl.com Fri Aug 21 12: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 ACAA33A68BE; Fri, 21 Aug 2009 12: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: <20090821194501.ACAA33A68BE@core3.amsl.com> Date: Fri, 21 Aug 2009 12:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 19: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, H. Tschofenig Filename : draft-ietf-ipsecme-ikev2-resumption-07.txt Pages : 28 Date : 2009-08-21 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 encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and 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 examples are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-21124029.I-D@ietf.org> --NextPart-- From kohn.jack@gmail.com Fri Aug 21 15:23: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 C8D153A6359 for ; Fri, 21 Aug 2009 15:23:07 -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 lHc0F03-mBPw for ; Fri, 21 Aug 2009 15:23:06 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id AC7AE3A6977 for ; Fri, 21 Aug 2009 15:23:06 -0700 (PDT) Received: by gxk17 with SMTP id 17so1451738gxk.19 for ; Fri, 21 Aug 2009 15:23:08 -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=WoylgyaO/vrVICp5LI9xtETmUME5yH5X3m8Pnwf7bew=; b=CG/d3Z25DcLZ2Fi5mW4UQU0YAR3o6WH8s3o5rM+lUik2pPZvzVvk2KY3WxORc0OOe4 hxJkYJjyio3jFwPVCVRX3yZMmhIa6HQoy4/+u4ADhi6A7RLiffunv86leCqwu4OU+eh7 Yfhs/PJn506ivqnaMJvLgsSrXtU7xTQiU558U= 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=dWQ9KUlw8fjcxi4hAZ74u5nM37Iw5xPIRR9TSh3wvArFwS3lB1PMbGFcgjjPAts46w 0y5D7xi0Xlj8bH2wa7G/4HX9FYAqMppoU2MRJ5mYUAVQCs2MgUb9RnrjhA0Y7QRMs5Ky CApXI4P6PhUvPCZaRyrzoLtIzf76W/4X6Nrxg= MIME-Version: 1.0 Received: by 10.90.10.1 with SMTP id 1mr1313734agj.62.1250893058337; Fri, 21 Aug 2009 15:17:38 -0700 (PDT) In-Reply-To: <20090810234501.D0BF03A6E8C@core3.amsl.com> References: <20090810234501.D0BF03A6E8C@core3.amsl.com> Date: Sat, 22 Aug 2009 03:47:38 +0530 Message-ID: From: Jack Kohn To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=00163628351664eb640471ae3c2e Cc: paul.hoffman@vpnc.org, "Bhatia, Manav \(Manav\)" , "Grewal, Ken" , g_e_montenegro@yahoo.com Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 22:23:07 -0000 --00163628351664eb640471ae3c2e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe this draft had cleared the WG LC long time back. What else are the chairs/authors waiting for? Jack On Tue, Aug 11, 2009 at 5:15 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > > Title : Wrapped ESP for Traffic Visibility > Author(s) : K. Grewal, et al. > Filename : draft-ietf-ipsecme-traffic-visibility-07.txt > Pages : 14 > Date : 2009-08-10 > > This document describes the Wrapped Encapsulating Security > Payload (WESP) protocol, which builds on top of Encapsulating > Security Payload (ESP) [RFC4303] and is designed to allow > intermediate devices to ascertain if ESP-NULL [RFC2410] is being > employed and hence inspect the IPsec packets for network > monitoring and access control functions. Currently in the IPsec > standard, there is no way to differentiate between ESP > encryption and ESP NULL encryption by simply examining a packet. > This poses certain challenges to the intermediate devices that > need to deep inspect the packet before making a decision on what > should be done with that packet (Inspect and/or Allow/Drop). The > mechanism described in this document can be used to easily > disambiguate ESP-NULL from ESP encrypted packets, without > compromising on the security provided by ESP. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00163628351664eb640471ae3c2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe this draft had cleared the WG LC long time back. What else are th= e chairs/authors waiting for?

Jack

On Tue, Aug 11, 2009 at 5:15 AM, <Internet-Drafts@ietf.org> wrote:
A New Internet-Dr= aft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Wor= king Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Wrapped ESP for Traffic Visibil= ity
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : K. Grewal, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ipsecme-traffic-visibi= lity-07.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-08-10

This document describes the Wrapped Encapsulating Security
Payload (WESP) protocol, which builds on top of Encapsulating
Security Payload (ESP) [RFC4303] and is designed to allow
intermediate devices to ascertain if ESP-NULL [RFC2410] is being
employed and hence inspect the IPsec packets for network
monitoring and access control functions. =A0Currently in the IPsec
standard, there is no way to differentiate between ESP
encryption and ESP NULL encryption by simply examining a packet.
This poses certain challenges to the intermediate devices that
need to deep inspect the packet before making a decision on what
should be done with that packet (Inspect and/or Allow/Drop). The
mechanism described in this document can be used to easily
disambiguate ESP-NULL from ESP encrypted packets, without
compromising on the security provided by ESP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/dra= ft-ietf-ipsecme-traffic-visibility-07.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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


--00163628351664eb640471ae3c2e-- From yaronf@checkpoint.com Fri Aug 21 22:25: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 307623A68A9 for ; Fri, 21 Aug 2009 22:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 RUU6R4LLLFKq for ; Fri, 21 Aug 2009 22:25:42 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 524FA3A680E for ; Fri, 21 Aug 2009 22:25:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D760F29C002; Sat, 22 Aug 2009 08:26:08 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2E47C200456; Sat, 22 Aug 2009 08:26:08 +0300 (IDT) X-CheckPoint: {4A8F805B-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 n7M5Pi3d015416; Sat, 22 Aug 2009 08:25:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 22 Aug 2009 08:25:45 +0300 From: Yaron Sheffer To: Jack Kohn , "ipsec@ietf.org" Date: Sat, 22 Aug 2009 08:25:42 +0300 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-07.txt Thread-Index: AcoirTRnqVRsgGQwQdaeQivF367TsAAOR1wA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E1@il-ex01.ad.checkpoint.com> References: <20090810234501.D0BF03A6E8C@core3.amsl.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_002F_01CA2302.238DC200" MIME-Version: 1.0 Cc: "Bhatia, Manav \(Manav\)" , "Grewal, Ken" , "g_e_montenegro@yahoo.com" , "paul.hoffman@vpnc.org" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 05:25:44 -0000 ------=_NextPart_000_002F_01CA2302.238DC200 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0030_01CA2302.238DC200" ------=_NextPart_001_0030_01CA2302.238DC200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jack, I believe it is essential that both this draft and the ESP-null Heuristics draft contain language that clarifies how they relate to one another. I posted some text to the list on Aug. 11, and I am still awaiting approval from the Heuristics group of authors. When we have this point resolved, the draft is ready to move forward. Thanks, Yaron _____ From: Jack Kohn [mailto:kohn.jack@gmail.com] Sent: Saturday, August 22, 2009 1:18 To: ipsec@ietf.org Cc: Yaron Sheffer; Grewal, Ken; paul.hoffman@vpnc.org; g_e_montenegro@yahoo.com; Bhatia, Manav (Manav) Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-07.txt I believe this draft had cleared the WG LC long time back. What else are the chairs/authors waiting for? Jack On Tue, Aug 11, 2009 at 5:15 AM, wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-07.txt Pages : 14 Date : 2009-08-10 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-07 .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_001_0030_01CA2302.238DC200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Jack,

 

I believe it is essential that both = this draft and the ESP-null Heuristics draft contain language that clarifies = how they relate to one another. I posted some text to the list on Aug. 11, = and I am still awaiting approval from the Heuristics group of authors. When we = have this point resolved, the draft is ready to move = forward.

 

Thanks,

=

      =       Yaron

 

From: Jack = Kohn [mailto:kohn.jack@gmail.com]
Sent: Saturday, August = 22, 2009 1:18
To: ipsec@ietf.org
Cc: Yaron Sheffer; Grewal, Ken; paul.hoffman@vpnc.org; g_e_montenegro@yahoo.com; Bhatia, Manav (Manav)
Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-07.txt

 

I believe this = draft had cleared the WG LC long time back. What else are the chairs/authors = waiting for?

Jack

On Tue, Aug 11, 2009 at 5:15 AM, <Internet-Drafts@ietf.org>= wrote:

A New = Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions = Working Group of the IETF.


       Title           : = Wrapped ESP for Traffic Visibility
       Author(s)       : K. Grewal, = et al.
       Filename        : draft-ietf-ipsecme-traffic-visibility-07.txt
       Pages           : = 14
       Date           =  : 2009-08-10

This document describes the Wrapped Encapsulating Security
Payload (WESP) protocol, which builds on top of Encapsulating
Security Payload (ESP) [RFC4303] and is designed to allow
intermediate devices to ascertain if ESP-NULL [RFC2410] is being
employed and hence inspect the IPsec packets for network
monitoring and access control functions.  Currently in the = IPsec
standard, there is no way to differentiate between ESP
encryption and ESP NULL encryption by simply examining a packet.
This poses certain challenges to the intermediate devices that
need to deep inspect the packet before making a decision on what
should be done with that packet (Inspect and/or Allow/Drop). The
mechanism described in this document can be used to easily
disambiguate ESP-NULL from ESP encrypted packets, without
compromising on the security provided by ESP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-= traffic-visibility-07.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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

 

------=_NextPart_001_0030_01CA2302.238DC200-- ------=_NextPart_000_002F_01CA2302.238DC200 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyMjA1MjU0MlowIwYJKoZIhvcNAQkEMRYEFIkQljDUu3bb o1oH/ffN8JV2gIu5MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Dj7DZBJLVyjWvyHTDCURgxL2DjtMcgud6xOce72SVYoXe+gLEqvHUyZ4n/5W/nKvFfaTP3CNOGeC fqQ0TmvYrfyGTLIqoa//egRCF1srsO06qa67ySMrZYNMVCkNsx6t7SnxPqtayLdi4xOZHoSUO/5m UF+E/r1vWRljj9KsyYH9gxLZR0dgY/Z8DXLc2EmpBC2Y154M7VPkxKasdE4sBWC47wk2O7TyvgAc 5n5TApJBHSCrPKDJKpu0MEWTTGt3E0E9lFTl39n56motGQRUQeNg2949APYuIoWfQCVvwrWk8Bp4 gn0tkxCETBFBaZIzIg09oPB43baBlJc+KpqJVAAAAAAAAA== ------=_NextPart_000_002F_01CA2302.238DC200-- From ynir@checkpoint.com Sun Aug 23 22:46: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 2DF3B3A6A77 for ; Sun, 23 Aug 2009 22:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baBOWY4WkQtE for ; Sun, 23 Aug 2009 22:46:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id DC05A3A69B7 for ; Sun, 23 Aug 2009 22:46:28 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 61B4929C004; Mon, 24 Aug 2009 08:46:57 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 19DEA200E09; Mon, 24 Aug 2009 08:46:57 +0300 (IDT) X-CheckPoint: {4A922818-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 n7O5kW3d023641; Mon, 24 Aug 2009 08:46:33 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 24 Aug 2009 08:46:31 +0300 From: Yoav Nir To: "'Paul Hoffman'" , "ipsec@ietf.org" Date: Mon, 24 Aug 2009 08:46:31 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 Thread-Index: Acog95DbWU1cAon8T06+5rpCtAeG/gDhFZ9g Message-ID: <006FEB08D9C6444AB014105C9AEB133F906D312AD8@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD594E4@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A80B@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] WG Last Call: draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 24 Aug 2009 05:46:30 -0000 Sorry for the delay. I believe the draft is in good shape, but I do have some comments. 1. ESN is mentioned as optional for IKEv1 and included in IKEv2. It is not = mentioned that this is an optional feature for IPsec (both old and new) 2. Section 4.2.1 describes RFC 4478 (authentication lifetime). It says "Thi= s document defines a new informational message that...". Instead it should = say "This document defines a new status notification, that...". Also, after= "unless the initiator re-authenticates" I would add "within a specified pe= riod of time". 3. Section 5.6 describes cryptographic suites documents (RFC 4308 and 4869)= , including the algorithms these documents specify (encryption, data integr= ity and DH group). It does not mention the not-so-obvious fact that RFC 486= 9 also requires the use of ECDSA for public keys used for authentication (i= f public keys are used), whereas 4308 makes no such requirement. 4. Section 8.7 describes RoHC RFCs that relate to IPsec. I think it should = also mention the soon-to-be-published drafts about compressing IPsec traffi= c: - draft-ietf-rohc-ipsec-extensions-hcoipsec - draft-ietf-rohc-ikev2-extensions-hcoipsec - draft-ietf-rohc-hcoipsec In addition to these, a few nits: 1. The document capitalizes the name of the WG as IPsecme. I think we like = using IPsecME, no? 2. The descriptions of RFC 3947 and RFC 3948 are oddly placed. Both are in = section 3 (IPsec) although 3947 is about IKE, and yet they are separated ra= ther than following one another. I think that either 3947 should be moved t= o section 4 (IKE) or that they should be moved together. 3. RFCs 3947 and 4304 (ESN) are in section 3 (IPsec) but are more appropria= te for section 4 (IKE) 4. Section 4.2.3 describes dead peer detection. It should mention that RFC = 4306 (and the bis) call this feature "liveness check". Email secured by Check Point From kivinen@iki.fi Mon Aug 24 05:51: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 BF80A3A69E2 for ; Mon, 24 Aug 2009 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 7nuWRRJRl-R8 for ; Mon, 24 Aug 2009 05:51:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 868053A690E for ; Mon, 24 Aug 2009 05:51:06 -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 n7OCovtu015267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 15:50:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7OCouhE011967; Mon, 24 Aug 2009 15:50: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: <19090.36016.734818.51208@fireball.kivinen.iki.fi> Date: Mon, 24 Aug 2009 15:50:56 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@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" Subject: [IPsec] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 24 Aug 2009 12:51:08 -0000 Yaron Sheffer writes: > Hi, > > As we near publication of the WESP and Heuristics drafts, we'd like to make > sure that the WG consensus is clearly expressed in both documents. So we > propose to include the following note as a section in both documents. Please > let us know if this works for you: I think that applicability statement is good, and acceptable. Sorry about the delay for answering, but I wanted to re-read the draft-ietf-ipsecme-traffic-visibility draft once more before answering (my comments to it will follow). > Applicability: Heuristic Traffic Inspection and Wrapped ESP > ----------------------------------------------------------- > > There are two ways to enable intermediate security devices to distinguish > between encrypted and unencrypted ESP traffic: > > - The heuristics approach [heuristics I-D] has the intermediate node inspect > the unchanged ESP traffic, to determine with extremely high probability > whether or not the traffic stream is encrypted. > > - The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP > endpoints to be modified to support the new protocol. WESP allows the > intermediate node to distinguish encrypted and unencrypted traffic > deterministically, using a simpler implementation for the intermediate node. > > Both approaches are being documented simultaneously by the IPsecME Working > Group, with WESP being put on Standards Track while the heuristics approach > is being published as an Informational RFC. While endpoints are being > modified to adopt WESP, we expect both approaches to coexist for years, > because the heuristic approach is needed to inspect traffic where at least > one of the endpoints has not been modified. In other words, intermediate > nodes are expected to support both approaches in order to achieve good > security and performance during the transition period. > > -- end text > > [Note: both references are non-normative.] > > Currently both documents have direct or indirect references to one another, > but they are not exactly in line with the consensus we have reached. In both > cases the emphasis is on the two solutions competing with one another, > rather than complementing each other. So would this text be added to both documents or what? If so where (between section 2 and 3 in esp-null-heuristics and after or replacing section 1.2 of traffic-visibility draft)? -- kivinen@iki.fi From kivinen@iki.fi Mon Aug 24 06:03: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 207A228C1E1 for ; Mon, 24 Aug 2009 06:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJGALMJqBdpT for ; Mon, 24 Aug 2009 06:03:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EBDC628C1DD for ; Mon, 24 Aug 2009 06:03:06 -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 n7OD3BJK006290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 16:03:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7OD3BiH009992; Mon, 24 Aug 2009 16:03:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19090.36751.8910.15073@fireball.kivinen.iki.fi> Date: Mon, 24 Aug 2009 16:03:11 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-traffic-visibility@tools.ietf.org Subject: [IPsec] draft-ietf-ipsecme-traffic-visibility-07.txt 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, 24 Aug 2009 13:03:08 -0000 I now finished reading that traffic visibility draft and I have some minor nits for it. In section 2, when describing flags, it does not explictly give the bit order used when describing bits. I.e. is the version in bits 24-25 in the full 4-byte header, or bits 30-31. Adding those fields to the picture would make this clear, i.e. changing the Detailed WESP Packet Format picture to be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrLen | TrailerLen |V|V|I| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Existing ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or adding separate picture for flags, or adding similar text than what is in RFC4306 ("The bits are defined LSB first, so bit 0 would be the least significant bit of the Flags octet). Also in section 2 it says "2 bits: Version. MUST be sent as 0 and checked by the receiver. ", i.e. the version bit must be checked by the receiver, but it does not say what needs to be done if the version is different (most likely packet should be dropped, as version should have be negotiated already in the IKEv2). In the end of section 2 (second last paragraph) there is sentence saying "The receiver MUST drop packets for which the integrity check is invalid.". I think this sentence is confusing, as if it means that receiver must check the ICV field as normally IPsec, I do not think there is any need to say that again, as it is clear from normal IPsec processing, that packets with incorrect ICV are dropped. Especially as this is just after text about future versions of protocol, I first read it and started wandering if there is some separate integrity check that needs to be done or what. In section 4. IANA Considerations it says that: The final 6 bits of the WESP Flags are the "Non-version Flags". This specification defines no values, and future assignment is to be managed via the IANA Policy of "Specification Required". This is not correct, as it already defines one more bit, i.e. the "Encrypted Payload" bit in this document. -- kivinen@iki.fi From kivinen@iki.fi Mon Aug 24 06:47: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 573EA3A6E0B for ; Mon, 24 Aug 2009 06:47:23 -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.046, 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 e9vcrL7slxqm for ; Mon, 24 Aug 2009 06:47:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A2E853A6B52 for ; Mon, 24 Aug 2009 06:47: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 n7ODlHL3010860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 16:47:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7ODlGbH008500; Mon, 24 Aug 2009 16:47:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19090.39396.969252.312776@fireball.kivinen.iki.fi> Date: Mon, 24 Aug 2009 16:47:16 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B065@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B065@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 40 min X-Total-Time: 41 min Cc: "ipsec@ietf.org" Subject: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 24 Aug 2009 13:47:23 -0000 Yaron Sheffer writes: > - Sec. 5. In the definition of IPsec flows, how is this done for (typically > tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow > definition? This text belongs either here or in Sec. 8. Adding port numbers as part of the flow table might make some extra flows in case the NAT box is rebooted and port numbers change, but it is also safer assumption to do, as in case there is multiple clients behind the same NAT box talking to the same SGW, the port numbers is the only thing that differentiates those clients from each other. I added text to section 8 saying "Each unique port pair makes separate IPsec flow, i.e. UDP encapsulated IPsec flows are identified by the source and destination IP, source and destination port number and SPI number". > - 5. "Unsure" - if we choose the option of dropping such packets, are there > cases when retransmitted packets do not add any information and we will > remain forever "unsure"? It depends. If the packet is really encrypted ESP, then no, as each retransmission will have different IV, which means every packet will completely different, and that will make the heuristics to find out that flow is not ESP-NULL (i.e. Self describing padding checks will fail). If packet is ESP-NULL packet and is about known protocol (TCP/UDP) then simple checks given in the pseudocode work, i.e. we check that the source and destination port numbers are same for the retransmitted packet, and each of those will add some bits to the "Check_Bits" value, and when it reaches the threshold set in the policy the flow is recognized as ESP-NULL with given parameters. The problem case is that if only packets sent by the flow are of some unknown protocol, then heuristics cannot determine whether any of the fields in the protocol data are correct, thus it cannot determine the IV length. Even in this case the flow can be recognized as ESP-NULL packet with known ICV length, but unknow IV length if we get consistent next header fields in retrasmitted packets (as described at the end of section 9.2). > - 6, first paragraph. in to -> into Fixed. > - 6. This section seems to discuss the construction of an ESP-null detection > engine out of an off-the-shelf DPI engine. If this is the case, please say > so. The section describes relationship between the deep inspection engine and the heuristics, it is not necessarely related to the existing or off-the-shelf DPI engines. > - 9.1. 160, 192, and 256 bit algorithms are used -> 160, 192, and 256 field > lengths are used Fixed. > - 9.1. "Payload Data" is starred for some reason, probably cut-and-paste. Fixed. > - 10. The Security Considerations needs to have an explanation of what this > is good for, i.e. what security policy is enforced, what kind of DPI is > done. Also, (malicious) traffic can be encrypted in multiple ways, e.g. > simply by using TLS on top of TCP. One of the problems with using ESP-NULL is that I myself do not think there is really any good uses for it. The attackers can bypass it so easily by using encryption that I do not really know what kind of security policies can be enforced with it (unless you use disallow encrypted ESP compeltely, in which case heuristics come trivial). This is the main reason I do not see that WESP or heuristics will ever really get widely used anywhere. My reason for heuristics is that for those who want this kind of thing and who can explain themselves why they want it can implement them without messing up the IPsec implementations :-) The security considerations section already says that "The whole deep inspection for ESP-NULL flows only has the problem that attacker can always bypass it by using encrypted ESP instead of ESP-NULL unless that is not forbidden by policy." Changed that now to be: "The whole deep inspection for ESP-NULL flows only has the problem that attacker can always bypass it by using encrypted ESP (or some other encryption or tunneling method) instead of ESP-NULL unless that is not forbidden by policy." so that should cover TLS over TCP, or IP over DNS etc style bypassing methods... > In addition, we need to note the DOS potential of the ESP-null > detection process. Do we really? I think it is clear that any protocol can have bugs and implementation issues, but we do not list that in every single security considerations section (i.e. IKEv2 or AH or ESP). The DoS potential of the ESP-null detection is not any different than DoS potential of the IKEv2 implementation or ESP itself. > - Pseudocode: are we assuming one protocol per SPI? No. There can be multiple protocols going through the same SA. In some cases it is more efficient if multiple TCP packets are sent during detection process, but it works even if they come mixed in any way (i.e. when it checks if the last packet received had same TCP/UDP source/destination ports etc that is more efficient if the last packet really was part of same TCP/UDP flow than this current packet, but that is not required for correct operation). > At a higher level, shouldn't we have processing for tunnel mode ESP > as well? Yes, but to make pseudocode bit shorter, I left those out. As the description of "Example Pseudocode" says "It does not include all the required checks, and this is just example pseudocode". Section 9.3.5. describe what kind of checks can/should be done for the IPv4/IPv6 tunnel mode. As the introduction section says that "Because the traffic inspected is usually host to host traffic inside one organization, that usually means transport mode IPsec is used." and because of this I left those tunnel mode checks out from the pseudocode. Also firewall / deep inspection engine implementors usually have very good set of IPv4 and IPv6 header checks already in their products, so they can reuse those. Added comment about that to the pseudocode. > - Pseudocode: retreaved -> retrieved Fixed. -- kivinen@iki.fi From yaronf@checkpoint.com Mon Aug 24 07:07: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 1318028C1BA for ; Mon, 24 Aug 2009 07:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 Ky0riN7W+zvd for ; Mon, 24 Aug 2009 07:07:42 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 39EC03A6E4F for ; Mon, 24 Aug 2009 07:07:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 27B9429C005; Mon, 24 Aug 2009 17:08:10 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E3D3929C002; Mon, 24 Aug 2009 17:08:09 +0300 (IDT) X-CheckPoint: {4A929D8A-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 n7OE7j3d017986; Mon, 24 Aug 2009 17:07:45 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 24 Aug 2009 17:07:44 +0300 From: Yaron Sheffer To: Tero Kivinen Date: Mon, 24 Aug 2009 17:07:43 +0300 Thread-Topic: [IPsec] Relating the two ESP-null documents Thread-Index: AcokuYm3a02Vf625RKWTOKRdHYLnCQACi5tw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B5FB@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@il-ex01.ad.checkpoint.com> <19090.36016.734818.51208@fireball.kivinen.iki.fi> In-Reply-To: <19090.36016.734818.51208@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_00AC_01CA24DD.651BE620" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 24 Aug 2009 14:07:43 -0000 ------=_NextPart_000_00AC_01CA24DD.651BE620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, Thanks for approving this text. I was expecting each draft's editor team to decide where to add it into their draft. Best, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, August 24, 2009 15:51 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: [IPsec] Relating the two ESP-null documents > > Yaron Sheffer writes: > > Hi, > > > > As we near publication of the WESP and Heuristics drafts, we'd like to > make > > sure that the WG consensus is clearly expressed in both documents. So we > > propose to include the following note as a section in both documents. > Please > > let us know if this works for you: > > I think that applicability statement is good, and acceptable. > > Sorry about the delay for answering, but I wanted to re-read the > draft-ietf-ipsecme-traffic-visibility draft once more before answering > (my comments to it will follow). > > > Applicability: Heuristic Traffic Inspection and Wrapped ESP > > ----------------------------------------------------------- > > > > There are two ways to enable intermediate security devices to > distinguish > > between encrypted and unencrypted ESP traffic: > > > > - The heuristics approach [heuristics I-D] has the intermediate node > inspect > > the unchanged ESP traffic, to determine with extremely high probability > > whether or not the traffic stream is encrypted. > > > > - The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP > > endpoints to be modified to support the new protocol. WESP allows the > > intermediate node to distinguish encrypted and unencrypted traffic > > deterministically, using a simpler implementation for the intermediate > node. > > > > Both approaches are being documented simultaneously by the IPsecME > Working > > Group, with WESP being put on Standards Track while the heuristics > approach > > is being published as an Informational RFC. While endpoints are being > > modified to adopt WESP, we expect both approaches to coexist for years, > > because the heuristic approach is needed to inspect traffic where at > least > > one of the endpoints has not been modified. In other words, intermediate > > nodes are expected to support both approaches in order to achieve good > > security and performance during the transition period. > > > > -- end text > > > > [Note: both references are non-normative.] > > > > Currently both documents have direct or indirect references to one > another, > > but they are not exactly in line with the consensus we have reached. In > both > > cases the emphasis is on the two solutions competing with one another, > > rather than complementing each other. > > So would this text be added to both documents or what? If so where > (between section 2 and 3 in esp-null-heuristics and after or replacing > section 1.2 of traffic-visibility draft)? > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00AC_01CA24DD.651BE620 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNDE0MDc0M1owIwYJKoZIhvcNAQkEMRYEFNIiQXPqH/gO 4BdPfqkdcqJEq15eMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA oDkPvNJacACA1WSURb12NYWfgWAAfpQ76DI3Lysqj/m/kkz3Q9vWBGBKUj6IDk1g6G00Mgu/kX+k hQndEa4iI5t//O/wf9jf6WzxKKoJ7qC8dT64fPAnHdpzcs2xJ698ziee7W/laN7+ynIKr3nG9u/+ 9K5bz654en74RopOJyU+H+VWrzj9chquS/Nx/smrT8jLvVEopc3hKJuImSt2cOVueFVbIj4KTWjQ KcaKnjNRHqKB9jdi/kyL6BoDTWNoNuXpkj5sxZ9x/VBUbuKgsCy8aqrZISZb9pkVcYowAvGAmX8Y GlDyxw5fk32TtblMLkWn8xX0y8DnnaWl+XDyhQAAAAAAAA== ------=_NextPart_000_00AC_01CA24DD.651BE620-- From yaronf@checkpoint.com Mon Aug 24 09:52: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 2279A3A6A1E for ; Mon, 24 Aug 2009 09:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 itdBg5CJMZ0k for ; Mon, 24 Aug 2009 09:52:53 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 76DCA3A69EC for ; Mon, 24 Aug 2009 09:52:52 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E670729C002; Mon, 24 Aug 2009 19:53:17 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9B5E2200E09 for ; Mon, 24 Aug 2009 19:53:17 +0300 (IDT) X-CheckPoint: {4A92C43C-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 n7OGqr3d008651 for ; Mon, 24 Aug 2009 19:52:53 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 24 Aug 2009 19:52:51 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 24 Aug 2009 19:52:51 +0300 Thread-Topic: Comments on draft-ietf-ipsecme-roadmap-03 Thread-Index: Acok21CbLavv0hGyREKWbklR8BCScA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B618@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_00DD_01CA24F4.76AA1A80" MIME-Version: 1.0 Subject: [IPsec] Comments on draft-ietf-ipsecme-roadmap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 24 Aug 2009 16:52:54 -0000 ------=_NextPart_000_00DD_01CA24F4.76AA1A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - draft-ietf-ipsecme-ikev2-ipv6-config is no longer on the Standards Track. - KINK and BTNS should be all-caps. Similarly MOBIKE. - 3.1: "IPsec protections are provided by two extension headers" - this is true for IPv6, I don't think the term is applicable to IPv4. - In fact, it would be nice if Sec. 3 mentioned that IPsec and IKE apply equally to IPv4 and IPv6. It may be trivial to IPsec folks, but it isn't really. - I would have liked to see ESP BEET mode referenced, since it's more widely implemented than other docs that we do mention. But as far as I know it is not on track to becoming an RFC. - "Requirements levels for RFC3715" are meaningless - this is a requirements document. - 4.1.1: the relation of IKEv1 and Oakley, as described here, is confusing. Because the Oakley *document* is informational, so you only need to read the other 3 docs as an implementer. - 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines the use of ESN in IKEv1? But you can't expect a Roadmap document to resolve all issues. - 4.2.3: "dead peer detection (DPD) is an integral part of IKEv2", but now renamed to "liveness test" or "liveness check". - 4.2.4: why say that session resumption "requires changes to IKEv2"? It is an extension like many others. Similarly for the Redirect draft. - 4.2.4: typo in the reference: psecme-2. - 5.2: please add a reference to the new AES-CTR document (also requires to change Table 2). - 5.4.1: shouldn't we mention that RFC 5282 is based on a more generic AEAD framework (RFC 5116)? - 5.6: please define what is "Suite B" (a newcomer would be confused by the different uses of the word "suite" here). - 6: typo: "[RFC5197] provides in in-depth". - 7.3: Sec. 1 of RFC 5386 makes it clear that it does *not* apply to IKEv1, or at least cannot be applied to all implementations. In addition, there is great confusion surrounding the term "unauthenticated security associations" in the BTNS context, but the IPsec Roadmap is not the place to deal with this issue. - 7.4: I wouldn't say KINK is *another* attempt to provide an alternative, because BTNS is not an alternative, it is just an IKE (and RFC4301) tweak. - 7.5: I would describe the history differently (I was there...). IPSRA attempted to tack user authentication onto IKEv1 with no change to IKE. This indeed proved cumbersome, and the result was the brand new IKEv2, which in fact adopted some of the IPSRA ideas, primarily the use of EAP. - 8.3: this section could be improved by explaining what HIP is. It is fashionable ("hip") to quote Wikipedia, so here goes: The Host Identity Protocol (HIP) is a host identification technology for use on Internet Protocol (IP) networks, such as the Internet. The Internet has two main name spaces, IP addresses and the Domain Name System. HIP separates the end-point identifier and locator roles of IP addresses. It introduces a Host Identity (HI) name space, based on a public key security infrastructure. - 8.3: typo: "for for describing". - The description of RFC5206 has mismatched parenthesis. - 8.7: I agree with Yoav we should include the "almost published" ROHC documents. - Table 1: There is nothing that limits the Heuristics draft to ipsec-v3. In facts legacy devices are a major reason for publishing these heuristics. Thanks, Yaron ------=_NextPart_000_00DD_01CA24F4.76AA1A80 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNDE2NTI1MVowIwYJKoZIhvcNAQkEMRYEFEEhUlfGhoOh UZkWEUQKI+ErMZdrMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ai2nM6l2kf8V22/f+deHvYXjNshHtHLt8+Rj2VBbOSFCe5yDP+xhvfMZ9cM7OL4M7zDF012NIsOY ylj1IA+Y+YKIvWAas4KmPz9t34kX1mIiFyIWb6124gipJosynDFMuGDEl0nIHnOa21DZfIQH3SAb whKp+TufuEblsTdKK1uoNsTryGJBMn7S2S5ZuvsWWZJRT948q36mec/wr8nFsSredxiL9l80gjKE O0n62rMTIRfQhT7LTIu/QhRJo+XfjyzgJvfUWKj+2Rr7EDaUyoRIbrxZgq7zxSwIytQ0F5GITGrD M/7wXq1C7hRGJxAqvA+S9x0Ghrv3Lc5RZG1vuwAAAAAAAA== ------=_NextPart_000_00DD_01CA24F4.76AA1A80-- From paul.hoffman@vpnc.org Mon Aug 24 10: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 32D1928C1DC for ; Mon, 24 Aug 2009 10:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=1.427, 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 WTWxksHmVvb5 for ; Mon, 24 Aug 2009 10:09:52 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5A6D33A68DD for ; Mon, 24 Aug 2009 10:09:52 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7OH9sjL022639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 10:09:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19090.36016.734818.51208@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@il-ex01.ad.checkpoint.com> <19090.36016.734818.51208@fireball.kivinen.iki.fi> Date: Mon, 24 Aug 2009 10:09:53 -0700 To: Tero Kivinen , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Relating the two ESP-null documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 24 Aug 2009 17:09:53 -0000 At 3:50 PM +0300 8/24/09, Tero Kivinen wrote: >So would this text be added to both documents or what? It should go in both. That way, an implementer a year from now who comes across one of the RFCs will both find out about the other and be clear on the relationship. >If so where >(between section 2 and 3 in esp-null-heuristics and after or replacing >section 1.2 of traffic-visibility draft)? My preference for esp-null-heuristics is that this applicability statement be section 1.1, and that what is now section 2 (the 2119 language) become section 1.2. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Tue Aug 25 14:23:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFDF3A700A for ; Tue, 25 Aug 2009 14:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.343, 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 rz0XmVLy7TDE for ; Tue, 25 Aug 2009 14:23:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id BAF573A6A32 for ; Tue, 25 Aug 2009 14:23:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E64E29C007; Wed, 26 Aug 2009 00:23:26 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 69594200E09 for ; Wed, 26 Aug 2009 00:23:26 +0300 (IDT) X-CheckPoint: {4A9454F7-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 n7PLN13d025405 for ; Wed, 26 Aug 2009 00:23:02 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 00:23:00 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 26 Aug 2009 00:22:59 +0300 Thread-Topic: #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Thread-Index: Acolx8tTM5jUk3sNR/yL4Khw93j8FQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@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_00CD_01CA25E0.F0A779D0" MIME-Version: 1.0 Subject: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 21:23:32 -0000 ------=_NextPart_000_00CD_01CA25E0.F0A779D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CE_01CA25E0.F0A779D0" ------=_NextPart_001_00CE_01CA25E0.F0A779D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [2.23, NAT Traversal] > o Implementations MUST process received UDP-encapsulated ESP packets > even when no NAT was detected. > > o The original source and destination IP address required for the > transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) > are obtained from the Traffic Selectors associated with the > exchange. In the case of NAT traversal, the Traffic Selectors > MUST contain exactly one IP address, which is then used as the > original IP address. Tero: Getting original source and destination IP address from the traffic selectors do not really work currently. Especially when combined with the selectors from the packet and when responder is behind nat or similar problems. Paul: Not done. Specify replacement text and discuss on the mailing list. People who care about Transport Mode are requested to help resolve this NAT Traversal issue. Thanks, Yaron ------=_NextPart_001_00CE_01CA25E0.F0A779D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[2.23, NAT Traversal]

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

>        even = when no NAT was detected.

> 

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

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

>        are = obtained from the Traffic Selectors associated with the

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

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

>        = original IP address.

 

Tero:

 

Getting original source and destination IP address = from the traffic

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

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

similar problems.

 

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

 

People who care about Transport Mode are requested to = help resolve this NAT Traversal issue.

 

Thanks,

         =    Yaron

------=_NextPart_001_00CE_01CA25E0.F0A779D0-- ------=_NextPart_000_00CD_01CA25E0.F0A779D0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNTIxMDUzN1owIwYJKoZIhvcNAQkEMRYEFDnsFHkhJ6I8 42j7lFs1uOXuxT18MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA lsrw1TLhPsAJd+FP63GleFIxIOn+Pi4T8SHp/P2lvnmqu4se2Q6jxMxTmQyA64UFVoxzKuRPbHbb ++mF+llUfaQI50Wi+iV6E/yfv3r5GNDCvBjDQEuybdoh9YoNX/dgb1zhWqjV1CQGfzEdqjv/yrbG VrGcuZqkEBzU0kob+7CXeSenL9aSSmydPKymG8dEnHu8NOueNY85xfFkFDV1TtuFXeFf3c9x176h 92HWVs5kwFWxRmnYJUzIDk0OiRR2wotrKrnBDnMzsi4lpamJ2mFRb8Ro75u/tFwnKuodvewDp0cR GRlUkTfL7vAVr/vHOAsSAZ8UDBgij9Oweu3uSwAAAAAAAA== ------=_NextPart_000_00CD_01CA25E0.F0A779D0-- From yaronf@checkpoint.com Tue Aug 25 14:23: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 31D943A6FFF for ; Tue, 25 Aug 2009 14:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_20=-0.74, 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 1pWHuv7DOcak for ; Tue, 25 Aug 2009 14:23:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8C6CA3A68C2 for ; Tue, 25 Aug 2009 14:23:00 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 973DA29C004; Wed, 26 Aug 2009 00:23:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5296B200E09 for ; Wed, 26 Aug 2009 00:23:22 +0300 (IDT) X-CheckPoint: {4A9454F3-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 n7PLMv3d025379 for ; Wed, 26 Aug 2009 00:22:58 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 00:22:56 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 26 Aug 2009 00:22:33 +0300 Thread-Topic: More ikev2-bis issues Thread-Index: AcolxXOamXXE5pRFQQWy3yP2p1E89w== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617AF@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_0122_01CA25E3.4E03B470" MIME-Version: 1.0 Subject: [IPsec] More ikev2-bis 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: Tue, 25 Aug 2009 21:23:33 -0000 ------=_NextPart_000_0122_01CA25E3.4E03B470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0123_01CA25E3.4E03B470" ------=_NextPart_001_0123_01CA25E3.4E03B470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I will now post several of the remaining "bis" issues. I would appreciate your replies before Sep. 1. We have only 9 issues left, so we are really getting close to Last Call on this important document. Thanks, Yaron ------=_NextPart_001_0123_01CA25E3.4E03B470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I will now post several of the remaining = “bis” issues. I would appreciate your replies before Sep. 1. We have only 9 = issues left, so we are really getting close to Last Call on this important = document.

 

Thanks,

         =    Yaron

------=_NextPart_001_0123_01CA25E3.4E03B470-- ------=_NextPart_000_0122_01CA25E3.4E03B470 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNTIxMjIzM1owIwYJKoZIhvcNAQkEMRYEFHe84C+36PMM bTzLSAu1d9dzERhzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA aOjo8JqRMBPUFm9pB2PRtDPJf4FXrBMIym/eWnIhf32EckMHMuwdtXOEnwSiZDDnN1b9Jnemkj+b YHFqvCgTRJKQ6wZzkfK/H/0tNyISF6IQQtTyxvcCgDsqRax3vNMIs6Z9wuaJ5tPRnrq35FwXFr/r DUJO2dTlotOtCjgVswdvVvTxRdhE15VniqNutBvtu4xDwue/TES19eN0eqdEtRXqc9UGZvP3lCk7 goLd0jJbthDP8mHpVK1weFLH7DMKAMttwaGgQZNbpgkvCtwrwvnrd1ud+tt5abpt8bG4fiqV11Xq 8EvtfJKggMji+vlWuq/WWt30vJFBgED2bN/suwAAAAAAAA== ------=_NextPart_000_0122_01CA25E3.4E03B470-- From yaronf@checkpoint.com Tue Aug 25 14:23: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 3F5EC3A6A55 for ; Tue, 25 Aug 2009 14:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_20=-0.74, 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 AJSVhHekT5L0 for ; Tue, 25 Aug 2009 14:23:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 14FF33A6A89 for ; Tue, 25 Aug 2009 14:23:04 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7D3B5200E0F; Wed, 26 Aug 2009 00:23:28 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4C868200E09 for ; Wed, 26 Aug 2009 00:23:28 +0300 (IDT) X-CheckPoint: {4A9454F9-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 n7PLN33d025415 for ; Wed, 26 Aug 2009 00:23:04 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 00:23:02 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 26 Aug 2009 00:23:00 +0300 Thread-Topic: #79: Remove CP from Create_Child_SA? Thread-Index: AcolyMQq9n8TZkPbQeWuTriGCYMdmw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@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_00DD_01CA25E1.E97EC8B0" MIME-Version: 1.0 Subject: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 21:23:35 -0000 ------=_NextPart_000_00DD_01CA25E1.E97EC8B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00DE_01CA25E1.E97EC8B0" ------=_NextPart_001_00DE_01CA25E1.E97EC8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that "request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as "RESERVED". Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav's proposal. This would be a protocol change (even if we don't understand what the current semantics is.), so we shouldn't do it unless we're quite sure. Thanks, Yaron ------=_NextPart_001_00DE_01CA25E1.E97EC8B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yoav:

 

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

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

 

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

 

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

 

 

Everyone, please comment on the above, even if you = support Yoav’s proposal. This would be a protocol change (even if we don’t = understand what the current semantics is…), so we shouldn’t do it unless = we’re quite sure.

 

Thanks,

         =    Yaron

 

------=_NextPart_001_00DE_01CA25E1.E97EC8B0-- ------=_NextPart_000_00DD_01CA25E1.E97EC8B0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNTIxMTIzNFowIwYJKoZIhvcNAQkEMRYEFM9MgJuXtkuY Z1nPsaK487BvpeItMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA tw1zxRxq0J2JtLlJXamOTe0lbSRmw5soutOvxScyoU2RKhc3XREUJeTxcUdWCXV90C037xZE9yOu ddq2FiHR675urMYZTUaUxkSmHjPpK4/dxwNLLpsEix1XRfUDK4CMp3Y4dlLQzo+vg1enJyJI6/wM 8I5qCnvZIAnYg3Dv/2OqIS8v05Fq13rtzpKf6POoyTJ0Z9gRDDyi4pUeZr6xl2cta0hf6yUPjm39 uNIGdsud2Xn3+sZEI0N6r9ldhvtk1NeS0NeqZZy6CkddjZCLSIApyfq1DtgJXDJ0ykh9EDJbDsZo iY1lfHKleVQdPgovCWlMoiTukkLOPFnllt5fvAAAAAAAAA== ------=_NextPart_000_00DD_01CA25E1.E97EC8B0-- From yaronf@checkpoint.com Tue Aug 25 14:46: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 7A7623A6FFE for ; Tue, 25 Aug 2009 14:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.392, 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 pcwY52l5PTsC for ; Tue, 25 Aug 2009 14:46:10 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9C5E73A700B for ; Tue, 25 Aug 2009 14:46:09 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5934829C00A; Wed, 26 Aug 2009 00:23:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 271A3200E09 for ; Wed, 26 Aug 2009 00:23:29 +0300 (IDT) X-CheckPoint: {4A9454F9-4-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7PLN33f025415 for ; Wed, 26 Aug 2009 00:23:04 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 00:23:02 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 26 Aug 2009 00:23:01 +0300 Thread-Topic: #107: Sending certificate chains in IKEv2 Thread-Index: AcolyXw3Tmjw3og6QJqm/GJsSHck4Q== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@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_00ED_01CA25E2.A18B7BB0" MIME-Version: 1.0 Subject: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 21:46:11 -0000 ------=_NextPart_000_00ED_01CA25E2.A18B7BB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00EE_01CA25E2.A18B7BB0" ------=_NextPart_001_00EE_01CA25E2.A18B7BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yoav says: Section 3.6 ("Certificate Payload") describes sending certificates in the IKE_AUTH exchange. The usual format for sending certificates is #4 (X.509 Certificate - Signature). Here's what it says: {{{ 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 the singular) The last paragraph says: {{{ Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication... ...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. }}} What this doesn't say is how we send this chain of certificates. Is it multiple separate CERT payloads (in that case it should say so) or is it a single CERT payload (and then we should also say so) Input from actual implementations (and bakeoffs) will be most valuable here. Thanks, Yaron ------=_NextPart_001_00EE_01CA25E2.A18B7BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yoav says:

 

Section 3.6 ("Certificate Payload") = describes sending certificates in the IKE_AUTH exchange.  The usual format = for sending certificates is #4 (X.509 Certificate - Signature). Here's what it = says:

 

 

{{{

   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 the singular)  The last paragraph = says:

 

 

{{{

   Implementations MUST be capable of being = configured to send and

   accept up to four X.509 certificates in = support of authentication...

   ...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.

}}}

 

What this doesn't say is how we send this chain of certificates.  Is it multiple separate CERT payloads (in that case = it should say so) or is it a single CERT payload (and then we should also say = so)

 

 

Input from actual implementations (and bakeoffs) will = be most valuable here.

 

Thanks,

         =    Yaron

------=_NextPart_001_00EE_01CA25E2.A18B7BB0-- ------=_NextPart_000_00ED_01CA25E2.A18B7BB0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNTIxMTc0M1owIwYJKoZIhvcNAQkEMRYEFKpMWcLC6bF7 g+/js2q0wr+qR86TMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA MHh3oQqRootjWb4rPjyYpKjhaH2LBMpf88+J5Gyp8sbDWHv3DxU1GOGtLCQoakYx3WMiHi8GQhmW AgmPpxgj9k33on8BUqw/Cp6iE6JDCHpKwZEcpHE/WB5UUTLn8HyU+qcvTuRLZpwpZAKrghRS2KIB Yn8lzorDpViUxvtQPBG19skgaSH/dqhCc8H1j0JKL0vTH4fJnL9ZM580jxMEJCy+W0DhBTJw1lQm e7v0ABGYbavAIgX/JQtHiHFQRoCxlMNZkTVQfyBfOzCSJBNNVz7Qgsl15Naqzu96CZ4RX2/QKOal Iv7fgkM65ZIMOOmU9bozHfAyKSt3MHm+FjceAQAAAAAAAA== ------=_NextPart_000_00ED_01CA25E2.A18B7BB0-- From yaronf@checkpoint.com Tue Aug 25 15:19: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 5FB433A6F38 for ; Tue, 25 Aug 2009 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 xC582CUEKNiH for ; Tue, 25 Aug 2009 15:19:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D5B103A6ACC for ; Tue, 25 Aug 2009 15:19:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DB8E729C005; Wed, 26 Aug 2009 00:23:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AD7DC200E09 for ; Wed, 26 Aug 2009 00:23:22 +0300 (IDT) X-CheckPoint: {4A9454F3-2-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7PLMv3e025379 for ; Wed, 26 Aug 2009 00:22:58 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 00:22:56 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 26 Aug 2009 00:22:56 +0300 Thread-Topic: #22: Add section on simultaneous IKE SA rekey Thread-Index: Acolxj5uv+eIQO2OT+yyF2jrTmJkqg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B0@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_00C0_01CA25DF.63BFF660" MIME-Version: 1.0 Subject: [IPsec] #22: Add section on simultaneous IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 22:19:41 -0000 ------=_NextPart_000_00C0_01CA25DF.63BFF660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: 2.8.1. Simultaneous CHILD_SA rekeying Instead of simultaneous CHILD_SA rekeying, there should be section of simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just results few extra SAs that will disappear after next rekeys (at worst there will be 2 SA pairs, but all others will be deleted instead of being rekeyed as they are not used. The simultaneous IKE SA rekeying is much more important case to get correct, as both ends MUST agree on which IKE SA survive, as otherwise they will move the CHILD SA to wrong IKE SA and their state is completely messed up after that. This section should also explain that even if the simultaneous rekeying of IKE SA is noticed only AFTER the whole rekeying is already finished, both ends MUST still correctly detect it and act based on the fact which IKE SA will survive. This means that the old IKE SA should not be deleted too quickly after the IKE SA rekey finished, just in case there happened to be simultaneous rekey in progress. The one doing the delete should wait at least few minutes before deleting the old IKE SA, so it can be sure that other end does not have simultaneous rekey going on the IKE SA. Paul: Not done. More specific text is needed. This is interesting, but should be discussed on the list. There was a long discussion of this issue in the past, see some pointers here: http://www.ietf.org/mail-archive/web/ipsec/current/msg03516.html. We would appreciate proposed text for such a new section. Thanks, Yaron ------=_NextPart_000_00C0_01CA25DF.63BFF660 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNTIwNTQzMVowIwYJKoZIhvcNAQkEMRYEFATnuBh1lyAV SzAzCyph9REIb1MpMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA pwkrb/LMEqTWOpQ5hVJ6YrksjEUFvVRFuEMUC1udSSmK+4jCbdkTTtjsicxH5vcRO+L69TE9GUV8 Vx0LM8ADQdAiEKbyW8qNTeAcMlxD95SaPHS0tZ9i8GSYQMsT+MIeltrMTRXQENu+o8xGPXiK8EXr s/stx943nrJSHb4LTnFa/wUYPEtg7ZHZrm/QR4slm6boSXDHjOCYifS4I/ld6e9oi8jvc2swPDHN Q9UmeFvHmAO9O7Cx37m8Rdx0lZX4gaDIYvdMdT2glZznrATwKGFPuN2bDF4KjtJuswIaCMW1SAh1 6ukHnOZ0MeuoIUNmMEUgj2b5IYM8Pf8kZ3WtSgAAAAAAAA== ------=_NextPart_000_00C0_01CA25DF.63BFF660-- From rsjenwar@gmail.com Tue Aug 25 20:08: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 154423A7038 for ; Tue, 25 Aug 2009 20:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.218, 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 2bo3-Dbg4k0X for ; Tue, 25 Aug 2009 20:08:32 -0700 (PDT) Received: from mail-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by core3.amsl.com (Postfix) with ESMTP id 92FA428C3ED for ; Tue, 25 Aug 2009 20:07:58 -0700 (PDT) Received: by pxi5 with SMTP id 5so6443583pxi.6 for ; Tue, 25 Aug 2009 20:08:01 -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=yk5R+uBoKVtlXZQJ78zoREKSoloKZfIbvtHcy5ACDBI=; b=n/sMwwiquis7gj8CGnalTaVjGhJ+HN0sOJOTh8HacvswwBubtZqDHbgmFp6Q7EGBQo vFg9BzS96m1M0raqi01fWl+xVCrYd1NH54qXRBKfuPNV1KjMKpQjIDsm4uBpKWmSpxQL IrbNeSQy1OHGE7uqDwxx5g10Gq9z9mewYDCEc= 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=UawBjkSYSb3tgvMCMdaV1HQ+myGo7BWdsdww1WWCYSwV00liadt5Xuc/kv7Zmo/9iR gs+IJ6wQVp9RscjWoYIJLjuzIpGWGhsFTQ4LNpKHla00a2zh7oDeqPPZ+QgHcnRYFhE4 o4SNLUTVPWtabWQl9//d1/X6ZvEdPJQLTaP+A= MIME-Version: 1.0 Received: by 10.142.249.18 with SMTP id w18mr73462wfh.26.1251256081638; Tue, 25 Aug 2009 20:08:01 -0700 (PDT) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> Date: Wed, 26 Aug 2009 08:38:01 +0530 Message-ID: <7ccecf670908252008v15aa4b54ldb25dbef1e7e0986@mail.gmail.com> From: Raj Singh To: Yaron Sheffer Content-Type: multipart/alternative; boundary=00504502ca7144e4cd047202c218 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 03:08:33 -0000 --00504502ca7144e4cd047202c218 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron, Also, there are use cases when application needs more than 1 IP address for internal purpose. With current ikev2bis, this is possible as we can request address after session establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange. If we say that we want to support in ONLY IKE_AUTH. Are we going to stop supporting CP payload via INFORMATION exchange ? Thanks & Regards, Raj On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer wrote= : > Yoav: > > > > Patricia noted in a post to the IPsec mailing list (12/12/2008) that > section 2.19 says that "request for such a temporary address can be inclu= ded > in any request to create a CHILD_SA (including the implicit request in > message 3) by including a CP payload." > > IMO the normal way of doing things is in this message 3, so rather than a > parenthetical remark, it's really the only one anyone uses. I don't thin= k > it makes sense to assign a different IP address for each SA, and I don't > think anyone actually intended for this to be implied. > > > > In RFC 4306, section 3.15, one of the attributes that can be sent in the = CP > payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time > before the client needs to renew the address with the gateway (probably > renew the lease with a DHCP server). With such an attribute, it made sens= e > for the client to renew the address along with rekeying some CHILD_SA. > > > > In the bis document, we've deprecated this attribute, and it is now marke= d > as "RESERVED". Since we've done that, I suggest we remove the CP payload > from the Create Child SA exchange in appendix A, and reword section 2.19 = to > reflect that requesting an IP address is only acceptable during IKE_AUTH. > > > > > > Everyone, please comment on the above, even if you support Yoav=E2=80=99s= proposal. > This would be a protocol change (even if we don=E2=80=99t understand what= the > current semantics is=E2=80=A6), so we shouldn=E2=80=99t do it unless we= =E2=80=99re quite sure. > > > > Thanks, > > Yaron > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00504502ca7144e4cd047202c218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron,

Also, there are use cases when application needs more than= 1 IP address for internal purpose.
With current ikev2bis, this is possi= ble as we can request address after session establishment using CP[CFG_REQU= EST] in=C2=A0 INFORMATIONAL exchange.
If we say that we want to support in ONLY IKE_AUTH.
Are we going to stop= supporting CP payload via INFORMATION exchange ?

Thanks & Regar= ds,
Raj

On Wed, Aug 26, 2009 at 2:53 A= M, Yaron Sheffer <yaronf@checkpoint.com> wrote:

Yoav:

=C2=A0

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

=C2=A0

Everyone, please comment on the above, even if you support Yoa= v=E2=80=99s proposal. This would be a protocol change (even if we don=E2=80=99t underst= and what the current semantics is=E2=80=A6), so we shouldn=E2=80=99t do it unless we=E2= =80=99re quite sure.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Yaron

=C2=A0


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


--00504502ca7144e4cd047202c218-- From ynir@checkpoint.com Tue Aug 25 23:11: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 242D33A687C for ; Tue, 25 Aug 2009 23:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, 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 zi+SU1Y1TbK9 for ; Tue, 25 Aug 2009 23:11:01 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 674523A6F10 for ; Tue, 25 Aug 2009 23:11:00 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D93AE29C005; Wed, 26 Aug 2009 09:11:23 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 99ECB200E09; Wed, 26 Aug 2009 09:11:23 +0300 (IDT) X-CheckPoint: {4A94D0AD-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 n7Q6Aw3d021172; Wed, 26 Aug 2009 09:10:59 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 09:10:57 +0300 From: Yoav Nir To: Raj Singh Date: Wed, 26 Aug 2009 09:10:56 +0300 Thread-Topic: [IPsec] #79: Remove CP from Create_Child_SA? Thread-Index: AcomE/mLPVarq5v8STqOBTUAjzfCzw== Message-ID: <3F7BCA5E-45E8-4769-8CB1-56D816EEB5D9@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <7ccecf670908252008v15aa4b54ldb25dbef1e7e0986@mail.gmail.com> In-Reply-To: <7ccecf670908252008v15aa4b54ldb25dbef1e7e0986@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_3F7BCA5E45E847698CB156D816EEB5D9checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 06:11:02 -0000 --_000_3F7BCA5E45E847698CB156D816EEB5D9checkpointcom_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Raj. The issue is concerned with Config payload in Child SA only. Config in INFO= RMATIONAL will stay, or at least, there is no current proposal to remove it= . It can be useful for querying the application version, which is still a def= ined attribute for CP. Can you elaborate on the cases where the application needs more than 1 IP a= ddress? Yoav On Aug 26, 2009, at 6:08 AM, Raj Singh wrote: Hi Yaron, Also, there are use cases when application needs more than 1 IP address for= internal purpose. With current ikev2bis, this is possible as we can request address after ses= sion establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange. If we say that we want to support in ONLY IKE_AUTH. Are we going to stop supporting CP payload via INFORMATION exchange ? Thanks & Regards, Raj On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer > wrote: Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that sectio= n 2.19 says that "request for such a temporary address can be included in a= ny request to create a CHILD_SA (including the implicit request in message = 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a p= arenthetical remark, it's really the only one anyone uses. I don't think i= t makes sense to assign a different IP address for each SA, and I don't thi= nk anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP= payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time b= efore the client needs to renew the address with the gateway (probably rene= w the lease with a DHCP server). With such an attribute, it made sense for = the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked = as "RESERVED". Since we've done that, I suggest we remove the CP payload fr= om the Create Child SA exchange in appendix A, and reword section 2.19 to r= eflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav=92s proposa= l. This would be a protocol change (even if we don=92t understand what the = current semantics is=85), so we shouldn=92t do it unless we=92re quite sure= . Thanks, Yaron =0D=0A Email secured by Check Point=0D=0A --_000_3F7BCA5E45E847698CB156D816EEB5D9checkpointcom_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Raj.

The issue is concerned with Config payload in Child SA only. Config in INF= ORMATIONAL will stay, or at least, there is no current proposal to remove i= t.  

It can be useful for querying the applic= ation version, which is still a defined attribute for CP.

Can you elaborate on the cases where the application needs more tha= n 1 IP address?

Yoav

On Au= g 26, 2009, at 6:08 AM, Raj Singh wrote:

Hi Yaron,

Also, there are use c= ases when application needs more than 1 IP address for internal purpose.With current ikev2bis, this is possible as we can request address after se= ssion establishment using CP[CFG_REQUEST] in  INFORMATIONAL exchange. =
If we say that we want to support in ONLY IKE_AUTH.
Are we going to stop= supporting CP payload via INFORMATION exchange ?

Thanks & Regar= ds,
Raj

On Wed, Aug 26, 2009 at 2:53 A= M, Yaron Sheffer <yaronf@checkpoint.com> wrote:

Yoav:

 

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


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

 

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

 

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

 
 

Everyone, please comment on the above, even if you = support Yoav=92s proposal. This would be a protocol change (even if we don=92t understand wh= at the current semantics is=85), so we shouldn=92t do it unless we=92re quite sure= .

 

Thanks,

=             Yaron


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

= = --_000_3F7BCA5E45E847698CB156D816EEB5D9checkpointcom_-- From martin@strongswan.org Wed Aug 26 00:18: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 D0D753A6A00 for ; Wed, 26 Aug 2009 00:18:32 -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 mWwt1U5F5DjG for ; Wed, 26 Aug 2009 00:18:32 -0700 (PDT) Received: from zaes.ch (zaes.ch [213.133.111.41]) by core3.amsl.com (Postfix) with ESMTP id AA0D728C106 for ; Wed, 26 Aug 2009 00:18:01 -0700 (PDT) Received: from [85.4.153.56] (helo=[192.168.1.61]) by zaes.ch with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MgCxT-0004C4-0O; Wed, 26 Aug 2009 09:30:15 +0200 From: Martin Willi To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> Content-Type: text/plain Date: Wed, 26 Aug 2009 09:17:56 +0200 Message-Id: <1251271076.29327.7.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] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 07:18:32 -0000 Hi, > Input from actual implementations (and bakeoffs) will be most valuable > here. We and I think all vendors I have tested against use multiple certificate payloads (however, multi-level CA is a feature not tested with many participants). It is not even clear from the spec how to encode multiple certificates in a single cert payload with type 4 (just concatenate?). Regards Martin From rsjenwar@gmail.com Wed Aug 26 00:40: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 512183A6AE9 for ; Wed, 26 Aug 2009 00:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191, 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 JT76Efz6rIsw for ; Wed, 26 Aug 2009 00:40:39 -0700 (PDT) Received: from mail-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by core3.amsl.com (Postfix) with ESMTP id EACCA3A6945 for ; Wed, 26 Aug 2009 00:40:38 -0700 (PDT) Received: by pxi5 with SMTP id 5so6604921pxi.6 for ; Wed, 26 Aug 2009 00:40:41 -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=k6MGacySWyYUuP+l+VyhEnl0QRqBA0Fpo8zekdBET7k=; b=jd64Z+mNqnU0BrnFFAAbsvZpdf9VuOTs3ionApTyXbY1WaQwhcvGksbqsiHQamwui6 ogfLKos+a87VAkRs3tYJwhz7zAA80zNZbZrL/88l8LuG6Ge539BHnaSqjG22G1uA5T4s PrrEc9ZG3hWzgBH8kJVWWS+vk8+nycUqzwS20= 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=hKwWDcjzj85bRDFPHSpIpO/f16Hwn0f72mIKrgGa7KkQCZchvferflQ4hXwUbl9NOe YmdBiKYg6DtjpVXr2qzsxPK+eMd8gUmOhH2Epk9gQtkXMeYlgQ9Rj79cq3K3gSku3W7s GiAJKk7XCUHz+CFwshR5hqXbx/8s+NBUP3LBM= MIME-Version: 1.0 Received: by 10.142.3.12 with SMTP id 12mr478010wfc.331.1251272441779; Wed, 26 Aug 2009 00:40:41 -0700 (PDT) In-Reply-To: <3F7BCA5E-45E8-4769-8CB1-56D816EEB5D9@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <7ccecf670908252008v15aa4b54ldb25dbef1e7e0986@mail.gmail.com> <3F7BCA5E-45E8-4769-8CB1-56D816EEB5D9@checkpoint.com> Date: Wed, 26 Aug 2009 13:10:41 +0530 Message-ID: <7ccecf670908260040x1269eff2pce1655e5e09705ed@mail.gmail.com> From: Raj Singh To: Yoav Nir Content-Type: multipart/alternative; boundary=0016368e233f68d6ae0472069129 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 07:40:40 -0000 --0016368e233f68d6ae0472069129 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav, These applications are using same IKE SA for allocating IP to the application specific virtual interfaces, which can be more than one. Let me know if you further clarification. Thanks & Regards, Raj 2009/8/26 Yoav Nir > Hi Raj. > The issue is concerned with Config payload in Child SA only. Config in > INFORMATIONAL will stay, or at least, there is no current proposal to rem= ove > it. > > It can be useful for querying the application version, which is still a > defined attribute for CP. > > Can you elaborate on the cases where the application needs more than 1 IP > address? > > Yoav > > On Aug 26, 2009, at 6:08 AM, Raj Singh wrote: > > Hi Yaron, > > Also, there are use cases when application needs more than 1 IP address f= or > internal purpose. > With current ikev2bis, this is possible as we can request address after > session establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange. > If we say that we want to support in ONLY IKE_AUTH. > Are we going to stop supporting CP payload via INFORMATION exchange ? > > Thanks & Regards, > Raj > > On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer wro= te: > >> Yoav: >> >> >> Patricia noted in a post to the IPsec mailing list (12/12/2008) that >> section 2.19 says that "request for such a temporary address can be incl= uded >> in any request to create a CHILD_SA (including the implicit request in >> message 3) by including a CP payload." >> >> IMO the normal way of doing things is in this message 3, so rather than = a >> parenthetical remark, it's really the only one anyone uses. I don't thi= nk >> it makes sense to assign a different IP address for each SA, and I don't >> think anyone actually intended for this to be implied. >> >> >> In RFC 4306, section 3.15, one of the attributes that can be sent in the >> CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of t= ime >> before the client needs to renew the address with the gateway (probably >> renew the lease with a DHCP server). With such an attribute, it made sen= se >> for the client to renew the address along with rekeying some CHILD_SA. >> >> >> In the bis document, we've deprecated this attribute, and it is now mark= ed >> as "RESERVED". Since we've done that, I suggest we remove the CP payload >> from the Create Child SA exchange in appendix A, and reword section 2.19= to >> reflect that requesting an IP address is only acceptable during IKE_AUTH= . >> >> >> >> Everyone, please comment on the above, even if you support Yoav=E2=80=99= s >> proposal. This would be a protocol change (even if we don=E2=80=99t unde= rstand what >> the current semantics is=E2=80=A6), so we shouldn=E2=80=99t do it unless= we=E2=80=99re quite sure. >> >> >> Thanks, >> >> Yaron >> > > > > Email secured by Check Point > > --0016368e233f68d6ae0472069129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav,

These applications are using same IKE SA for allocating IP = to the application specific virtual interfaces, which can be more than one.= Let me know if you further clarification.

Thanks & Regards,
Raj


2009/8/26 Yoav Nir <ynir@checkpoint.com><= /span>
Hi Raj.

The issue = is concerned with Config payload in Child SA only. Config in INFORMATIONAL = will stay, or at least, there is no current proposal to remove it. =C2=A0

It can be useful for querying the application version, = which is still a defined attribute for CP.

Can you= elaborate on the cases where the application needs more than 1 IP address?=

Yoav

On Aug 26, 2009, at 6:08 AM, Raj Singh wrote:

Hi Yaron,

Also, there are use cases when application n= eeds more than 1 IP address for internal purpose.
With current ikev2bis, this is possible as we can request address after ses= sion establishment using CP[CFG_REQUEST] in=C2=A0 INFORMATIONAL exchange. <= br> If we say that we want to support in ONLY IKE_AUTH.
Are we going to stop= supporting CP payload via INFORMATION exchange ?

Thanks & Regar= ds,
Raj

On Wed, Aug 26, 2009 at 2:53 A= M, Yaron Sheffer <yaronf@checkpoint.com> wrote:

Yoav:

=C2=A0

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


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

=C2=A0

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

=C2=A0

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

=C2=A0
=C2=A0

Everyone, p= lease comment on the above, even if you support Yoav=E2=80=99s proposal. This would be a protocol change (even if we don=E2=80=99t underst= and what the current semantics is=E2=80=A6), so we shouldn=E2=80=99t do it unless we=E2= =80=99re quite sure.

= =C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Yaron

<= /div>


Email secured by Check Point


--0016368e233f68d6ae0472069129-- From ynir@checkpoint.com Wed Aug 26 01: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 312063A67D3 for ; Wed, 26 Aug 2009 01:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, 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 u9ezx-hUqVa9 for ; Wed, 26 Aug 2009 01:08:27 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 549CC3A6B8A for ; Wed, 26 Aug 2009 01:07:46 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3FE34200E0E; Wed, 26 Aug 2009 11:08:15 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E68ED200E09; Wed, 26 Aug 2009 11:08:14 +0300 (IDT) X-CheckPoint: {4A94EC0F-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 n7Q87o3d022207; Wed, 26 Aug 2009 11:07:50 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 11:07:48 +0300 From: Yoav Nir To: Raj Singh Date: Wed, 26 Aug 2009 11:07:48 +0300 Thread-Topic: [IPsec] #79: Remove CP from Create_Child_SA? Thread-Index: AcomJEwtiZLZAvzQQeqTi7ir0orhZQ== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <7ccecf670908252008v15aa4b54ldb25dbef1e7e0986@mail.gmail.com> <3F7BCA5E-45E8-4769-8CB1-56D816EEB5D9@checkpoint.com> <7ccecf670908260040x1269eff2pce1655e5e09705ed@mail.gmail.com> In-Reply-To: <7ccecf670908260040x1269eff2pce1655e5e09705ed@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_F86D751091AD4053BBF974FA90A9B858checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 08:08:28 -0000 --_000_F86D751091AD4053BBF974FA90A9B858checkpointcom_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Interesting. But if it's different IP addresses for different applications, then there a= re probably also different traffic selectors for these applications, and th= en possibly different IPsec SAs. If that's the case, then maybe it does make sense to get IP addresses in th= e Create_Child SA exchange On Aug 26, 2009, at 10:40 AM, Raj Singh wrote: Hi Yoav, These applications are using same IKE SA for allocating IP to the applicati= on specific virtual interfaces, which can be more than one. Let me know if = you further clarification. Thanks & Regards, Raj 2009/8/26 Yoav Nir > Hi Raj. The issue is concerned with Config payload in Child SA only. Config in INFO= RMATIONAL will stay, or at least, there is no current proposal to remove it= . It can be useful for querying the application version, which is still a def= ined attribute for CP. Can you elaborate on the cases where the application needs more than 1 IP a= ddress? Yoav On Aug 26, 2009, at 6:08 AM, Raj Singh wrote: Hi Yaron, Also, there are use cases when application needs more than 1 IP address for= internal purpose. With current ikev2bis, this is possible as we can request address after ses= sion establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange. If we say that we want to support in ONLY IKE_AUTH. Are we going to stop supporting CP payload via INFORMATION exchange ? Thanks & Regards, Raj On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer > wrote: Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that sectio= n 2.19 says that "request for such a temporary address can be included in a= ny request to create a CHILD_SA (including the implicit request in message = 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a p= arenthetical remark, it's really the only one anyone uses. I don't think i= t makes sense to assign a different IP address for each SA, and I don't thi= nk anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP= payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time b= efore the client needs to renew the address with the gateway (probably rene= w the lease with a DHCP server). With such an attribute, it made sense for = the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked = as "RESERVED". Since we've done that, I suggest we remove the CP payload fr= om the Create Child SA exchange in appendix A, and reword section 2.19 to r= eflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav=92s proposa= l. This would be a protocol change (even if we don=92t understand what the = current semantics is=85), so we shouldn=92t do it unless we=92re quite sure= . Thanks, Yaron Email secured by Check Point =0D=0A Email secured by Check Point=0D=0A --_000_F86D751091AD4053BBF974FA90A9B858checkpointcom_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Interesting.

But if it's different IP addresses for different applications, then t= here are probably also different traffic selectors for these applications, = and then possibly different IPsec SAs.

If that's t= he case, then maybe it does make sense to get IP addresses in the Create_Ch= ild SA exchange

On Aug 26, 2009, at 10:40 AM, Raj S= ingh wrote:

Hi Yoav,

These applications are using same IKE SA for allo= cating IP to the application specific virtual interfaces, which can be more= than one. Let me know if you further clarification.

Thanks & Re= gards,
Raj


2009/8/26 Yoav Nir <ynir@checkpoint.com><= /span>
Hi Raj.

The issue = is concerned with Config payload in Child SA only. Config in INFORMATIONAL = will stay, or at least, there is no current proposal to remove it.  

It can be useful for querying the application version, = which is still a defined attribute for CP.

Can you= elaborate on the cases where the application needs more than 1 IP address?=

Yoav

On Aug 26, 2009, at 6:08 AM, Raj Singh wrote:

Hi Yaron,

Also, there are use cases when application n= eeds more than 1 IP address for internal purpose.
With current ikev2bis, this is possible as we can request address after ses= sion establishment using CP[CFG_REQUEST] in  INFORMATIONAL exchange. <= br> If we say that we want to support in ONLY IKE_AUTH.
Are we going to stop= supporting CP payload via INFORMATION exchange ?

Thanks & Regar= ds,
Raj

On Wed, Aug 26, 2009 at 2:53 A= M, Yaron Sheffer <yaronf@checkpoint.com> wrote:

Yoav:

 

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


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

 

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

 

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

 
 

Everyone, p= lease comment on the above, even if you support Yoav=92s proposal. This would be a protocol change (even if we don=92t understand wh= at the current semantics is=85), so we shouldn=92t do it unless we=92re quite sure= .

 

     &nb= sp;      Yaron




Email secured by Check Point




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

= = --_000_F86D751091AD4053BBF974FA90A9B858checkpointcom_-- From kivinen@iki.fi Wed Aug 26 06:40: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 9F57C3A6A48 for ; Wed, 26 Aug 2009 06:40:14 -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 5dWD2CNB-fEB for ; Wed, 26 Aug 2009 06:40:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 210813A67B1 for ; Wed, 26 Aug 2009 06:40:12 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n7QDAjNN000327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 16:10:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7QDAjLO014400; Wed, 26 Aug 2009 16:10:45 +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: <19093.13397.428483.391635@fireball.kivinen.iki.fi> Date: Wed, 26 Aug 2009 16:10:45 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <7ccecf670908252008v15aa4b54ldb25dbef1e7e0986@mail.gmail.com> <3F7BCA5E-45E8-4769-8CB1-56D816EEB5D9@checkpoint.com> <7ccecf670908260040x1269eff2pce1655e5e09705ed@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: "ipsec@ietf.org WG" , Raj Singh Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:40:14 -0000 Yoav Nir writes: > But if it's different IP addresses for different applications, then > there are probably also different traffic selectors for these > applications, and then possibly different IPsec SAs. Most likely, but it is still most likely going to be few -> many mapping, i.e. you have few (1-3? or so IP-addresses), but you can have many SAs each using few of those addresses. I do not really see any need to use configuration payloads along with create child SA exchanges. The reason we do configuration payloads in the IKE_AUTH is to avoid extra round trips for the most common case when creating IKE SA, getting IP address, and creating IPsec SA. If some implementation needs more IP-addresses, then it can first use INFORMATIONAL exchange with configuration payloads to get the IP-addresses it needs, and then use create child SA to create the IPsec SA using that address. For the GW it is enough to check that traffic selectors for the source address is one of the addresses allocated for the client (or otherwise address allowed by policy). Draft-ietf-ispecme-ikev2-ipv6-config might need configuration payloads in information exchanges also, especially if you use the sharing of VPN access (section 3.4), as in that case you most likely need one new perfix per interface where you share the address, and all of your interfaces might not be up and in use when you first create the IKE SA. -- kivinen@iki.fi From kivinen@iki.fi Wed Aug 26 06:40: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 8A3713A67B1 for ; Wed, 26 Aug 2009 06:40: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 Fl2gr2jaS26N for ; Wed, 26 Aug 2009 06:40:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 49D643A6A42 for ; Wed, 26 Aug 2009 06:40: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 n7QCqDXe009559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 15:52:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7QCqBew008545; Wed, 26 Aug 2009 15:52:11 +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: <19093.12283.746864.474510@fireball.kivinen.iki.fi> Date: Wed, 26 Aug 2009 15:52:11 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: "ipsec@ietf.org" Subject: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:40:15 -0000 Yaron Sheffer writes: > [2.23, NAT Traversal] > > o Implementations MUST process received UDP-encapsulated ESP packets > > even when no NAT was detected. > > > > o The original source and destination IP address required for the > > transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) > > are obtained from the Traffic Selectors associated with the > > exchange. In the case of NAT traversal, the Traffic Selectors > > MUST contain exactly one IP address, which is then used as the > > original IP address. > > Tero: > > Getting original source and destination IP address from the traffic > selectors do not really work currently. Especially when combined with > the selectors from the packet and when responder is behind nat or > similar problems. > > Paul: Not done. Specify replacement text and discuss on the mailing list. > > People who care about Transport Mode are requested to help resolve this NAT > Traversal issue. I wrote better long description about the problem, and also proposed solution text at 2009-04-07: http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html -- kivinen@iki.fi From kivinen@iki.fi Wed Aug 26 06:44: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 2E6BE3A67F3 for ; Wed, 26 Aug 2009 06:44:41 -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.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 IRKmB5rVxMRF for ; Wed, 26 Aug 2009 06:44:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 252DE3A67EF for ; Wed, 26 Aug 2009 06:44:39 -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 n7QDhOBq005383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 16:43:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7QDhNUI015149; Wed, 26 Aug 2009 16:43: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: <19093.15355.539409.699756@fireball.kivinen.iki.fi> Date: Wed, 26 Aug 2009 16:43:23 +0300 From: Tero Kivinen To: Martin Willi In-Reply-To: <1251271076.29327.7.camel@martin.hsr.ch> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> <1251271076.29327.7.camel@martin.hsr.ch> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:44:41 -0000 Martin Willi writes: > It is not even clear from the spec how to encode multiple certificates > in a single cert payload with type 4 (just concatenate?). There is no way to encode more than one certificate with X.509 Certificate - Signature (#4) format in one certificate payload. -- kivinen@iki.fi From ynir@checkpoint.com Wed Aug 26 06:54: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 8EF683A683D for ; Wed, 26 Aug 2009 06:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 LxYI0+9SecSQ for ; Wed, 26 Aug 2009 06:54:33 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 978613A67F3 for ; Wed, 26 Aug 2009 06:54:33 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2A70329C004; Wed, 26 Aug 2009 16:54:20 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DD928200E0A; Wed, 26 Aug 2009 16:54:19 +0300 (IDT) X-CheckPoint: {4A953D28-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 n7QDrt3d001161; Wed, 26 Aug 2009 16:53:55 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 16:53:52 +0300 From: Yoav Nir To: Tero Kivinen Date: Wed, 26 Aug 2009 16:53:54 +0300 Thread-Topic: [IPsec] #107: Sending certificate chains in IKEv2 Thread-Index: AcomVKUrr4VoGEOBSF26F6C3oSHsTA== Message-ID: <6AF12A00-3D30-417D-AB9E-1E9FE6CC6C4F@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> <1251271076.29327.7.camel@martin.hsr.ch> <19093.15355.539409.699756@fireball.kivinen.iki.fi> In-Reply-To: <19093.15355.539409.699756@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] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:54:34 -0000 Good. So how about we close this issue by adding the last sentence =20 below: If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other =20 certificates may be sent in any order. Each certificate is encoded in a separate CERT payload. Does this sound OK to everyone? On Aug 26, 2009, at 4:43 PM, Tero Kivinen wrote: > Martin Willi writes: >> It is not even clear from the spec how to encode multiple =20 >> certificates >> in a single cert payload with type 4 (just concatenate?). > > There is no way to encode more than one certificate with X.509 > Certificate - Signature (#4) format in one certificate payload. > --=20 > kivinen@iki.fi > _______________________________________________ > 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 kivinen@iki.fi Wed Aug 26 07:08:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D1F3A6C6F for ; Wed, 26 Aug 2009 07:08:36 -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 zpAq78BvAeNp for ; Wed, 26 Aug 2009 07:08:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B98713A6C7B for ; Wed, 26 Aug 2009 07:08:23 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n7QDgTFS017570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 16:42:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7QDgTaC018920; Wed, 26 Aug 2009 16:42:29 +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: <19093.15301.348253.446035@fireball.kivinen.iki.fi> Date: Wed, 26 Aug 2009 16:42:29 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 30 min Cc: "ipsec@ietf.org" Subject: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 14:08:36 -0000 Yaron Sheffer writes: > What this doesn't say is how we send this chain of certificates. Is it > multiple separate CERT payloads (in that case it should say so) or is it a > single CERT payload (and then we should also say so) If you use format that can only store one certificate (for example X.509 Certificate - Signature (#4), or Hash and URL of X.509 certificate (#12)) then you send multiple Certificate Payloads each having one certificate in, and the first certificate payload you send contains the certificate you use to sign the AUTH payload. If you use format that can store multiple certificates (PKCS #7 wrapped X.509 certificate (#1) or Hash and URL of X.509 bundle (#13)) then the first certificate inside the first Certificate Payload is the one used to sign the AUTH payload. This thing is same as it was in IKEv1, i.e. sending multiple Certificate payloads, each having one certificate using X.509 Certificate - Signature (#4) was the most common configuration implementations supported. Note, that it is also valid to send mixed set of certificate payloads, i.e. send first few Certificate Payloads using X.509 Certificate - Signature (#4) format and then send couple of Certificate Payloads using Certificate Revocation List (CRL) (#7) format, to provide the CRLs for those certificates. I already had some comments to this at 2008-07-29, where I requested change to the "X.509 Certificate - Signature" description, so it would be clear that it can also be used in validation of the chain not only when validating AUTH payload http://www.ietf.org/mail-archive/web/ipsec/current/msg02953.html, actually Yoav Nir's version has even better text http://www.ietf.org/mail-archive/web/ipsec/current/msg04326.html (and disagree with Paul's comment that this text would add new MUST, as that requirement has always been there as there is no way to encode multiple certificates to one X.509 Certificate - Signature (#4) format, thus if you want to use that format you must have sent multiple certificates earlier too (note that the MUST was only "with this encoding")). On the other hand as this thing with multiple CERT payloads is not only restricted to that format, so some generic text to section 3.6 is needed anyways. There is also my previous email about this #107 ticket, which includes some more comments to the issue: http://www.ietf.org/mail-archive/web/ipsec/current/msg04327.html. -- kivinen@iki.fi From wierbows@us.ibm.com Wed Aug 26 07:52: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 B575B3A6B8D for ; Wed, 26 Aug 2009 07:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.035 X-Spam-Level: X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 0gZaN-OUgE1z for ; Wed, 26 Aug 2009 07:52:06 -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 56BC63A68AE for ; Wed, 26 Aug 2009 07:52:06 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7QDfn9S006643 for ; Wed, 26 Aug 2009 09:41:49 -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 v10.0) with ESMTP id n7QDo2IT216778 for ; Wed, 26 Aug 2009 09:50:02 -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 n7QDo26C027826 for ; Wed, 26 Aug 2009 09:50:02 -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 n7QDo2Yf027793 for ; Wed, 26 Aug 2009 09:50:02 -0400 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> To: "ipsec@ietf.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Wed, 26 Aug 2009 09:49:59 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 08/26/2009 09:50:02 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02" Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 14:52:07 -0000 --0__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: multipart/related; Boundary="1__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02" --1__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: multipart/alternative; Boundary="2__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02" --2__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable We use multiple certificate payloads when using X.509 Certificate - Signature (4) encoding. I do not really see how this could be questioned. RFC 4306 clearly say= s X.509 Certificate - Signature (4) encoding contains a single certificat= e as pointed out below. The logical conclusion is that if you need to send multiple certificates and choose to use X.509 Certificate - Signature = (4) encoding then you need multiple payloads. On the other hand you can send one payload if you use Hash and URL of X= .509 bundle encoding. If you do then the first certificate in the bundle mu= st contain the public key used to sign the AUTH payload. I think the existing text is fine. Dave Wierbowski = Yaron Sheffer = = To Sent by: "ipsec@ietf.org" ipsec-bounces@iet = cc f.org = Subj= ect [IPsec] #107: Sending certificat= e 08/25/2009 05:23 chains in IKEv2 = PM = = = = = = Yoav says: Section 3.6 ("Certificate Payload") describes sending certificates in t= he IKE_AUTH exchange. The usual format for sending certificates is #4 (X.= 509 Certificate - Signature). Here's what it says: {{{ o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUT= H payload. }}} (note the singular) The last paragraph says: {{{ Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication...= ...If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificate= s may be sent in any order. }}} What this doesn't say is how we send this chain of certificates. Is it= multiple separate CERT payloads (in that case it should say so) or is i= t a single CERT payload (and then we should also say so) Input from actual implementations (and bakeoffs) will be most valuable here. Thanks, Yaron(See attached file: smime.p7s) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --2__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

We use multiple certificate payloads when using X.509 Certificate -= Signature (4) encoding.

I do not really see how this could be questioned. RFC 4306 clearly say= s X.509 Certificate - Signature (4) encoding contains a single certific= ate as pointed out below. The logical conclusion is that if you need t= o send multiple certificates and choose to use X.509 Certificate - Sig= nature (4) encoding then you need multiple payloads.

On the other hand you can send one payload if you use Hash and URL of X= .509 bundle encoding. If you do then the first certificate in the bund= le must contain the public key used to sign the AUTH payload.

I think the existing text is fine.



Dave Wierbowski






3D"InactiveYaron Sheffer <yaronf@checkp= oint.com>


=
          Yaron Sheffer <yaronf@checkpoint.com>
          Sent by: ipsec-bounces@ietf.org

          08/25/2009 05:23 PM

 =
3D=
To
3D""
"ipsec@ietf.org" <ipsec@ietf.org>
3D=
cc
3D""
3D=
Subject
3D""
[IPsec] #107: Sending certificate chains in IKEv2
3D=3D""

Yoav says:

Section 3.6 ("Certificate Payload") desc= ribes sending certificates in the IKE_AUTH exchange. The usual format = for sending certificates is #4 (X.509 Certificate - Signature). Here's = what it says:


{{{
o X.509 Certificate - Signature (4) contains a= DER encoded X.509
certificate whose public key is used to vali= date the sender's AUTH
payload.
}}}

(note the singular) The last paragraph says:


{{{
Implementations MUST be capable of being config= ured to send and
accept up to four X.509 certificates in support= of authentication...
...If
multiple certificates are sent, the first certi= ficate MUST contain
the public key used to sign the AUTH payload. = The other certificates
may be sent in any order.
}}}

What this doesn't say is how we send this chain of= certificates. Is it multiple separate CERT payloads (in that case it = should say so) or is it a single CERT payload (and then we should also = say so)


Input from actual implementations (and bakeoffs) w= ill be most valuable here.

Thanks,
Yaron(See attached file: smi= me.p7s)_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --2__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02-- --1__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <2__=0ABBFC8DDFD9CB028f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --1__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: image/gif; name="pic43443.gif" Content-Disposition: inline; filename="pic43443.gif" Content-ID: <3__=0ABBFC8DDFD9CB028f9e8a93df938@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== --1__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <4__=0ABBFC8DDFD9CB028f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --1__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02-- --0__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02 Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-ID: <1__=0ABBFC8DDFD9CB028f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNTIxMTc0M1owIwYJKoZIhvcNAQkEMRYEFKpMWcLC6bF7 g+/js2q0wr+qR86TMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA MHh3oQqRootjWb4rPjyYpKjhaH2LBMpf88+J5Gyp8sbDWHv3DxU1GOGtLCQoakYx3WMiHi8GQhmW AgmPpxgj9k33on8BUqw/Cp6iE6JDCHpKwZEcpHE/WB5UUTLn8HyU+qcvTuRLZpwpZAKrghRS2KIB Yn8lzorDpViUxvtQPBG19skgaSH/dqhCc8H1j0JKL0vTH4fJnL9ZM580jxMEJCy+W0DhBTJw1lQm e7v0ABGYbavAIgX/JQtHiHFQRoCxlMNZkTVQfyBfOzCSJBNNVz7Qgsl15Naqzu96CZ4RX2/QKOal Iv7fgkM65ZIMOOmU9bozHfAyKSt3MHm+FjceAQAAAAAAAA== --0__=0ABBFC8DDFD9CB028f9e8a93df938690918c0ABBFC8DDFD9CB02-- From gmonte@microsoft.com Wed Aug 26 03:30:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FB73A6962 for ; Wed, 26 Aug 2009 03:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gQxqT9fXWHY for ; Wed, 26 Aug 2009 03:30:56 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B083E3A685A for ; Wed, 26 Aug 2009 03:30:56 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 26 Aug 2009 03:29:54 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.621.7; Wed, 26 Aug 2009 03:29:54 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.236]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 26 Aug 2009 03:29:57 -0700 From: Gabriel Montenegro To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: draft-ietf-ipsecme-traffic-visibility-07.txt comments Thread-Index: AQHKJLti02SPD2k6REyFhSXZAbtIXZC4JpdQ Date: Wed, 26 Aug 2009 10:29:53 +0000 Message-ID: <17CBED0797974641B6FF531FCB74E0930DCADDE9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <19090.36751.8910.15073@fireball.kivinen.iki.fi> In-Reply-To: <19090.36751.8910.15073@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 26 Aug 2009 08:08:29 -0700 Cc: "ipsecme-chairs@tools.ietf.org" , "draft-ietf-ipsecme-traffic-visibility@tools.ietf.org" Subject: Re: [IPsec] draft-ietf-ipsecme-traffic-visibility-07.txt 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: Wed, 26 Aug 2009 10:30:57 -0000 Thanks Tero. Good catches. We'll address them in the upcoming revision. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, 24 August, 2009 6:03 AM > To: ipsec@ietf.org > Cc: draft-ietf-ipsecme-traffic-visibility@tools.ietf.org; ipsecme- > chairs@tools.ietf.org > Subject: draft-ietf-ipsecme-traffic-visibility-07.txt comments > > I now finished reading that traffic visibility draft and I have some > minor nits for it. > > In section 2, when describing flags, it does not explictly give the > bit order used when describing bits. I.e. is the version in bits 24-25 > in the full 4-byte header, or bits 30-31. > > Adding those fields to the picture would make this clear, i.e. > changing the Detailed WESP Packet Format picture to be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | HdrLen | TrailerLen |V|V|I| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Existing ESP Encapsulation | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Or adding separate picture for flags, or adding similar text than what > is in RFC4306 ("The bits are defined LSB first, so bit 0 would be the > least significant bit of the Flags octet). > > Also in section 2 it says "2 bits: Version. MUST be sent as 0 and > checked by the receiver. ", i.e. the version bit must be checked by > the receiver, but it does not say what needs to be done if the version > is different (most likely packet should be dropped, as version should > have be negotiated already in the IKEv2). > > In the end of section 2 (second last paragraph) there is sentence > saying "The receiver MUST drop packets for which the integrity check > is invalid.". > > I think this sentence is confusing, as if it means that receiver must > check the ICV field as normally IPsec, I do not think there is any > need to say that again, as it is clear from normal IPsec processing, > that packets with incorrect ICV are dropped. Especially as this is > just after text about future versions of protocol, I first read it and > started wandering if there is some separate integrity check that needs > to be done or what. > > In section 4. IANA Considerations it says that: > > The final 6 bits of the WESP Flags are the "Non-version Flags". > This specification defines no values, and future assignment is to > be managed via the IANA Policy of "Specification Required". > > This is not correct, as it already defines one more bit, i.e. the > "Encrypted Payload" bit in this document. > -- > kivinen@iki.fi From danmcd@sun.com Wed Aug 26 08:33: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 22D1B3A6E0B for ; Wed, 26 Aug 2009 08:33:55 -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 xPxXd0qPAKLd for ; Wed, 26 Aug 2009 08:33:54 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 5CC5F3A6A37 for ; Wed, 26 Aug 2009 08:33:54 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7QFWN1W010280 for ; Wed, 26 Aug 2009 15:32:23 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7QFWNY6015892 for ; Wed, 26 Aug 2009 11:32:23 -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 n7QFOqdE020894 for ; Wed, 26 Aug 2009 11:24:52 -0400 (EDT) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7QFOqmN020893 for ipsec@ietf.org; Wed, 26 Aug 2009 11:24:52 -0400 (EDT) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 26 Aug 2009 11:24:52 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090826152452.GB20866@kebe.East.Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19093.12283.746864.474510@fireball.kivinen.iki.fi> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 15:33:55 -0000 On Wed, Aug 26, 2009 at 03:52:11PM +0300, Tero Kivinen wrote: > I wrote better long description about the problem, and also proposed > solution text at 2009-04-07: > http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html The text referenced above summarizes the problem AND solution quite nicely, and reduces my response to a lame, but succinct +1. Dan From wierbows@us.ibm.com Wed Aug 26 08:43: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 8EEBF3A6CE1; Wed, 26 Aug 2009 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.335 X-Spam-Level: X-Spam-Status: No, score=-4.335 tagged_above=-999 required=5 tests=[AWL=0.300, 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 WWZuTZ2+HXch; Wed, 26 Aug 2009 08:43:55 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 049203A6B9C; Wed, 26 Aug 2009 08:43:54 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7QF4CaG014431; Wed, 26 Aug 2009 11:04:12 -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 v10.0) with ESMTP id n7QFAeGj139616; Wed, 26 Aug 2009 11:10:41 -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 n7QFAc58020671; Wed, 26 Aug 2009 11:10:40 -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 n7QFAbKV020508; Wed, 26 Aug 2009 11:10:37 -0400 In-Reply-To: <19093.15301.348253.446035@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Wed, 26 Aug 2009 11:10:36 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 08/26/2009 11:10:36 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 15:43:56 -0000 --0__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC Content-type: multipart/alternative; Boundary="1__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC" --1__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I agree with Tero that Yoav's proposed text adds clarity and effectivel= y it does not add a new MUST; however, to address Paul's concern can we just= change the words "MUST be" to the word "are" or lower case "should be?"= For example: o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUT= H payload. Note that with this encoding if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's= AUTH payload. As Tero points out, this is the only way to send a chain this using X.5= 09 Certificate - Signature.encoding. MUST terminology really is not neede= d in my opinion. Dave Wierbowski = Tero Kivinen = = Sent by: = To ipsec-bounces@iet Yaron Sheffer = f.org = = cc "ipsec@ietf.org" 08/26/2009 09:42 Subj= ect AM [IPsec] #107: Sending certifica= te chains in IKEv2 = = = = = = = Yaron Sheffer writes: > What this doesn't say is how we send this chain of certificates. Is = it > multiple separate CERT payloads (in that case it should say so) or is= it a > single CERT payload (and then we should also say so) If you use format that can only store one certificate (for example X.509 Certificate - Signature (#4), or Hash and URL of X.509 certificate (#12)) then you send multiple Certificate Payloads each having one certificate in, and the first certificate payload you send contains the certificate you use to sign the AUTH payload. If you use format that can store multiple certificates (PKCS #7 wrapped X.509 certificate (#1) or Hash and URL of X.509 bundle (#13)) then the first certificate inside the first Certificate Payload is the one used to sign the AUTH payload. This thing is same as it was in IKEv1, i.e. sending multiple Certificate payloads, each having one certificate using X.509 Certificate - Signature (#4) was the most common configuration implementations supported. Note, that it is also valid to send mixed set of certificate payloads, i.e. send first few Certificate Payloads using X.509 Certificate - Signature (#4) format and then send couple of Certificate Payloads using Certificate Revocation List (CRL) (#7) format, to provide the CRLs for those certificates. I already had some comments to this at 2008-07-29, where I requested change to the "X.509 Certificate - Signature" description, so it would be clear that it can also be used in validation of the chain not only when validating AUTH payload http://www.ietf.org/mail-archive/web/ipsec/current/msg02953.html, actually Yoav Nir's version has even better text http://www.ietf.org/mail-archive/web/ipsec/current/msg04326.html (and disagree with Paul's comment that this text would add new MUST, as that requirement has always been there as there is no way to encode multiple certificates to one X.509 Certificate - Signature (#4) format, thus if you want to use that format you must have sent multiple certificates earlier too (note that the MUST was only "with this encoding")). On the other hand as this thing with multiple CERT payloads is not only restricted to that format, so some generic text to section 3.6 is needed anyways. There is also my previous email about this #107 ticket, which includes some more comments to the issue: http://www.ietf.org/mail-archive/web/ipsec/current/msg04327.html. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I agree with Tero that Yoav's proposed text adds clarity and effecti= vely it does not add a new MUST; however, to address Paul's concern can= we just change the words "MUST be" to the word "are&quo= t; or lower case "should be?" For example:

   o  X.509 Certificate - Signature= (4) contains a DER encoded X.509
     certificate whose public key is used to validate t= he sender's AUTH
     payload. Note that with this encoding if a chain o= f certificates
     needs to be sent, multiple CERT payloads are used,= only the
     first of which holds the public key used to valida= te the sender's
     AUTH payload.

As Tero points out, this is the only way to send a chain this using X.5= 09 Certificate - Signature.encoding. MUST terminology really is not ne= eded in my opinion.

Dave Wierbowski



3D"InactiveTero Kivinen <kivinen@iki.fi>
=

=
          Tero Kivinen <kivinen@iki.fi><= font size=3D"2">
          Sent by: ipsec-bounces@ietf.org

          08/26/2009 09:42 AM

 =
3D=
To
3D""
Yaron Sheffer <yaronf@checkpoint.com>
3D=
cc
3D""
"ipsec@ietf.org" <ipsec@ietf.org>
3D=
Subject
3D""
[IPsec] #107: Sending certificate chains in IKEv2
3D=3D""

Yaron Sheffer writes:
> What this doesn't say is how we send this chain of certificates. &= nbsp;Is it
> multiple separate CERT payloads (in that case it should say so) or= is it a
> single CERT payload (and then we should also say so)

If you use format that can only store one certificate (for example
X.509 Certificate - Signature (#4), or Hash and URL of X.509
certificate (#12)) then you send multiple Certificate Payloads each
= having one certificate in, and the first certificate payload you send contains the certificate you use to sign the AUTH payload.

If you use format that can store multiple certificates (PKCS #7
wrapped X.509 certificate (#1) or Hash and URL of X.509 bundle (#13)) then the first certificate inside the first Certificate Payload is the<= br> one used to sign the AUTH payload.

This thing is same as it was in IKEv1, i.e. sending multiple
Certificate payloads, each having one certificate using X.509
Certificate - Signature (#4) was the most common configuration
implementations supported.

Note, that it is also valid to send mixed set of certificate payloads,<= br> i.e. send first few Certificate Payloads using X.509 Certificate -
Signature (#4) format and then send couple of Certificate Payloads
using Certificate Revocation List (CRL) (#7) format, to provide the
= CRLs for those certificates.

I already had some comments to this at 2008-07-29, where I requested change to the "X.509 Certificate - Signature" description, so= it would
be clear that it can also be used in validation of the chain not only when validating AUTH payload
http://www.ietf.org/mail-archive/web/ipsec/current/msg02= 953.html,
actually Yoav Nir's version has even better text
http://www.ietf.org/mail-archive/web/ipsec/current/msg04= 326.html (and
disagree with Paul's comment that this text would add new MUST, as
that requirement has always been there as there is no way to encode
= multiple certificates to one X.509 Certificate - Signature (#4)
format, thus if you want to use that format you must have sent
multiple certificates earlier too (note that the MUST was only "wi= th
this encoding")). On the other hand as this thing with multiple CE= RT
payloads is not only restricted to that format, so some generic text to section 3.6 is needed anyways.

There is also my previous email about this #107 ticket, which includes<= br> some more comments to the issue:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04= 327.html.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC-- --0__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFC8DDFC1C8EC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC Content-type: image/gif; name="pic15247.gif" Content-Disposition: inline; filename="pic15247.gif" Content-ID: <2__=0ABBFC8DDFC1C8EC8f9e8a93df938@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__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBFC8DDFC1C8EC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFC8DDFC1C8EC8f9e8a93df938690918c0ABBFC8DDFC1C8EC-- From yaronf@checkpoint.com Wed Aug 26 09:23:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFAA3A6CB3 for ; Wed, 26 Aug 2009 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.334, 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 Vsd6QuiatGzn for ; Wed, 26 Aug 2009 09:23:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 068DE28C315 for ; Wed, 26 Aug 2009 09:22:57 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6C91B29C008; Wed, 26 Aug 2009 17:14:33 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1F0DE200E0D; Wed, 26 Aug 2009 17:14:33 +0300 (IDT) X-CheckPoint: {4A9541E5-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 n7QEE83d007152; Wed, 26 Aug 2009 17:14:08 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 26 Aug 2009 17:14:05 +0300 From: Yaron Sheffer To: Yoav Nir , Tero Kivinen Date: Wed, 26 Aug 2009 17:14:05 +0300 Thread-Topic: [IPsec] #107: Sending certificate chains in IKEv2 Thread-Index: AcomVKUrr4VoGEOBSF26F6C3oSHsTAAAfuEQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E1361924@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B6@il-ex01.ad.checkpoint.com> <1251271076.29327.7.camel@martin.hsr.ch> <19093.15355.539409.699756@fireball.kivinen.iki.fi> <6AF12A00-3D30-417D-AB9E-1E9FE6CC6C4F@checkpoint.com> In-Reply-To: <6AF12A00-3D30-417D-AB9E-1E9FE6CC6C4F@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_019F_01CA2670.9D79FA90" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 16:23:31 -0000 ------=_NextPart_000_019F_01CA2670.9D79FA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yoav, This text (to be added for this specific encoding) duplicates the existing text at the end of this same section. Moreover, we keep saying "multiple certificates" without mentioning the semantics of these multiple certs, i.e. they should form a trust chain. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Wednesday, August 26, 2009 16:54 > To: Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 > > Good. So how about we close this issue by adding the last sentence > below: > > 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. Each certificate is encoded in a separate > CERT payload. > > Does this sound OK to everyone? > > On Aug 26, 2009, at 4:43 PM, Tero Kivinen wrote: > > > Martin Willi writes: > >> It is not even clear from the spec how to encode multiple > >> certificates > >> in a single cert payload with type 4 (just concatenate?). > > > > There is no way to encode more than one certificate with X.509 > > Certificate - Signature (#4) format in one certificate payload. > > -- > > kivinen@iki.fi > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_019F_01CA2670.9D79FA90 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNjE0MTQwNVowIwYJKoZIhvcNAQkEMRYEFGRCvsFeLGX4 DYJXe+PkrzTtO6wzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA jwPZismVsRtsSQUCjjmIAI7kxuR5YsNPMP7e1EEA1QLhtxIAY+5VIMiUcnPo1pbZObvnFY5kDHrv 68327VqnEoXPiQd4yNb2aKVtLOkSz7WV/W3CbasNpDg39eC0iKlQm6RoUYaT41KqiCNMbdP0oO2b VC9tmjxmonw2YyAFfuniP15DqIdb5PnrcqiXMqiVeiH3ZSE6mpfyrqHyOqEcH5bJiII3BHjxTKg4 k9pCLQhwvKO8Dj/o/MMTr2pmpRmUlyhNRVudzkz/YR/jjlTQ39Midct5GAZZqLTnoRqrw7XOupNN jHZcKA++jsjm2pXDRZj8ccQNJ+4qTAYCkUxaeAAAAAAAAA== ------=_NextPart_000_019F_01CA2670.9D79FA90-- From wwwrun@core3.amsl.com Wed Aug 26 10:32:22 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F14CB28C4C5; Wed, 26 Aug 2009 10:32:21 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090826173221.F14CB28C4C5@core3.amsl.com> Date: Wed, 26 Aug 2009 10:32:21 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] IPSECME Virtual 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, 26 Aug 2009 17:32:22 -0000 The ipsecme WG will have a virtual interim WG meeting in about a month. We will have a conference call on Tuesday September 22, 15:00 GMT (18:00 Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Technical details are available here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls A detailed agenda will be posted to the ipsec@ietf.org mailing list closer to the meeting. Thanks, Yaron Sheffer and Paul Hoffman From smoonen@us.ibm.com Wed Aug 26 11:03: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 15F453A6AA6; Wed, 26 Aug 2009 11:03:34 -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 1unS1MwcP72S; Wed, 26 Aug 2009 11:03:32 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 6EBCF28C4DF; Wed, 26 Aug 2009 11:03:29 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7QHwhMq000378; Wed, 26 Aug 2009 11:58:43 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7QI3FD5108368; Wed, 26 Aug 2009 12:03:15 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n7QI4KKl007696; Wed, 26 Aug 2009 12:04:20 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n7QI4KvK007655; Wed, 26 Aug 2009 12:04:20 -0600 In-Reply-To: <19093.12283.746864.474510@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 1EED4B9B:CC68B9D5-8525761E:00603A09; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/26/2009 02:02:51 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/26/2009 02:02:51 PM, Serialize complete at 08/26/2009 02:02:51 PM, S/MIME Sign failed at 08/26/2009 02:02:51 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08092009|August 09, 2009) at 08/26/2009 12:03:12, Serialize complete at 08/26/2009 12:03:12 Message-ID: Date: Wed, 26 Aug 2009 14:03:12 -0400 Content-Type: multipart/alternative; boundary="=_alternative 006323998525761E_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 18:03:34 -0000 This is a multipart message in MIME format. --=_alternative 006323998525761E_= Content-Type: text/plain; charset="US-ASCII" Tero, I am not comfortable with the following statement: . . . thus it will send back traffic selectors having IPN1 and IP2 as their IP addresses . . . I would prefer that the server re-map the TS values back to IP1 and IPN2 when sending its response. This is consistent with the general expectation that the response's TS payloads are a subset of the request's payloads. The client does not absolutely need this information (it would perhaps help for deterministic checksum fixup, however in transport mode as long as an integrity algorithm is used the checksum provides no additional value anyway). I think it is also advantageous to contain this fixup processing to one code path (processing TS payloads in received requests), and it also simplifies the response message processing (the client does not need to complicate its checks to verify that the response's TS payloads are a subset of the request's). This separation of responsibility is more advantageous to a client implementation that needs to be as minimal as possible. Finally, what I propose above is how our own IKEv1 implementation works in cases where ID payloads are sent for transport mode. :) As a responder we found it best to bend over backwards to cater to the initiator's view of the world. I'm also concerned about the following statement: After this it does SPD lookup based on those new traffic selectors. . . . If entry is found but it does not allow transport mode, then MUST undo the address substitution and redo the SPD lookup using the original traffic selectors. . . . This statement is incoherent to me. From the fact that the initiator proposed transport mode, it is clear that the initiator identifies TSi with itself and TSr with the server. The address substitution exactly translates these addresses into the domain of the responder's SPD. If the responder's policy indicates that transport mode is not acceptable for this SPD entry, then I think the only possible outcome is that SA negotiation should be failed. No other SPD entry could possibly match the initiator's intentions. However, the MUST quoted above causes the responder to treat these addresses in an incoherent way: 1) The responder has detected a NAT in front of the initiator, so treating IP1 as being within the domain of the responder's SPD isn't appropriate; we need to use IPN1. 2) NATs aside, the responder knows that the initiator identifies IP1 with the initiator itself (because the initiator proposed transport mode), so treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps as some address behind the initiator for which it is acting as a gateway -- isn't appropriate, because the initiator could not possibly have had gateways in mind. 3) The responder has detected a NAT in front of itself, so treating IPN2 as being within the domain of the responder's SPD isn't appropriate; we need to use IP2. 4) NATs aside, the responder knows that the initiator identifies IPN2 as the responder (because the initiator proposed transport mode), so treating IPN2 as anything other than the responder (i.e., IP2) -- as though it were some address behind the responder for which the responder is acting as a gateway -- isn't appropriate, because the initiator could not possibly have had gateways in mind. I don't think this is an appropriate way for the responder to interpret TSi and TSr. I propose that the MUST above be changed to "MUST fail the SA negotiation." Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development 1-919-254-1388 (T/L: 444-1388) http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yaron Sheffer Cc: "ipsec@ietf.org" Date: 08/26/2009 12:01 PM Subject: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Yaron Sheffer writes: > [2.23, NAT Traversal] > > o Implementations MUST process received UDP-encapsulated ESP packets > > even when no NAT was detected. > > > > o The original source and destination IP address required for the > > transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) > > are obtained from the Traffic Selectors associated with the > > exchange. In the case of NAT traversal, the Traffic Selectors > > MUST contain exactly one IP address, which is then used as the > > original IP address. > > Tero: > > Getting original source and destination IP address from the traffic > selectors do not really work currently. Especially when combined with > the selectors from the packet and when responder is behind nat or > similar problems. > > Paul: Not done. Specify replacement text and discuss on the mailing list. > > People who care about Transport Mode are requested to help resolve this NAT > Traversal issue. I wrote better long description about the problem, and also proposed solution text at 2009-04-07: http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006323998525761E_= Content-Type: text/html; charset="US-ASCII"
Tero, I am not comfortable with the following statement:

        . . . thus it will send back traffic selectors having IPN1 and IP2 as their IP addresses . . .

I would prefer that the server re-map the TS values back to IP1 and IPN2 when sending its response.  This is consistent with the general expectation that the response's TS payloads are a subset of the request's payloads.  The client does not absolutely need this information (it would perhaps help for deterministic checksum fixup, however in transport mode as long as an integrity algorithm is used the checksum provides no additional value anyway).  I think it is also advantageous to contain this fixup processing to one code path (processing TS payloads in received requests), and it also simplifies the response message processing (the client does not need to complicate its checks to verify that the response's TS payloads are a subset of the request's).  This separation of responsibility is more advantageous to a client implementation that needs to be as minimal as possible.

Finally, what I propose above is how our own IKEv1 implementation works in cases where ID payloads are sent for transport mode. :)  As a responder we found it best to bend over backwards to cater to the initiator's view of the world.

I'm also concerned about the following statement:

        After this it does SPD lookup based on those new traffic selectors. . . .
        If entry is found but it does not allow transport mode, then MUST
        undo the address substitution and redo the SPD lookup using the
        original traffic selectors. . . .

This statement is incoherent to me.  From the fact that the initiator proposed transport mode, it is clear that the initiator identifies TSi with itself and TSr with the server.  The address substitution exactly translates these addresses into the domain of the responder's SPD.  If the responder's policy indicates that transport mode is not acceptable for this SPD entry, then I think the only possible outcome is that SA negotiation should be failed.  No other SPD entry could possibly match the initiator's intentions.  However, the MUST quoted above causes the responder to treat these addresses in an incoherent way:

1) The responder has detected a NAT in front of the initiator, so treating IP1 as being within the domain of the responder's SPD isn't appropriate; we need to use IPN1.
2) NATs aside, the responder knows that the initiator identifies IP1 with the initiator itself (because the initiator proposed transport mode), so treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps as some address behind the initiator for which it is acting as a gateway -- isn't appropriate, because the initiator could not possibly have had gateways in mind.
3) The responder has detected a NAT in front of itself, so treating IPN2 as being within the domain of the responder's SPD isn't appropriate; we need to use IP2.
4) NATs aside, the responder knows that the initiator identifies IPN2 as the responder (because the initiator proposed transport mode), so treating IPN2 as anything other than the responder (i.e., IP2) -- as though it were some address behind the responder for which the responder is acting as a gateway -- isn't appropriate, because the initiator could not possibly have had gateways in mind.

I don't think this is an appropriate way for the responder to interpret TSi and TSr.  I propose that the MUST above be changed to "MUST fail the SA negotiation."


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


From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf@checkpoint.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 08/26/2009 12:01 PM
Subject: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP




Yaron Sheffer writes:
> [2.23, NAT Traversal]
> >     o  Implementations MUST process received UDP-encapsulated ESP packets
> >        even when no NAT was detected.
> >
> >     o  The original source and destination IP address required for the
> >        transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
> >        are obtained from the Traffic Selectors associated with the
> >        exchange.  In the case of NAT traversal, the Traffic Selectors
> >        MUST contain exactly one IP address, which is then used as the
> >        original IP address.
>  
> Tero:
>  
> Getting original source and destination IP address from the traffic
> selectors do not really work currently. Especially when combined with
> the selectors from the packet and when responder is behind nat or
> similar problems.
>  
> Paul: Not done. Specify replacement text and discuss on the mailing list.
>  
> People who care about Transport Mode are requested to help resolve this NAT
> Traversal issue.

I wrote better long description about the problem, and also proposed
solution text at 2009-04-07:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 006323998525761E_=-- From kivinen@iki.fi Wed Aug 26 23:57:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DB73A6CC1; Wed, 26 Aug 2009 23:57:31 -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 dOFzuk-wB4NZ; Wed, 26 Aug 2009 23:57:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 301823A6CA7; Wed, 26 Aug 2009 23: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 n7R6vSDO018883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 09:57:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7R6vPlp026652; Thu, 27 Aug 2009 09:57:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19094.11861.685058.59716@fireball.kivinen.iki.fi> Date: Thu, 27 Aug 2009 09:57:25 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19093.15301.348253.446035@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 44 min Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 06:57:31 -0000 David Wierbowski writes: > I agree with Tero that Yoav's proposed text adds clarity and effectively it > does not add a new MUST; however, to address Paul's concern can we just > change the words "MUST be" to the word "are" or lower case "should be?" > For example: > > 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 are used, only the > first of which holds the public key used to validate the sender's > AUTH payload. This text looks good for me. And I think it is important to add this to X.509 Certificate - Signature (4) case, even when we have some generic text elsewhere saying same thing, as this is the most common case people are using now. > As Tero points out, this is the only way to send a chain this using X.509 > Certificate - Signature.encoding. MUST terminology really is not needed in > my opinion. Agreed. I think in addition to that text we might want to add some generic text to the final paragraph saying: Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). In case those formats which contain one certificate are used and multiple certificates are to be sent then each certificate are sent as separate Certificate Payload. Or add similar text than what is in the 3.7 Certificate Request Payload which have following sentence at the end of first paragraph "If multiple CAs are trusted and the certificate encoding does not allow a list, then multiple Certificate Request payloads would need to be transmitted." One more thing, do we want to explictly mention that it is very common to mix multiple types of certificate payloads, i.e. send certificate multiple payloads some having X.509 Certificate - Signature (4) format and some having Certificate Revocation List (7) format. Another combination could be Raw RSA Key (11) and X.509 Certificate - Signature (4). In that case the Raw RSA Key (11) format is meant for minimal implementations who have the raw RSA key of the other end statically configured to their policy, and the X.509 Certificate - Signature (4) format is meant for full implementations which can process and validate certificates. Note also that not all certificates are there to form a chain, they can also provide other things like CRLs or even multiple different chains towards the different CAs (in case the private/public key use has certificates from multiple CAs, and other end didn't indicate any known CA), so the extra certificate payloads (after the first one used to sign the AUTH payload) are there just to help validation of the first certificate, not necessarely to form a chain. -- kivinen@iki.fi From kivinen@iki.fi Thu Aug 27 01:14: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 724793A68B9; Thu, 27 Aug 2009 01:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqaq42D1k7LT; Thu, 27 Aug 2009 01:14:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A57A13A689A; Thu, 27 Aug 2009 01:14:47 -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 n7R8EnBu019657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 11:14:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7R8Em89022425; Thu, 27 Aug 2009 11:14: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: <19094.16504.238846.676243@fireball.kivinen.iki.fi> Date: Thu, 27 Aug 2009 11:14:48 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 24 min Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 08:14:49 -0000 Scott C Moonen writes: > Tero, I am not comfortable with the following statement: > > . . . thus it will send back traffic selectors having IPN1 and IP2 > as their IP addresses . . . > > I would prefer that the server re-map the TS values back to IP1 and IPN2 > when sending its response. This is not possible, as the other end needs to know the address if IPN1 and IP2 (those are not known to him otherwise). Those addresses are used as original source and destination addresses for incremental checksum fixup. > This is consistent with the general > expectation that the response's TS payloads are a subset of the request's > payloads. Yes, but then we still would have problem that we do not get the original addresses from anywhere. Currently IKEv2 says they are taken from the traffic selectors, but if we do not send IPN1 and IP2 back from responder to initiator, initiator does not get them anywhere. > The client does not absolutely need this information (it would > perhaps help for deterministic checksum fixup, however in transport mode > as long as an integrity algorithm is used the checksum provides no > additional value anyway). RFC3948 do want them to do incremental checksum fixup, and one of the reasons we want to modify this text is to provide that information. > I think it is also advantageous to contain this > fixup processing to one code path (processing TS payloads in received > requests), and it also simplifies the response message processing (the > client does not need to complicate its checks to verify that the > response's TS payloads are a subset of the request's). This separation of > responsibility is more advantageous to a client implementation that needs > to be as minimal as possible. Yes, it might make it bit more simplier, but would loose functionality that is supposed to be there. The initiators processing of the responders reply is quite simple anyways, i.e. check if USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and if so store traffic selectors as original addresses, and replace them similarly as is done in other cases. Then normal processing can continue without any changes (i.e. traffic selector verification, IPsec SA installing etc). > Finally, what I propose above is how our own IKEv1 implementation works in > cases where ID payloads are sent for transport mode. :) As a responder we > found it best to bend over backwards to cater to the initiator's view of > the world. In IKEv1 there is separate payloads for sending the original addresses. In IKEv2 we do not have that, thus we must use traffic selectors for that. > I'm also concerned about the following statement: > > After this it does SPD lookup based on those new traffic > selectors. . . . > If entry is found but it does not allow transport mode, then MUST > undo the address substitution and redo the SPD lookup using the > original traffic selectors. . . . > > This statement is incoherent to me. From the fact that the initiator > proposed transport mode, it is clear that the initiator identifies TSi > with itself and TSr with the server. No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full choice of ignoring it and using tunnel mode instead. TSi and TSr do NOT identify initiator at all, initiator is already identified by the ID payloads. TSi and TSr are used to select suitable SPD entry for the given identified initiator. As for transport-mode NAT-T case the original TSi and TSr can be quite unknown for the responder, we first try with the converted addresses, but if we need to fall back to tunnel-mode NAT-T, then we want to keep original traffic selectors as now the packets exiting from the tunnel will have those addresses (i.e. packets coming from the tunnel will have IP1 and IPN2 as their source and destination addresses, as NAT in the middle does not substitute them). > The address substitution exactly > translates these addresses into the domain of the responder's SPD. If the > responder's policy indicates that transport mode is not acceptable for > this SPD entry, then I think the only possible outcome is that SA > negotiation should be failed. No other SPD entry could possibly match the > initiator's intentions. Initiator asked that if possible use transport mode with these addresses, if transport mode is not possible then use tunnel mode. Even if transport mode was not allowed, it is possible that responder do have tunnel mode rule that is allowed for that client even when transport mode was not. I do not see how you can claim that "No other SPD entry" could not be found, as initiator only gave hint that it would like to use transport mode. The use of tunnel vs transport mode is fully based on the responders policy. > However, the MUST quoted above causes the > responder to treat these addresses in an incoherent way: > > 1) The responder has detected a NAT in front of the initiator, so treating > IP1 as being within the domain of the responder's SPD isn't appropriate; > we need to use IPN1. Yes, for transport mode. For tunnel mode the IP1 is within the domain of responder's SPD as that is what responder will see in the packets coming out from the tunnel. > 2) NATs aside, the responder knows that the initiator identifies IP1 with > the initiator itself (because the initiator proposed transport mode), so > treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps > as some address behind the initiator for which it is acting as a gateway > -- isn't appropriate, because the initiator could not possibly have had > gateways in mind. I do not understand that statement at all. Other end is identified by the ID payloads, not by traffic selectors or by IP-addresses. If NATs are involved it is completely possible that responder have multiple clients connecting to it each having same IP1 (10.0.0.1) as their TSi field. Also it is possible that it has multiple clients using different IP1, but using same IPN1 as their outer address (but different ports for UDP encapsulation). RFC 3948 security considerations section has text about these different overlapping address problems. > 3) The responder has detected a NAT in front of itself, so treating IPN2 > as being within the domain of the responder's SPD isn't appropriate; we > need to use IP2. Again only for transport mode. For tunnel mode IPN2 is again ok, as that is the packet which is exiting from the tunnel. Of course if tunnel mode was used instead of transport mode then the implementation must use some method to make sure that those packets exiting from the tunnel and having destination address of IPN2 are still directly processed by the local stack. > 4) NATs aside, the responder knows that the initiator identifies IPN2 as > the responder (because the initiator proposed transport mode), so treating > IPN2 as anything other than the responder (i.e., IP2) -- as though it were > some address behind the responder for which the responder is acting as a > gateway -- isn't appropriate, because the initiator could not possibly > have had gateways in mind. > > I don't think this is an appropriate way for the responder to interpret > TSi and TSr. I propose that the MUST above be changed to "MUST fail the > SA negotiation." That would be against the 1.3.1 of the IKEv2bis or 3.10.1 of RFC4306 which says: ... If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. -- kivinen@iki.fi From yaronf@checkpoint.com Thu Aug 27 01:35: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 DB21C3A6972; Thu, 27 Aug 2009 01:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 aVtLL77GyAfT; Thu, 27 Aug 2009 01:35:36 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2FB763A6AE4; Thu, 27 Aug 2009 01:35:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1DDE729C004; Thu, 27 Aug 2009 11:36:00 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D4214200E09; Thu, 27 Aug 2009 11:35:59 +0300 (IDT) X-CheckPoint: {4A9643FD-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 n7R8ZZ3d005227; Thu, 27 Aug 2009 11:35:35 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 27 Aug 2009 11:35:33 +0300 From: Yaron Sheffer To: Tero Kivinen , David Wierbowski Date: Thu, 27 Aug 2009 11:35:34 +0300 Thread-Topic: [IPsec] #107: Sending certificate chains in IKEv2 Thread-Index: Acom46cgvFAIXsrYQDqPli/URlImxQADMRFg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13619FF@il-ex01.ad.checkpoint.com> References: <19093.15301.348253.446035@fireball.kivinen.iki.fi> <19094.11861.685058.59716@fireball.kivinen.iki.fi> In-Reply-To: <19094.11861.685058.59716@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_0000_01CA270A.7C9B01D0" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 08:35:36 -0000 ------=_NextPart_000_0000_01CA270A.7C9B01D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All of which taken together indicates the Sec. 3.6 needs to be rewritten. It'll be hard enough to get interoperability with all these options, but certainly if much remains undocumented. We might even need to resort to defining what the mythical "minimal implementation" is allowed to do. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, August 27, 2009 9:57 > To: David Wierbowski > Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; Yaron Sheffer > Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 > > David Wierbowski writes: > > I agree with Tero that Yoav's proposed text adds clarity and effectively > it > > does not add a new MUST; however, to address Paul's concern can we just > > change the words "MUST be" to the word "are" or lower case "should be?" > > For example: > > > > 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 are used, only the > > first of which holds the public key used to validate the sender's > > AUTH payload. > > This text looks good for me. And I think it is important to add this > to X.509 Certificate - Signature (4) case, even when we have some > generic text elsewhere saying same thing, as this is the most common > case people are using now. > > > As Tero points out, this is the only way to send a chain this using > X.509 > > Certificate - Signature.encoding. MUST terminology really is not needed > in > > my opinion. > > Agreed. > > I think in addition to that text we might want to add some generic > text to the final paragraph saying: > > Some of the certificate formats can only contain one certificate > (for example formats 4, 7, 11 and 12), and some can contain > multiple certificates (for example 1, 13). In case those formats > which contain one certificate are used and multiple certificates > are to be sent then each certificate are sent as separate > Certificate Payload. > > Or add similar text than what is in the 3.7 Certificate Request > Payload which have following sentence at the end of first paragraph > "If multiple CAs are trusted and the certificate encoding does not > allow a list, then multiple Certificate Request payloads would need to > be transmitted." > > One more thing, do we want to explictly mention that it is very common > to mix multiple types of certificate payloads, i.e. send certificate > multiple payloads some having X.509 Certificate - Signature (4) format > and some having Certificate Revocation List (7) format. > > Another combination could be Raw RSA Key (11) and X.509 Certificate - > Signature (4). In that case the Raw RSA Key (11) format is meant for > minimal implementations who have the raw RSA key of the other end > statically configured to their policy, and the X.509 Certificate - > Signature (4) format is meant for full implementations which can > process and validate certificates. > > Note also that not all certificates are there to form a chain, they > can also provide other things like CRLs or even multiple different > chains towards the different CAs (in case the private/public key use > has certificates from multiple CAs, and other end didn't indicate any > known CA), so the extra certificate payloads (after the first one used > to sign the AUTH payload) are there just to help validation of the > first certificate, not necessarely to form a chain. > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0000_01CA270A.7C9B01D0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNzA4MzUzMlowIwYJKoZIhvcNAQkEMRYEFEKJxS/uPcY/ wd6QghnBDztUkl96MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA fwRwVB4cMqVdNf0LWKXyJ9eOT73m9RhPhmoLPbbVAcmadaNL9/ZtzUDR9V9Av1hePb9bNG3bfrlW hNQOE8X+8uDrm9LKOlA5TU7Yy5TGKdNl1S6tzZUcJeCyNIlo/+ayR6vnuEXalktldtoZ1pig0wxD Chv4V7CsJkRW58FQd6cbmVSFzXDJQy33ZSh1GmLRemo3sYDg1lyWHMK0nb+B1cgfTItlogbVE2k6 ZwN3yRI5REpNPiVPouunWKRXlRprtxSvxiN8B/WDW6/3eOuTV19VoqHzCn84EDfUPvIjo3F9papv TxZ+dG1J2YvlszHXrS7eUimM0IZDO317XYimMAAAAAAAAA== ------=_NextPart_000_0000_01CA270A.7C9B01D0-- From bhaskie@gmail.com Thu Aug 27 00:19: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 E4A2B3A6D12 for ; Thu, 27 Aug 2009 00:19:32 -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 GIOM6shDl-4S for ; Thu, 27 Aug 2009 00:19:32 -0700 (PDT) Received: from mail-pz0-f187.google.com (mail-pz0-f187.google.com [209.85.222.187]) by core3.amsl.com (Postfix) with ESMTP id 3637C3A6A22 for ; Thu, 27 Aug 2009 00:19:32 -0700 (PDT) Received: by pzk17 with SMTP id 17so986749pzk.32 for ; Thu, 27 Aug 2009 00:19:36 -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=4TNMYXf/5ZdI4FBlHZcn6dWZJFI2BeObpf0SrPLOpz0=; b=MKcj1Xe57TiO1aj8S5L1cXi2PJW3YKeIQK8hSorIjvoL+O+n/d3fuxPs+zp08rtVys 140DJ55IcqkA+LGpm3OJL5BV86GriNafeT1yDx3aOwI7wSwIoT9tPlsPjig2FgTZQjn6 y3BlVjurNi1hQp7zjeFJF14NS3mKQJ/dHS2hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=v16Sl0pVYYxhz74Sva3f1iCQnc7UarIdYYZhmmH2W3io/+1d7uDDK3IEwefPUwMhoK nziCsz1869hBzKeGfbeSvdgunEDxKch5wj87WDwasR2xMIOaAABcKs9nuw+UJkiS0Mqc gvabwwFLo4l4Bi0hwKFRgL9CBL8/29yJxTuHU= MIME-Version: 1.0 Received: by 10.140.199.6 with SMTP id w6mr4297212rvf.58.1251357576514; Thu, 27 Aug 2009 00:19:36 -0700 (PDT) Date: Thu, 27 Aug 2009 12:49:36 +0530 Message-ID: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> From: Bhaskar Dutta To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2171ed5cbf604721a631e Subject: [IPsec] SCTP Multihoming with IPSec (RFC 3554) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 27 Aug 2009 09:05:59 -0000 --000e0cd2171ed5cbf604721a631e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Does any IPSec implementation support RFC 3554 (On the Use of Stream Control Transmission Protocol (SCTP) with IPsec)? I am working on SCTP over IPSec (linux 2.6.27) and in case of multihoming unless RFC 3554 is supported I will need to configure 2 * n * m Security Associations. TIA. Regards, Bhaskar --000e0cd2171ed5cbf604721a631e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Does any IPSec implementation support RFC 3554 (On the Use of Stream Control
Transmission Protocol (SCTP) with IPsec)?

I am working on SCTP over IPSec (linux 2.6.27) and in case of multihoming unless
RFC 3554 is supported I will need to configure 2 * n * m Security Associations.

TIA.

Regards,
Bhaskar

--000e0cd2171ed5cbf604721a631e-- From Pasi.Eronen@nokia.com Thu Aug 27 04:05: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 58D103A6D42 for ; Thu, 27 Aug 2009 04:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.285, 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 JLI+Ftv8J2yb for ; Thu, 27 Aug 2009 04:05:52 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C92563A6D01 for ; Thu, 27 Aug 2009 04:05:51 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7RB5e0f026280; Thu, 27 Aug 2009 14:05:47 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:05:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:05:44 +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, 27 Aug 2009 13:05:44 +0200 From: To: , Date: Thu, 27 Aug 2009 13:05:43 +0200 Thread-Topic: #79: Remove CP from Create_Child_SA? Thread-Index: AcolyMQq9n8TZkPbQeWuTriGCYMdmwBPSqAA Message-ID: <808FD6E27AD4884E94820BC333B2DB773C0145D42A@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB773C0145D42ANOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2009 11:05:44.0753 (UTC) FILETIME=[52E55A10:01CA2706] X-Nokia-AV: Clean Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 11:05:57 -0000 --_000_808FD6E27AD4884E94820BC333B2DB773C0145D42ANOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), = it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that sectio= n 2.19 says that "request for such a temporary address can be included in a= ny request to create a CHILD_SA (including the implicit request in message = 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a p= arenthetical remark, it's really the only one anyone uses. I don't think i= t makes sense to assign a different IP address for each SA, and I don't thi= nk anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP= payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time b= efore the client needs to renew the address with the gateway (probably rene= w the lease with a DHCP server). With such an attribute, it made sense for = the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked = as "RESERVED". Since we've done that, I suggest we remove the CP payload fr= om the Create Child SA exchange in appendix A, and reword section 2.19 to r= eflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav's proposal.= This would be a protocol change (even if we don't understand what the curr= ent semantics is...), so we shouldn't do it unless we're quite sure. Thanks, Yaron --_000_808FD6E27AD4884E94820BC333B2DB773C0145D42ANOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would repeat my comment from April:

http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.= html

 

If we continue to allow CP in INFORMATIONAL exchange (and IM= HO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same= semantics).

 

Best regards,

Pasi

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = ext Yaron Sheffer
Sent: 26 August, 2009 00:23
To: ipsec@ietf.org
Subject: [IPsec] #79: Remove CP from Create_Child_SA?

 

Yoav:

 

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

 

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

 

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

 

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

 

 

Everyone, please comment on the above, even if you support Yoav’s proposal. Thi= s would be a protocol change (even if we don’t understand what the current seman= tics is…), so we shouldn’t do it unless we’re quite sure.

 

Thanks,

          &nb= sp; Yaron

 

--_000_808FD6E27AD4884E94820BC333B2DB773C0145D42ANOKEUMSG01mgd_-- From yaronf@checkpoint.com Thu Aug 27 04:26:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99A63A6F9C for ; Thu, 27 Aug 2009 04:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.303, 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 zjjZvdbyNchs for ; Thu, 27 Aug 2009 04:26:22 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AB2E03A6EB0 for ; Thu, 27 Aug 2009 04:26:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A539729C004; Thu, 27 Aug 2009 14:26:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 53A76200E09; Thu, 27 Aug 2009 14:26:50 +0300 (IDT) X-CheckPoint: {4A966C06-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 n7RBQP3d022701; Thu, 27 Aug 2009 14:26:25 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 27 Aug 2009 14:26:23 +0300 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Thu, 27 Aug 2009 14:26:23 +0300 Thread-Topic: #79: Remove CP from Create_Child_SA? Thread-Index: AcolyMQq9n8TZkPbQeWuTriGCYMdmwBPSqAAAADN8DA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E1361A49@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB773C0145D42A@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C0145D42A@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_0038_01CA2722.5A8B2440" MIME-Version: 1.0 Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 11:26:27 -0000 ------=_NextPart_000_0038_01CA2722.5A8B2440 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0039_01CA2722.5A8B2440" ------=_NextPart_001_0039_01CA2722.5A8B2440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'll second that. Yaron _____ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 27, 2009 14:06 To: Yaron Sheffer; ipsec@ietf.org Subject: RE: #79: Remove CP from Create_Child_SA? I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that "request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as "RESERVED". Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav's proposal. This would be a protocol change (even if we don't understand what the current semantics is.), so we shouldn't do it unless we're quite sure. Thanks, Yaron ------=_NextPart_001_0039_01CA2722.5A8B2440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll second = that.

 

      =       Yaron

 

From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, August = 27, 2009 14:06
To: Yaron Sheffer; ipsec@ietf.org
Subject: RE: #79: Remove = CP from Create_Child_SA?

 

I would = repeat my comment from April:

http://www.i= etf.org/mail-archive/web/ipsec/current/msg04245.html

 <= /o:p>

If we = continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be = allowed in CREATE_CHILD_SA, too (with exactly same semantics). =

 <= /o:p>

Best = regards,

Pasi

 <= /o:p>

From: = ipsec-bounces@ietf.org = [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Yaron = Sheffer
Sent: 26 August, 2009 = 00:23
To: ipsec@ietf.org
Subject: [IPsec] #79: = Remove CP from Create_Child_SA?

 

Yoav:

 

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

 

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

 

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

 

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

 

 

Everyone, please comment on the above, even if you = support Yoav’s proposal. This would be a protocol change (even if we = don’t understand what the current semantics is…), so we shouldn’t do it = unless we’re quite sure.

 

Thanks,

         =    Yaron

 

------=_NextPart_001_0039_01CA2722.5A8B2440-- ------=_NextPart_000_0038_01CA2722.5A8B2440 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyNzExMjYyM1owIwYJKoZIhvcNAQkEMRYEFEh2n1u2GpyH YTjFnUCACYd5eP+uMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA eM7WWGfCqn2DfgRnW+LQk0vWncECAhJHcTDrDb+fXBzZRCXmI/g9J8ZqIhSlghF1npnza3/drP5l s9S3tyPMwlSfQnG21h7fqNXMcsmztkecP6riAiLKWbKN7gSpsVV7HxeJYUk1tbbOCHqY5YyjDeni acuFPZ7Iqtrnh4bAd4J2QctN5pjA1+VYxjEnLjfyQBVtXztUaZjG/ogXvvPE2RFRNYUu1I9aN6gj i1CceyF3sC1f0GuAQWFSiho8mHXHw0yOKXf5iAZyG47GLp9n+Dysjk6ADyJilY4OMruXYTEvu5dh NKIHtiOlS/EHFmyge3bSowF3uwI+shVuLhUynAAAAAAAAA== ------=_NextPart_000_0038_01CA2722.5A8B2440-- From ynir@checkpoint.com Thu Aug 27 04:48: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 EF31D3A691E for ; Thu, 27 Aug 2009 04:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 lxkgYOopoc6T for ; Thu, 27 Aug 2009 04:48:32 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 675293A6D9D for ; Thu, 27 Aug 2009 04:48:25 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B28A829C004; Thu, 27 Aug 2009 14:48:55 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6F09E200E09; Thu, 27 Aug 2009 14:48:55 +0300 (IDT) X-CheckPoint: {4A967132-2-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7RBhG46027220; Thu, 27 Aug 2009 14:48:30 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 27 Aug 2009 14:47:45 +0300 From: Yoav Nir To: " " Date: Thu, 27 Aug 2009 14:47:45 +0300 Thread-Topic: [IPsec] #79: Remove CP from Create_Child_SA? Thread-Index: AconDDFTsBOFnCcmSqeMzXt+9uD/yg== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB773C0145D42A@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C0145D42A@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: multipart/alternative; boundary="_000_B3B112E736DF4BDFA4AF7241CDA5B8B3checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 11:48:34 -0000 --_000_B3B112E736DF4BDFA4AF7241CDA5B8B3checkpointcom_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I disagree. Payloads in a particular CREATE_CHILD_SA exchange should be specifically re= lated to the SA being created. The IKE_AUTH exchange is different, because= it is used to set up everything we need to get an IPsec SA going. We do not use the CREATE_CHILD_SA to delete old SAs, to query application v= ersions or to advertise capabilities through notifications or Vendor IDs, s= o it should also not include IP address maintenance. That's what INFORMATI= ONAL exchanges are for. On Aug 27, 2009, at 2:05 PM, > > wrote: I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), = it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that sectio= n 2.19 says that "request for such a temporary address can be included in a= ny request to create a CHILD_SA (including the implicit request in message = 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a p= arenthetical remark, it's really the only one anyone uses. I don't think i= t makes sense to assign a different IP address for each SA, and I don't thi= nk anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP= payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time b= efore the client needs to renew the address with the gateway (probably rene= w the lease with a DHCP server). With such an attribute, it made sense for = the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked = as "RESERVED". Since we've done that, I suggest we remove the CP payload fr= om the Create Child SA exchange in appendix A, and reword section 2.19 to r= eflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav=92s proposa= l. This would be a protocol change (even if we don=92t understand what the = current semantics is=85), so we shouldn=92t do it unless we=92re quite sure= . Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =0D=0A Email secured by Check Point=0D=0A --_000_B3B112E736DF4BDFA4AF7241CDA5B8B3checkpointcom_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

I disagree.

Payloads in a particular CRE= ATE_CHILD_SA exchange should be specifically related to the SA being create= d.  The IKE_AUTH exchange is different, because it is used to set up e= verything we need to get an IPsec SA going.

We do = not use the CREATE_CHILD_SA to delete old SAs, to query application version= s or to advertise capabilities through notifications or Vendor IDs, so it s= hould also not include IP address maintenance.  That's what INFORMATIO= NAL exchanges are for.


On Aug 27, 20= 09, at 2:05 PM, <Pasi.Eronen@no= kia.com> <Pasi.Eronen@no= kia.com> wrote:

<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; m= argin-left: 0cm; font-size: 12pt; font-family: 'Times New Roman', serif; ">= I would repeat my comment from April:
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Yaron Sheffer
Sent: 26 August, 2009 00:23
To: ipsec@ietf.org
Subject: [IPsec] #79= : Remove CP from Create_Child_SA?
=  
Yoav:
 
Patricia noted in a = post to the IPsec mailing list (12/12/2008) that section 2.19 says that "re= quest for such a temporary address can be included in any request to create= a CHILD_SA (including the implicit request in message 3) by including a CP= payload."
 
IMO the normal way of doing= things is in this message 3, so rather than a parenthetical remark, it's r= eally the only one anyone uses.  I don't think it makes sense to assig= n a different IP address for each SA, and I don't think anyone actually int= ended for this to be implied.
 
=
In RFC 4= 306, section 3.15, one of the attributes that can be sent in the CP payload= is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before th= e client needs to renew the address with the gateway (probably renew the le= ase with a DHCP server). With such an attribute, it made sense for the clie= nt to renew the address along with rekeying some CHILD_SA. =
 
In the bis document, we've deprecated this attri= bute, and it is now marked as "RESERVED". Since we've done that, I suggest = we remove the CP payload from the Create Child SA exchange in appendix A, a= nd reword section 2.19 to reflect that requesting an IP address is only acc= eptable during IKE_AUTH.
 
=  
Everyone, please comment on the above, even if you support= Yoav=92s proposal. This would be a protocol change (even if we don=92t und= erstand what the current semantics is=85), so we shouldn=92t do it unless w= e=92re quite sure.
 
Thanks,=
            Yar= on
 
_______________= ________________________________
IPsec mailing list
IPsec@= ietf.org
https://www.ietf.org/mailm= an/listinfo/ipsec


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

= <= /html>= --_000_B3B112E736DF4BDFA4AF7241CDA5B8B3checkpointcom_-- From kivinen@iki.fi Thu Aug 27 05:14:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D9A3A691E for ; Thu, 27 Aug 2009 05:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 iwp2MZtlTNwI for ; Thu, 27 Aug 2009 05:13:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F42313A6A22 for ; Thu, 27 Aug 2009 05:13: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 n7RCDwNn001948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 15:13:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7RCDvdx016438; Thu, 27 Aug 2009 15:13:57 +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: <19094.30853.967442.754565@fireball.kivinen.iki.fi> Date: Thu, 27 Aug 2009 15:13:57 +0300 From: Tero Kivinen To: Bhaskar Dutta In-Reply-To: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> References: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 38 min Cc: ipsec@ietf.org Subject: [IPsec] SCTP Multihoming with IPSec (RFC 3554) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 27 Aug 2009 12:14:00 -0000 Bhaskar Dutta writes: > Does any IPSec implementation support RFC 3554 (On the Use of Stream Control > Transmission Protocol (SCTP) with IPsec)? Yes. Altough I do not know if it has been really tested (mostly just using sctp_test and single pair of ip-addresses). > I am working on SCTP over IPSec (linux 2.6.27) and in case of multihoming > unless > RFC 3554 is supported I will need to configure 2 * n * m Security > Associations. With IKEv2 you should just create one SA having multiple source and destination addresses. Then if more addresses are later added you need to create new SA with all of the addresses (or just new addresses). -- kivinen@iki.fi From wierbows@us.ibm.com Thu Aug 27 06:09: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 1DF383A67F1; Thu, 27 Aug 2009 06:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[AWL=1.131, 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 yrx-QZpK4HYB; Thu, 27 Aug 2009 06:09:02 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 35F913A69E2; Thu, 27 Aug 2009 06:09:02 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7RD8vqL025695; Thu, 27 Aug 2009 09:08:57 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7RD92qV224894; Thu, 27 Aug 2009 09:09:02 -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 n7RD91lP017803; Thu, 27 Aug 2009 09:09:01 -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 n7RD91uA017784; Thu, 27 Aug 2009 09:09:01 -0400 In-Reply-To: <19094.11861.685058.59716@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Thu, 27 Aug 2009 09:08:59 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 08/27/2009 09:09:00 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFC8CDFD774048f9e8a93df938690918c0ABBFC8CDFD77404" Content-Disposition: inline Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 13:09:04 -0000 --0__=0ABBFC8CDFD774048f9e8a93df938690918c0ABBFC8CDFD77404 Content-type: text/plain; charset=US-ASCII >David Wierbowski writes: >> I agree with Tero that Yoav's proposed text adds clarity and effectively it >> does not add a new MUST; however, to address Paul's concern can we just >> change the words "MUST be" to the word "are" or lower case "should be?" >> For example: >> >> 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 are used, only the >> first of which holds the public key used to validate the sender's >> AUTH payload. > >This text looks good for me. And I think it is important to add this >to X.509 Certificate - Signature (4) case, even when we have some >generic text elsewhere saying same thing, as this is the most common >case people are using now. > >> As Tero points out, this is the only way to send a chain this using X.509 >> Certificate - Signature.encoding. MUST terminology really is not needed in >> my opinion. > >Agreed. > >I think in addition to that text we might want to add some generic >text to the final paragraph saying: > > Some of the certificate formats can only contain one certificate > (for example formats 4, 7, 11 and 12), and some can contain > multiple certificates (for example 1, 13). In case those formats > which contain one certificate are used and multiple certificates > are to be sent then each certificate are sent as separate > Certificate Payload. > I agree that text like this should be added. I suggest some minor editorial changes (change "In case those formats" to "When" and "are" to "is": Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). When formats which contain one certificate are used and multiple certificates are to be sent then each certificate is sent as separate Certificate Payload. In that past I've asked if the first certificate payload is encoded using type 13 does the first certificate in the bundle have to be the one used to create the signature and you've answered yes. Perhaps we should also clarify that here. I do not think we can make such a statement when type 1 is used. I know of at least one vendor that uses type 1. The signing cert is not the first certificate in their PKCS #7 data. > >Or add similar text than what is in the 3.7 Certificate Request >Payload which have following sentence at the end of first paragraph >"If multiple CAs are trusted and the certificate encoding does not >allow a list, then multiple Certificate Request payloads would need to >be transmitted." I prefer your previous wording. > >One more thing, do we want to explictly mention that it is very common >to mix multiple types of certificate payloads, i.e. send certificate >multiple payloads some having X.509 Certificate - Signature (4) format >and some having Certificate Revocation List (7) format. > I agree that we should state that mixing multiple types of certificate payloads is allowed. The examples are helpful, but I'm not sure we need to include them in the text. >Another combination could be Raw RSA Key (11) and X.509 Certificate - >Signature (4). In that case the Raw RSA Key (11) format is meant for >minimal implementations who have the raw RSA key of the other end >statically configured to their policy, and the X.509 Certificate - >Signature (4) format is meant for full implementations which can >process and validate certificates. > >Note also that not all certificates are there to form a chain, they >can also provide other things like CRLs or even multiple different >chains towards the different CAs (in case the private/public key use >has certificates from multiple CAs, and other end didn't indicate any >known CA), so the extra certificate payloads (after the first one used >to sign the AUTH payload) are there just to help validation of the >first certificate, not necessarely to form a chain. I agree that we should stste the extra certificate payloads are there to help validation of the first certificate, not necessarely to form a single chain. >-- >kivinen@iki.fi --0__=0ABBFC8CDFD774048f9e8a93df938690918c0ABBFC8CDFD77404 Content-type: text/html; charset=US-ASCII Content-Disposition: inline


>David Wierbowski writes:
>> I agree with Tero that Yoav's proposed text adds clarity and effectively it
>> does not add a new MUST; however, to address Paul's concern can we just
>> change the words "MUST be" to the word "are" or lower case "should be?"
>> For example:
>>
>> 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 are used, only the
>> first of which holds the public key used to validate the sender's
>> AUTH payload.
>
>This text looks good for me. And I think it is important to add this
>to X.509 Certificate - Signature (4) case, even when we have some
>generic text elsewhere saying same thing, as this is the most common
>case people are using now.
>
>> As Tero points out, this is the only way to send a chain this using X.509
>> Certificate - Signature.encoding. MUST terminology really is not needed in
>> my opinion.
>
>Agreed.
>
>I think in addition to that text we might want to add some generic
>text to the final paragraph saying:
>
> Some of the certificate formats can only contain one certificate
> (for example formats 4, 7, 11 and 12), and some can contain
> multiple certificates (for example 1, 13). In case those formats
> which contain one certificate are used and multiple certificates
> are to be sent then each certificate are sent as separate
> Certificate Payload.
>

I agree that text like this should be added. I suggest some minor
editorial changes (change "In case those formats" to "When" and
"are" to "is":

Some of the certificate formats can only contain one certificate
(for example formats 4, 7, 11 and 12), and some can contain
multiple certificates (for example 1, 13). When formats
which contain one certificate are used and multiple certificates
are to be sent then each certificate is sent as separate
Certificate Payload.

In that past I've asked if the first certificate payload is encoded
using type 13 does the first certificate in the bundle have to be
the one used to create the signature and you've answered yes. Perhaps
we should also clarify that here. I do not think we can make such
a statement when type 1 is used. I know of at least one vendor that
uses type 1. The signing cert is not the first certificate in their
PKCS #7 data.

>
>Or add similar text than what is in the 3.7 Certificate Request
>Payload which have following sentence at the end of first paragraph
>"If multiple CAs are trusted and the certificate encoding does not
>allow a list, then multiple Certificate Request payloads would need to
>be transmitted."

I prefer your previous wording.

>
>One more thing, do we want to explictly mention that it is very common
>to mix multiple types of certificate payloads, i.e. send certificate
>multiple payloads some having X.509 Certificate - Signature (4) format
>and some having Certificate Revocation List (7) format.
>

I agree that we should state that mixing multiple types of
certificate payloads is allowed. The examples are helpful,
but I'm not sure we need to include them in the text.

>Another combination could be Raw RSA Key (11) and X.509 Certificate -
>Signature (4). In that case the Raw RSA Key (11) format is meant for
>minimal implementations who have the raw RSA key of the other end
>statically configured to their policy, and the X.509 Certificate -
>Signature (4) format is meant for full implementations which can
>process and validate certificates.
>
>Note also that not all certificates are there to form a chain, they
>can also provide other things like CRLs or even multiple different
>chains towards the different CAs (in case the private/public key use
>has certificates from multiple CAs, and other end didn't indicate any
>known CA), so the extra certificate payloads (after the first one used
>to sign the AUTH payload) are there just to help validation of the
>first certificate, not necessarely to form a chain.

I agree that we should stste the extra certificate payloads are there to
help validation of the first certificate, not necessarely to form a single
chain.

>--
>kivinen@iki.fi
 --0__=0ABBFC8CDFD774048f9e8a93df938690918c0ABBFC8CDFD77404-- From bhaskie@gmail.com Thu Aug 27 06:23: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 B28C528C580 for ; Thu, 27 Aug 2009 06:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch+athUNXALN for ; Thu, 27 Aug 2009 06:23:50 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id E614528C584 for ; Thu, 27 Aug 2009 06:23:24 -0700 (PDT) Received: by pzk38 with SMTP id 38so1095316pzk.5 for ; Thu, 27 Aug 2009 06:23:26 -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 :content-transfer-encoding; bh=fFpYN0qKeGd1TyMMe4u8y6NWDzVLx8Gs7mXSJ63mv1g=; b=oSzYUu7g+KQZ/BQohRg0fphSCRTqWZ8d2m1k8BKgiJssC14w+Vdi/pk1d+fyYmv/t6 So2HmISAzWb1/8oByHbMgGLl35iKBgwa+6U+MBX8KKJZ+2taVJ4xCOzTaW9KI2V5Mwqc 1UM5+3/dcAuK9NcNxcTn0kcasdtpOw/EsXZTQ= 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:content-transfer-encoding; b=CZEQMzHtO8VnV0O6ezLCXl5AUCk1FzFeQolbpBWPg/CVz1fx5GAPYeg8aCUoPvb2eY PAbezIh7HPOjY0CMwjg4s+IFIvtXUixI43ihNfZA+G69hKOyfCceO9E/6tXQFMiM8Q3l yLz4J60n4X3Ahnz05s5DP4HoIsctva8uYam4E= MIME-Version: 1.0 Received: by 10.140.157.9 with SMTP id f9mr4702555rve.165.1251379405991; Thu, 27 Aug 2009 06:23:25 -0700 (PDT) In-Reply-To: <19094.30853.967442.754565@fireball.kivinen.iki.fi> References: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> <19094.30853.967442.754565@fireball.kivinen.iki.fi> Date: Thu, 27 Aug 2009 18:53:25 +0530 Message-ID: <571fb4000908270623l40707e0dw9dbcc946357a73ea@mail.gmail.com> From: Bhaskar Dutta To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 27 Aug 2009 13:23:51 -0000 On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen wrote: > > Bhaskar Dutta writes: > > Does any IPSec implementation support RFC 3554 (On the Use of Stream Control > > Transmission Protocol (SCTP) with IPsec)? > > Yes. Altough I do not know if it has been really tested (mostly just > using sctp_test and single pair of ip-addresses). > > > I am working on SCTP over IPSec (linux 2.6.27) and in case of multihoming > > unless > > RFC 3554 is supported I will need to configure 2 * n * m Security > > Associations. > > With IKEv2 you should just create one SA having multiple source and > destination addresses. Then if more addresses are later added you need > to create new SA with all of the addresses (or just new addresses). > -- > kivinen@iki.fi Thanks a lot! I looked up for examples on setting up sainfo entries in racoon's remote.conf with multiple source/destination addresses but the man pages or searching the web did not lead to anything. Couldnt even find any examples with multiple entries in sainfo. Do you have any idea on how to write the sainfo entries in remote.conf and spdadd entries in setkey.conf that will work with multiple source/dest addresses? I did write to the ipsec-tools-users list but no luck yet. Thanks, Bhaskar From rsjenwar@gmail.com Thu Aug 27 10:06: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 50F9C3A699A for ; Thu, 27 Aug 2009 10:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.170, 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 s1yiMDKrjSeI for ; Thu, 27 Aug 2009 10:06:35 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 2AFFA3A6880 for ; Thu, 27 Aug 2009 10:06:35 -0700 (PDT) Received: by pzk38 with SMTP id 38so1243921pzk.5 for ; Thu, 27 Aug 2009 10:06:35 -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=/NnbF9CPttnK5wFxtRG8q0bL/gwX9Zj9nFiWBZGrBdk=; b=SeZZou6tnLj8+BTj2ec+eqOXgGf8+NMganpPtTo7RuN24+duz+SthAoA5vqjBm5eq8 T57ALuW03HU5duJ3LRAAj4e40KYUlqzc/Stwd04ShlrpEzYFrqjwNHC6u3COjkwlJFtx wvcbK13NKmtRH9EBsttFAiJyb3/qEmHdZZSvE= 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=Xx0wayDRQhjZ+65QfHdQ4tI07o98NDe8/TAEbI1V169ztuETV0LsZCb5L4QtAroiER 9/LcqVpakANxE9V80Hc/BJ6apV/3kVFTl6aY2EnsIJl4RtJyzG2FgM/jKjjycOl8FAVv h1FO2e+JlBoAikXuL3dtqIXXoNfpeexTNX3Cc= MIME-Version: 1.0 Received: by 10.143.129.2 with SMTP id g2mr759274wfn.56.1251392795353; Thu, 27 Aug 2009 10:06:35 -0700 (PDT) In-Reply-To: <571fb4000908270623l40707e0dw9dbcc946357a73ea@mail.gmail.com> References: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> <19094.30853.967442.754565@fireball.kivinen.iki.fi> <571fb4000908270623l40707e0dw9dbcc946357a73ea@mail.gmail.com> Date: Thu, 27 Aug 2009 22:36:35 +0530 Message-ID: <7ccecf670908271006y7e08c3adsea0430c4b22daada@mail.gmail.com> From: Raj Singh To: Bhaskar Dutta Content-Type: multipart/alternative; boundary=000e0cd5f6740aa5f80472229774 Cc: ipsec@ietf.org Subject: Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 27 Aug 2009 17:06:36 -0000 --000e0cd5f6740aa5f80472229774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Bhasker, This document will help you: http://www.ipsec-howto.org/ipsec-howto.pdf *It has sample configs for racoon. *Thanks & Regards, Raj On Thu, Aug 27, 2009 at 6:53 PM, Bhaskar Dutta wrote: > On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen wrote: > > > > Bhaskar Dutta writes: > > > Does any IPSec implementation support RFC 3554 (On the Use of Stream > Control > > > Transmission Protocol (SCTP) with IPsec)? > > > > Yes. Altough I do not know if it has been really tested (mostly just > > using sctp_test and single pair of ip-addresses). > > > > > I am working on SCTP over IPSec (linux 2.6.27) and in case of > multihoming > > > unless > > > RFC 3554 is supported I will need to configure 2 * n * m Security > > > Associations. > > > > With IKEv2 you should just create one SA having multiple source and > > destination addresses. Then if more addresses are later added you need > > to create new SA with all of the addresses (or just new addresses). > > -- > > kivinen@iki.fi > > Thanks a lot! > > I looked up for examples on setting up sainfo entries in racoon's > remote.conf with > multiple source/destination addresses but the man pages or searching the > web > did not lead to anything. Couldnt even find any examples with multiple > entries in sainfo. > > Do you have any idea on how to write the sainfo entries in remote.conf > and spdadd entries > in setkey.conf that will work with multiple source/dest addresses? > > I did write to the ipsec-tools-users list but no luck yet. > > Thanks, > Bhaskar > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000e0cd5f6740aa5f80472229774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bhasker,

This document will help you:
http://www.ipsec-howto.org/ipsec-howto.pdf
It has sample configs for racoon.

Thanks & Regards,=
Raj



On Thu, Aug 27, 2009 at 6:53 = PM, Bhaskar Dutta <bhaskie@gmail.com> wrote:
On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen <kivinen@iki.fi> wrote:
>
> Bhaskar Dutta writes:
> > Does any IPSec implementation support RFC 3554 (On the Use of Str= eam Control
> > Transmission Protocol (SCTP) with IPsec)?
>
> Yes. Altough I do not know if it has been really tested (mostly just > using sctp_test and single pair of ip-addresses).
>
> > I am working on SCTP over IPSec (linux 2.6.27) and in case of mul= tihoming
> > unless
> > RFC 3554 is supported I will need to configure 2 * n * m Security=
> > Associations.
>
> With IKEv2 you should just create one SA having multiple source and > destination addresses. Then if more addresses are later added you need=
> to create new SA with all of the addresses (or just new addresses). > --
> kivinen@iki.fi

Thanks a lot!

I looked up for examples on setting up sainfo entries in racoon's
remote.conf with
=C2=A0multiple source/destination addresses but the man pages or searching = the web
did not lead to anything. Couldnt even find any examples with multiple
entries in sainfo.

Do you have any idea on how to write the sainfo entries in remote.conf
and spdadd entries
in setkey.conf that will work with multiple source/dest addresses?

I did write to the ipsec-tools-users list but no luck yet.

Thanks,
Bhaskar
__________________________________= _____________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--000e0cd5f6740aa5f80472229774-- From Pasi.Eronen@nokia.com Thu Aug 27 12:29: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 9BFF328C2E5 for ; Thu, 27 Aug 2009 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 68KQdXZUwKAW for ; Thu, 27 Aug 2009 12:29:11 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CD06728C253 for ; Thu, 27 Aug 2009 12:29:11 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7RJRhv6019094; Thu, 27 Aug 2009 14:28:44 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 22:28:45 +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); Thu, 27 Aug 2009 22:28:44 +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, 27 Aug 2009 21:28:43 +0200 From: To: Date: Thu, 27 Aug 2009 21:28:41 +0200 Thread-Topic: [IPsec] #79: Remove CP from Create_Child_SA? Thread-Index: AconDDFTsBOFnCcmSqeMzXt+9uD/ygAP2tLQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773C0145D82F@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B4@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB773C0145D42A@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2009 19:28:44.0838 (UTC) FILETIME=[97A0DC60:01CA274C] Cc: ipsec@ietf.org Subject: Re: [IPsec] #79: Remove CP from Create_Child_SA? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 19:29:12 -0000 Yoav Nir wrote: > I disagree. > > Payloads in a particular CREATE_CHILD_SA exchange should be > specifically related to the SA being created. =A0The IKE_AUTH exchange > is different, because it is used to set up everything we need to get > an IPsec SA going. If we were designing IKEv2 from scratch, I would agree with you. But we're not, so we're not discussing what would be the best design here, but rather whether this part of RFC 4306 is so horribly broken it absolutely needs to be changed (RFC 4306 is unambiguous that CPs are allowed in CREATE_CHILD_SA exchange). I think it's not broken,=20 just somewhat ugly and inelegant... Best regards, Pasi (not wearing any hats)=20 From smoonen@us.ibm.com Thu Aug 27 13:06: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 445753A6927; Thu, 27 Aug 2009 13:06:04 -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 hTgDBAm3gcpz; Thu, 27 Aug 2009 13:06:02 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id C9A1B3A68EB; Thu, 27 Aug 2009 13:06:01 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7RK1LVt022337; Thu, 27 Aug 2009 14:01:21 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7RK5nZc038678; Thu, 27 Aug 2009 14:05:51 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7RK5lwB009295; Thu, 27 Aug 2009 14:05:47 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7RK5luL009283; Thu, 27 Aug 2009 14:05:47 -0600 In-Reply-To: <19094.16504.238846.676243@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 707CD950:EA528C5F-8525761F:0061A493; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/27/2009 04:05:32 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/27/2009 04:05:32 PM, Serialize complete at 08/27/2009 04:05:32 PM, S/MIME Sign failed at 08/27/2009 04:05:32 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08092009|August 09, 2009) at 08/27/2009 14:05:47, Serialize complete at 08/27/2009 14:05:47 Message-ID: Date: Thu, 27 Aug 2009 16:05:46 -0400 Content-Type: multipart/alternative; boundary="=_alternative 006E5EB38525761F_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 20:06:04 -0000 This is a multipart message in MIME format. --=_alternative 006E5EB38525761F_= Content-Type: text/plain; charset="US-ASCII" Tero, in short: 1) I still prefer to echo back TS payloads as I described. I realize that the TS payloads are the only opportunity that IKEv2 has to reproduce the effect of IKEv1's NAT-OA payloads. But using the traffic selectors in this way -- and only if the responder ends up agreeing to transport mode! -- still strikes me aesthetically as quite jarring, which is certainly a subjective thing but not a meaningless thing. :) As I indicated, I'm not worried about being unable to deterministically fixup the checksums because in transport mode with integrity protection, checksums aren't critical. I'm interested to hear what other implementers think. 2) I think we have a fundamental disagreement about whether it is proper for addresses in foreign networks to be configured in the SPD. Our own IKEv1 NAT-T implementation has made some (I think reasonable) design assumptions that exclude this, even in NAT-T tunnel mode. So, briefly, the MUST as you have written it is not even possible for our implementation to satisfy, because by definition our SPD cannot contain addresses from foreign networks. As you might guess, our assumptions lead to certain implications (such as the fact that we need to do various IP header address fixup and also port translation). I'm not sure it's worth boring the list with all the details. Perhaps what I can do is put together a note over the next couple of days to privately discuss our implementation with you. I'd mainly like to make sure that if there is a MUST here, it is written in such a way that implementations such as ours are not broken by definition. 3) I agree with you about my suggested replacement text, "MUST fail the SA negotiation." Because of the way that USE_TRANSPORT_MODE is negotiated, what I propose is not correct. For our own implementation, the correct behavior would be to accept the proposed SA without use of transport mode. At the moment I'm not sure how best to word this MUST to accommodate implementations that do and do not allow foreign network addresses in the SPD. Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Date: 08/27/2009 04:15 AM Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Scott C Moonen writes: > Tero, I am not comfortable with the following statement: > > . . . thus it will send back traffic selectors having IPN1 and IP2 > as their IP addresses . . . > > I would prefer that the server re-map the TS values back to IP1 and IPN2 > when sending its response. This is not possible, as the other end needs to know the address if IPN1 and IP2 (those are not known to him otherwise). Those addresses are used as original source and destination addresses for incremental checksum fixup. > This is consistent with the general > expectation that the response's TS payloads are a subset of the request's > payloads. Yes, but then we still would have problem that we do not get the original addresses from anywhere. Currently IKEv2 says they are taken from the traffic selectors, but if we do not send IPN1 and IP2 back from responder to initiator, initiator does not get them anywhere. > The client does not absolutely need this information (it would > perhaps help for deterministic checksum fixup, however in transport mode > as long as an integrity algorithm is used the checksum provides no > additional value anyway). RFC3948 do want them to do incremental checksum fixup, and one of the reasons we want to modify this text is to provide that information. > I think it is also advantageous to contain this > fixup processing to one code path (processing TS payloads in received > requests), and it also simplifies the response message processing (the > client does not need to complicate its checks to verify that the > response's TS payloads are a subset of the request's). This separation of > responsibility is more advantageous to a client implementation that needs > to be as minimal as possible. Yes, it might make it bit more simplier, but would loose functionality that is supposed to be there. The initiators processing of the responders reply is quite simple anyways, i.e. check if USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and if so store traffic selectors as original addresses, and replace them similarly as is done in other cases. Then normal processing can continue without any changes (i.e. traffic selector verification, IPsec SA installing etc). > Finally, what I propose above is how our own IKEv1 implementation works in > cases where ID payloads are sent for transport mode. :) As a responder we > found it best to bend over backwards to cater to the initiator's view of > the world. In IKEv1 there is separate payloads for sending the original addresses. In IKEv2 we do not have that, thus we must use traffic selectors for that. > I'm also concerned about the following statement: > > After this it does SPD lookup based on those new traffic > selectors. . . . > If entry is found but it does not allow transport mode, then MUST > undo the address substitution and redo the SPD lookup using the > original traffic selectors. . . . > > This statement is incoherent to me. From the fact that the initiator > proposed transport mode, it is clear that the initiator identifies TSi > with itself and TSr with the server. No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full choice of ignoring it and using tunnel mode instead. TSi and TSr do NOT identify initiator at all, initiator is already identified by the ID payloads. TSi and TSr are used to select suitable SPD entry for the given identified initiator. As for transport-mode NAT-T case the original TSi and TSr can be quite unknown for the responder, we first try with the converted addresses, but if we need to fall back to tunnel-mode NAT-T, then we want to keep original traffic selectors as now the packets exiting from the tunnel will have those addresses (i.e. packets coming from the tunnel will have IP1 and IPN2 as their source and destination addresses, as NAT in the middle does not substitute them). > The address substitution exactly > translates these addresses into the domain of the responder's SPD. If the > responder's policy indicates that transport mode is not acceptable for > this SPD entry, then I think the only possible outcome is that SA > negotiation should be failed. No other SPD entry could possibly match the > initiator's intentions. Initiator asked that if possible use transport mode with these addresses, if transport mode is not possible then use tunnel mode. Even if transport mode was not allowed, it is possible that responder do have tunnel mode rule that is allowed for that client even when transport mode was not. I do not see how you can claim that "No other SPD entry" could not be found, as initiator only gave hint that it would like to use transport mode. The use of tunnel vs transport mode is fully based on the responders policy. > However, the MUST quoted above causes the > responder to treat these addresses in an incoherent way: > > 1) The responder has detected a NAT in front of the initiator, so treating > IP1 as being within the domain of the responder's SPD isn't appropriate; > we need to use IPN1. Yes, for transport mode. For tunnel mode the IP1 is within the domain of responder's SPD as that is what responder will see in the packets coming out from the tunnel. > 2) NATs aside, the responder knows that the initiator identifies IP1 with > the initiator itself (because the initiator proposed transport mode), so > treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps > as some address behind the initiator for which it is acting as a gateway > -- isn't appropriate, because the initiator could not possibly have had > gateways in mind. I do not understand that statement at all. Other end is identified by the ID payloads, not by traffic selectors or by IP-addresses. If NATs are involved it is completely possible that responder have multiple clients connecting to it each having same IP1 (10.0.0.1) as their TSi field. Also it is possible that it has multiple clients using different IP1, but using same IPN1 as their outer address (but different ports for UDP encapsulation). RFC 3948 security considerations section has text about these different overlapping address problems. > 3) The responder has detected a NAT in front of itself, so treating IPN2 > as being within the domain of the responder's SPD isn't appropriate; we > need to use IP2. Again only for transport mode. For tunnel mode IPN2 is again ok, as that is the packet which is exiting from the tunnel. Of course if tunnel mode was used instead of transport mode then the implementation must use some method to make sure that those packets exiting from the tunnel and having destination address of IPN2 are still directly processed by the local stack. > 4) NATs aside, the responder knows that the initiator identifies IPN2 as > the responder (because the initiator proposed transport mode), so treating > IPN2 as anything other than the responder (i.e., IP2) -- as though it were > some address behind the responder for which the responder is acting as a > gateway -- isn't appropriate, because the initiator could not possibly > have had gateways in mind. > > I don't think this is an appropriate way for the responder to interpret > TSi and TSr. I propose that the MUST above be changed to "MUST fail the > SA negotiation." That would be against the 1.3.1 of the IKEv2bis or 3.10.1 of RFC4306 which says: ... If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. -- kivinen@iki.fi --=_alternative 006E5EB38525761F_= Content-Type: text/html; charset="US-ASCII"
Tero, in short:

1) I still prefer to echo back TS payloads as I described.  I realize that the TS payloads are the only opportunity that IKEv2 has to reproduce the effect of IKEv1's NAT-OA payloads.  But using the traffic selectors in this way -- and only if the responder ends up agreeing to transport mode! -- still strikes me aesthetically as quite jarring, which is certainly a subjective thing but not a meaningless thing. :)  As I indicated, I'm not worried about being unable to deterministically fixup the checksums because in transport mode with integrity protection, checksums aren't critical.  I'm interested to hear what other implementers think.

2) I think we have a fundamental disagreement about whether it is proper for addresses in foreign networks to be configured in the SPD.  Our own IKEv1 NAT-T implementation has made some (I think reasonable) design assumptions that exclude this, even in NAT-T tunnel mode.  So, briefly, the MUST as you have written it is not even possible for our implementation to satisfy, because by definition our SPD cannot contain addresses from foreign networks.  As you might guess, our assumptions lead to certain implications (such as the fact that we need to do various IP header address fixup and also port translation).  I'm not sure it's worth boring the list with all the details.  Perhaps what I can do is put together a note over the next couple of days to privately discuss our implementation with you.  I'd mainly like to make sure that if there is a MUST here, it is written in such a way that implementations such as ours are not broken by definition.

3) I agree with you about my suggested replacement text, "MUST fail the SA negotiation."  Because of the way that USE_TRANSPORT_MODE is negotiated, what I propose is not correct.  For our own implementation, the correct behavior would be to accept the proposed SA without use of transport mode.  At the moment I'm not sure how best to word this MUST to accommodate implementations that do and do not allow foreign network addresses in the SPD.

Thanks,


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


From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org
Date: 08/27/2009 04:15 AM
Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP




Scott C Moonen writes:
> Tero, I am not comfortable with the following statement:
>
>         . . . thus it will send back traffic selectors having IPN1 and IP2
> as their IP addresses . . .
>
> I would prefer that the server re-map the TS values back to IP1 and IPN2
> when sending its response.

This is not possible, as the other end needs to know the address if
IPN1 and IP2 (those are not known to him otherwise). Those addresses
are used as original source and destination addresses for incremental
checksum fixup.

> This is consistent with the general
> expectation that the response's TS payloads are a subset of the request's
> payloads.

Yes, but then we still would have problem that we do not get the
original addresses from anywhere. Currently IKEv2 says they are taken
from the traffic selectors, but if we do not send IPN1 and IP2 back
from responder to initiator, initiator does not get them anywhere.

> The client does not absolutely need this information (it would
> perhaps help for deterministic checksum fixup, however in transport mode
> as long as an integrity algorithm is used the checksum provides no
> additional value anyway).

RFC3948 do want them to do incremental checksum fixup, and one of the
reasons we want to modify this text is to provide that information.

> I think it is also advantageous to contain this
> fixup processing to one code path (processing TS payloads in received
> requests), and it also simplifies the response message processing (the
> client does not need to complicate its checks to verify that the
> response's TS payloads are a subset of the request's).  This separation of
> responsibility is more advantageous to a client implementation that needs
> to be as minimal as possible.

Yes, it might make it bit more simplier, but would loose functionality
that is supposed to be there. The initiators processing of the
responders reply is quite simple anyways, i.e. check if
USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and
if so store traffic selectors as original addresses, and replace them
similarly as is done in other cases. Then normal processing can
continue without any changes (i.e. traffic selector verification,
IPsec SA installing etc).

> Finally, what I propose above is how our own IKEv1 implementation works in
> cases where ID payloads are sent for transport mode. :)  As a responder we
> found it best to bend over backwards to cater to the initiator's view of
> the world.

In IKEv1 there is separate payloads for sending the original
addresses. In IKEv2 we do not have that, thus we must use traffic
selectors for that.

> I'm also concerned about the following statement:
>
>         After this it does SPD lookup based on those new traffic
> selectors. . . .
>         If entry is found but it does not allow transport mode, then MUST
>         undo the address substitution and redo the SPD lookup using the
>         original traffic selectors. . . .
>
> This statement is incoherent to me.  From the fact that the initiator
> proposed transport mode, it is clear that the initiator identifies TSi
> with itself and TSr with the server.

No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full
choice of ignoring it and using tunnel mode instead. TSi and TSr do
NOT identify initiator at all, initiator is already identified by the
ID payloads. TSi and TSr are used to select suitable SPD entry for the
given identified initiator.

As for transport-mode NAT-T case the original TSi and TSr can be quite
unknown for the responder, we first try with the converted addresses,
but if we need to fall back to tunnel-mode NAT-T, then we want to keep
original traffic selectors as now the packets exiting from the tunnel
will have those addresses (i.e. packets coming from the tunnel will
have IP1 and IPN2 as their source and destination addresses, as NAT in
the middle does not substitute them).

> The address substitution exactly
> translates these addresses into the domain of the responder's SPD.  If the
> responder's policy indicates that transport mode is not acceptable for
> this SPD entry, then I think the only possible outcome is that SA
> negotiation should be failed.  No other SPD entry could possibly match the
> initiator's intentions.

Initiator asked that if possible use transport mode with these
addresses, if transport mode is not possible then use tunnel mode.
Even if transport mode was not allowed, it is possible that responder
do have tunnel mode rule that is allowed for that client even when
transport mode was not.

I do not see how you can claim that "No other SPD entry" could not be
found, as initiator only gave hint that it would like to use transport
mode. The use of tunnel vs transport mode is fully based on the
responders policy.

> However, the MUST quoted above causes the
> responder to treat these addresses in an incoherent way:
>
> 1) The responder has detected a NAT in front of the initiator, so treating
> IP1 as being within the domain of the responder's SPD isn't appropriate;
> we need to use IPN1.

Yes, for transport mode. For tunnel mode the IP1 is within the domain
of responder's SPD as that is what responder will see in the packets
coming out from the tunnel.

> 2) NATs aside, the responder knows that the initiator identifies IP1 with
> the initiator itself (because the initiator proposed transport mode), so
> treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps
> as some address behind the initiator for which it is acting as a gateway
> -- isn't appropriate, because the initiator could not possibly have had
> gateways in mind.

I do not understand that statement at all. Other end is identified by
the ID payloads, not by traffic selectors or by IP-addresses. If NATs
are involved it is completely possible that responder have multiple
clients connecting to it each having same IP1 (10.0.0.1) as their TSi
field. Also it is possible that it has multiple clients using
different IP1, but using same IPN1 as their outer address (but
different ports for UDP encapsulation). RFC 3948 security
considerations section has text about these different overlapping
address problems.

> 3) The responder has detected a NAT in front of itself, so treating IPN2
> as being within the domain of the responder's SPD isn't appropriate; we
> need to use IP2.

Again only for transport mode. For tunnel mode IPN2 is again ok, as
that is the packet which is exiting from the tunnel. Of course if
tunnel mode was used instead of transport mode then the implementation
must use some method to make sure that those packets exiting from the
tunnel and having destination address of IPN2 are still directly
processed by the local stack.

> 4) NATs aside, the responder knows that the initiator identifies IPN2 as
> the responder (because the initiator proposed transport mode), so treating
> IPN2 as anything other than the responder (i.e., IP2) -- as though it were
> some address behind the responder for which the responder is acting as a
> gateway -- isn't appropriate, because the initiator could not possibly
> have had gateways in mind.
>
> I don't think this is an appropriate way for the responder to interpret
> TSi and TSr.  I propose that the MUST above be changed to "MUST fail the
> SA negotiation."

That would be against the 1.3.1 of the IKEv2bis or 3.10.1 of RFC4306
which says:

  ... If the request is accepted, the response MUST
  also include a notification of type USE_TRANSPORT_MODE.  If the
  responder declines the request, the Child SA will be established in
  tunnel mode.  
--
kivinen@iki.fi

--=_alternative 006E5EB38525761F_=-- From bhaskie@gmail.com Thu Aug 27 19:46: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 12C6C28C1EA for ; Thu, 27 Aug 2009 19:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8Uzb97RlF1g for ; Thu, 27 Aug 2009 19:46:52 -0700 (PDT) Received: from mail-px0-f202.google.com (mail-px0-f202.google.com [209.85.216.202]) by core3.amsl.com (Postfix) with ESMTP id 07E163A6B09 for ; Thu, 27 Aug 2009 19:46:51 -0700 (PDT) Received: by pxi40 with SMTP id 40so1525684pxi.5 for ; Thu, 27 Aug 2009 19:46:53 -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=qcCZR/SPKZDqOnOl1qRwmWjYgaMdNlQRVM5bmfITOcY=; b=FK6yxd/0RljnfqmiXIT64FhlttQBCsrpgSaijrxWJynsZWQzeqdMU/XuuGByKE7jya z17aOfFBaetfnChW58+xHqNIWUa2e/sDEc4o4qHH8XLvPKZs59U1rnt5Xpvcw9pf/C+k LsPuqaH8QAGK92tcsuQPYTzwoqCxJLit/a/kc= 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=Dedp+q4mJX8AEXg07FUmCmRXxJV07J/nfSK8FLOdUo75m3vuurVTcfW3RWPqC6qGEt +OQSd7a3cYXyz1m3WRbkPWJIL0DhmOrfKzHt+DL7HSMqzCFU4E7v5CJ6/REH50vlsVTL u0bAZ7ugfHZLC91arHcJMfrt42klzDLgV+GZE= MIME-Version: 1.0 Received: by 10.141.41.16 with SMTP id t16mr326667rvj.258.1251427612967; Thu, 27 Aug 2009 19:46:52 -0700 (PDT) In-Reply-To: <7ccecf670908271006y7e08c3adsea0430c4b22daada@mail.gmail.com> References: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> <19094.30853.967442.754565@fireball.kivinen.iki.fi> <571fb4000908270623l40707e0dw9dbcc946357a73ea@mail.gmail.com> <7ccecf670908271006y7e08c3adsea0430c4b22daada@mail.gmail.com> Date: Fri, 28 Aug 2009 08:16:52 +0530 Message-ID: <571fb4000908271946t3acd0a6dp8198f502792404c1@mail.gmail.com> From: Bhaskar Dutta To: Raj Singh Content-Type: text/plain; charset=ISO-8859-1 Cc: ipsec@ietf.org Subject: Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 28 Aug 2009 02:46:53 -0000 On Thu, Aug 27, 2009 at 10:36 PM, Raj Singh wrote: > Hi Bhasker, > > This document will help you: > http://www.ipsec-howto.org/ipsec-howto.pdf > It has sample configs for racoon. > > Thanks & Regards, > Raj Hi Raj, I'd already gone through this howto as well as several others. I couldn't find _anything_ that contains configuration examples for specifying multiple addresses in a single SA (which is the requirement for SCTP over IPSec RFC). As Tero pointed out, the support is there, but he doubts if any real testing has been done. Once I figure out how to specify the configuration with ipsec-tools I am planning to test it out thoroughly. Thanks, Bhaskar From kivinen@iki.fi Fri Aug 28 04: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 3BAF628C25C for ; Fri, 28 Aug 2009 04:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2cWm2SM5xLB for ; Fri, 28 Aug 2009 04:47:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D68EA28C20C for ; Fri, 28 Aug 2009 04:47:05 -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 n7SBl6B0027703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 14:47:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7SBl5cN018085; Fri, 28 Aug 2009 14:47:05 +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: <19095.50105.764201.796499@fireball.kivinen.iki.fi> Date: Fri, 28 Aug 2009 14:47:05 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 50 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:47:07 -0000 Scott C Moonen writes: > 1) I still prefer to echo back TS payloads as I described. I realize that > the TS payloads are the only opportunity that IKEv2 has to reproduce the > effect of IKEv1's NAT-OA payloads. But using the traffic selectors in > this way -- and only if the responder ends up agreeing to transport mode! > -- still strikes me aesthetically as quite jarring, which is certainly a > subjective thing but not a meaningless thing. :) As I indicated, I'm not > worried about being unable to deterministically fixup the checksums > because in transport mode with integrity protection, checksums aren't > critical. I'm interested to hear what other implementers think. The problem is that if you do not fix checksums incrementally you need to recalculate them completely, which is costly operation, especially when it happens after decryption, which means you cannot usually use the hardware on the network card. Then when you have recalculated them you need to recalculate them again to verify them. In some implementations you can skip that calculation by using special flags in implementation, but there is no generic way to do it (except for IPv4 UDP where you can set the checksum to 0). See RFC3948 section 3.1.2 for details. Using traffic selectors for the NAT-OA payloads is already in the RFC4306: 2.23. NAT Traversal ... The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [Hutt05]) are obtained from the Traffic Selectors associated with the exchange. So this is not new thing to add to IKEv2, the problem is that currently RFC4306 does not tell how to do that so it actually works. In my text I try to fix this omission and specify how it can be done without breaking existing MUSTs in RFC4306 and trying to follow other text in RFC4306. > 2) I think we have a fundamental disagreement about whether it is proper > for addresses in foreign networks to be configured in the SPD. Our own > IKEv1 NAT-T implementation has made some (I think reasonable) design > assumptions that exclude this, even in NAT-T tunnel mode. So, briefly, > the MUST as you have written it is not even possible for our > implementation to satisfy, because by definition our SPD cannot contain > addresses from foreign networks. As you might guess, our assumptions lead > to certain implications (such as the fact that we need to do various IP > header address fixup and also port translation). I'm not sure it's worth > boring the list with all the details. Perhaps what I can do is put > together a note over the next couple of days to privately discuss our > implementation with you. I'd mainly like to make sure that if there is a > MUST here, it is written in such a way that implementations such as ours > are not broken by definition. Hmm... Actually now when you point it out, I think the MUST is too strong, as there might also be implementations which do not support tunnel mode at all (host implementations are not required to support tunnel mode), thus perhaps that second policy lookup "MUST" needs to be changed to "SHOULD" or even "MAY". Would that be acceptable for you? > 3) I agree with you about my suggested replacement text, "MUST fail the SA > negotiation." Because of the way that USE_TRANSPORT_MODE is negotiated, > what I propose is not correct. For our own implementation, the correct > behavior would be to accept the proposed SA without use of transport mode. > At the moment I'm not sure how best to word this MUST to accommodate > implementations that do and do not allow foreign network addresses in the > SPD. -- kivinen@iki.fi From kivinen@iki.fi Fri Aug 28 04:51: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 7FE6028C20C for ; Fri, 28 Aug 2009 04:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRDGwLl9H+V0 for ; Fri, 28 Aug 2009 04:51:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 89A6F28C131 for ; Fri, 28 Aug 2009 04:51:40 -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 n7SBphBi013023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 14:51:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7SBphPG017841; Fri, 28 Aug 2009 14:51: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: <19095.50383.138296.103696@fireball.kivinen.iki.fi> Date: Fri, 28 Aug 2009 14:51:43 +0300 From: Tero Kivinen To: Bhaskar Dutta In-Reply-To: <571fb4000908271946t3acd0a6dp8198f502792404c1@mail.gmail.com> References: <571fb4000908270019h553878dk3e1dd84da6bd9e18@mail.gmail.com> <19094.30853.967442.754565@fireball.kivinen.iki.fi> <571fb4000908270623l40707e0dw9dbcc946357a73ea@mail.gmail.com> <7ccecf670908271006y7e08c3adsea0430c4b22daada@mail.gmail.com> <571fb4000908271946t3acd0a6dp8198f502792404c1@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: ipsec@ietf.org, Raj Singh Subject: Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 28 Aug 2009 11:51:41 -0000 Bhaskar Dutta writes: > As Tero pointed out, the support is there, but he doubts if any real > testing has been > done. Once I figure out how to specify the configuration with > ipsec-tools I am planning > to test it out thoroughly. I talked only about our own implementation (quicksec), not about any other implementation. You asked if "any implemention" supports it, so I replied to that. I have no idea whether some other implementation than our own supports SCTP. -- kivinen@iki.fi From smoonen@us.ibm.com Fri Aug 28 12:53: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 9A47B28C18B for ; Fri, 28 Aug 2009 12:53:34 -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 BVZ5iQPIJRlp for ; Fri, 28 Aug 2009 12:53:33 -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 5D2013A69BB for ; Fri, 28 Aug 2009 12:53:07 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7SJhjxI014297 for ; Fri, 28 Aug 2009 13:43:45 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7SJr4ma170676 for ; Fri, 28 Aug 2009 13:53:04 -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 n7SJr3uZ017722 for ; Fri, 28 Aug 2009 13:53:03 -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 n7SJr3OY017709; Fri, 28 Aug 2009 13:53:03 -0600 In-Reply-To: <19095.50105.764201.796499@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E13617B2@il-ex01.ad.checkpoint.com> <19093.12283.746864.474510@fireball.kivinen.iki.fi> <19094.16504.238846.676243@fireball.kivinen.iki.fi> <19095.50105.764201.796499@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: E3761EC6:122FC4F6-85257620:006BFCCB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/28/2009 03:42:18 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 08/28/2009 03:42:18 PM, Serialize complete at 08/28/2009 03:42:18 PM, S/MIME Sign failed at 08/28/2009 03:42:18 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V851_08092009|August 09, 2009) at 08/28/2009 13:53:02, Serialize complete at 08/28/2009 13:53:02 Message-ID: Date: Fri, 28 Aug 2009 15:53:02 -0400 Content-Type: multipart/alternative; boundary="=_alternative 006C3E5985257620_=" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:53:34 -0000 This is a multipart message in MIME format. --=_alternative 006C3E5985257620_= Content-Type: text/plain; charset="US-ASCII" Tero, changing the MUST to MAY is ok. If we choose SHOULD then I would prefer to present alternatives, something to the effect of "SHOULD either [do what you proposed] or accept the proposal with the use of tunnel mode, as appropriate." Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: "ipsec@ietf.org" Date: 08/28/2009 07:47 AM Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Scott C Moonen writes: > 1) I still prefer to echo back TS payloads as I described. I realize that > the TS payloads are the only opportunity that IKEv2 has to reproduce the > effect of IKEv1's NAT-OA payloads. But using the traffic selectors in > this way -- and only if the responder ends up agreeing to transport mode! > -- still strikes me aesthetically as quite jarring, which is certainly a > subjective thing but not a meaningless thing. :) As I indicated, I'm not > worried about being unable to deterministically fixup the checksums > because in transport mode with integrity protection, checksums aren't > critical. I'm interested to hear what other implementers think. The problem is that if you do not fix checksums incrementally you need to recalculate them completely, which is costly operation, especially when it happens after decryption, which means you cannot usually use the hardware on the network card. Then when you have recalculated them you need to recalculate them again to verify them. In some implementations you can skip that calculation by using special flags in implementation, but there is no generic way to do it (except for IPv4 UDP where you can set the checksum to 0). See RFC3948 section 3.1.2 for details. Using traffic selectors for the NAT-OA payloads is already in the RFC4306: 2.23. NAT Traversal ... The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [Hutt05]) are obtained from the Traffic Selectors associated with the exchange. So this is not new thing to add to IKEv2, the problem is that currently RFC4306 does not tell how to do that so it actually works. In my text I try to fix this omission and specify how it can be done without breaking existing MUSTs in RFC4306 and trying to follow other text in RFC4306. > 2) I think we have a fundamental disagreement about whether it is proper > for addresses in foreign networks to be configured in the SPD. Our own > IKEv1 NAT-T implementation has made some (I think reasonable) design > assumptions that exclude this, even in NAT-T tunnel mode. So, briefly, > the MUST as you have written it is not even possible for our > implementation to satisfy, because by definition our SPD cannot contain > addresses from foreign networks. As you might guess, our assumptions lead > to certain implications (such as the fact that we need to do various IP > header address fixup and also port translation). I'm not sure it's worth > boring the list with all the details. Perhaps what I can do is put > together a note over the next couple of days to privately discuss our > implementation with you. I'd mainly like to make sure that if there is a > MUST here, it is written in such a way that implementations such as ours > are not broken by definition. Hmm... Actually now when you point it out, I think the MUST is too strong, as there might also be implementations which do not support tunnel mode at all (host implementations are not required to support tunnel mode), thus perhaps that second policy lookup "MUST" needs to be changed to "SHOULD" or even "MAY". Would that be acceptable for you? > 3) I agree with you about my suggested replacement text, "MUST fail the SA > negotiation." Because of the way that USE_TRANSPORT_MODE is negotiated, > what I propose is not correct. For our own implementation, the correct > behavior would be to accept the proposed SA without use of transport mode. > At the moment I'm not sure how best to word this MUST to accommodate > implementations that do and do not allow foreign network addresses in the > SPD. -- kivinen@iki.fi --=_alternative 006C3E5985257620_= Content-Type: text/html; charset="US-ASCII"
Tero, changing the MUST to MAY is ok.  If we choose SHOULD then I would prefer to present alternatives, something to the effect of "SHOULD either [do what you proposed] or accept the proposal with the use of tunnel mode, as appropriate."


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


From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 08/28/2009 07:47 AM
Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP




Scott C Moonen writes:
> 1) I still prefer to echo back TS payloads as I described.  I realize that
> the TS payloads are the only opportunity that IKEv2 has to reproduce the
> effect of IKEv1's NAT-OA payloads.  But using the traffic selectors in
> this way -- and only if the responder ends up agreeing to transport mode!
> -- still strikes me aesthetically as quite jarring, which is certainly a
> subjective thing but not a meaningless thing. :)  As I indicated, I'm not
> worried about being unable to deterministically fixup the checksums
> because in transport mode with integrity protection, checksums aren't
> critical.  I'm interested to hear what other implementers think.

The problem is that if you do not fix checksums incrementally you need
to recalculate them completely, which is costly operation, especially
when it happens after decryption, which means you cannot usually use
the hardware on the network card. Then when you have recalculated them
you need to recalculate them again to verify them.

In some implementations you can skip that calculation by using special
flags in implementation, but there is no generic way to do it (except
for IPv4 UDP where you can set the checksum to 0). See RFC3948 section
3.1.2 for details.

Using traffic selectors for the NAT-OA payloads is already in the
RFC4306:

2.23.  NAT Traversal
...
     The original source and destination IP address required for the
     transport mode TCP and UDP packet checksum fixup (see [Hutt05])
     are obtained from the Traffic Selectors associated with the
     exchange.  

So this is not new thing to add to IKEv2, the problem is that
currently RFC4306 does not tell how to do that so it actually works.

In my text I try to fix this omission and specify how it can be done
without breaking existing MUSTs in RFC4306 and trying to follow other
text in RFC4306.

> 2) I think we have a fundamental disagreement about whether it is proper
> for addresses in foreign networks to be configured in the SPD.  Our own
> IKEv1 NAT-T implementation has made some (I think reasonable) design
> assumptions that exclude this, even in NAT-T tunnel mode.  So, briefly,
> the MUST as you have written it is not even possible for our
> implementation to satisfy, because by definition our SPD cannot contain
> addresses from foreign networks.  As you might guess, our assumptions lead
> to certain implications (such as the fact that we need to do various IP
> header address fixup and also port translation).  I'm not sure it's worth
> boring the list with all the details.  Perhaps what I can do is put
> together a note over the next couple of days to privately discuss our
> implementation with you.  I'd mainly like to make sure that if there is a
> MUST here, it is written in such a way that implementations such as ours
> are not broken by definition.

Hmm... Actually now when you point it out, I think the MUST is too
strong, as there might also be implementations which do not support
tunnel mode at all (host implementations are not required to support
tunnel mode), thus perhaps that second policy lookup "MUST" needs to
be changed to "SHOULD" or even "MAY".

Would that be acceptable for you?

> 3) I agree with you about my suggested replacement text, "MUST fail the SA
> negotiation."  Because of the way that USE_TRANSPORT_MODE is negotiated,
> what I propose is not correct.  For our own implementation, the correct
> behavior would be to accept the proposed SA without use of transport mode.
>  At the moment I'm not sure how best to word this MUST to accommodate
> implementations that do and do not allow foreign network addresses in the
> SPD.
--
kivinen@iki.fi

--=_alternative 006C3E5985257620_=-- From wwwrun@core3.amsl.com Mon Aug 31 07:09:35 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4752B3A6E46; Mon, 31 Aug 2009 07:09:35 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090831140935.4752B3A6E46@core3.amsl.com> Date: Mon, 31 Aug 2009 07:09:35 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 14:09:35 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Session Resumption ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17990&rfc_flag=0 From ynir@checkpoint.com Mon Aug 31 23:43: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 04D1128C402 for ; Mon, 31 Aug 2009 23:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.655, 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 6Gmh8xjZjAod for ; Mon, 31 Aug 2009 23:43:21 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 7F59528C3DA for ; Mon, 31 Aug 2009 23:43:19 -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 n816hT3d021769 for ; Tue, 1 Sep 2009 09:43:29 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 1 Sep 2009 09:43:26 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Tue, 1 Sep 2009 09:43:26 +0300 Thread-Topic: Issue #26: Missing treatment of error cases Thread-Index: Acoqz4ISrr6R5PQFS5qBkBEpL/nuHQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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: Tue, 01 Sep 2009 06:43:22 -0000 Hello all. Issue #26 was submitted by Tero Kivinen. It concerns section 2.21 =20 ("error handling") and states that several things are missing: - handling of errors before authentication - listing what error conditions cause the IKE SA to be deleted entirely - listing how errors are handled in the piggybacked exchanges. Following is our suggested new text. Please let us know what you =20 think. Also, please take a look at the description of =20 "AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH =20 message" means either an IKE_AUTH response to an IKE_AUTH request, or =20 an INFORMATIONAL request that describes an error in the IKE_AUTH =20 response. Do you think this phrasing is clear enough? 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted, or unacceptable =20 for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs in the processing of a response, then the initiator SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. If an error occurs outside the context of =20 an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. Errors that occur before a cryptographically protected IKE SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service =20 attack based on forged messages. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and not a request to start one), =20 it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that =20 the recipient has rebooted and forgotten the existence of an IKE SA. A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message =20 might be a forgery or might be a response, the genuine correspondent was tricked into sending. A node should treat such a message (and =20 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 check 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 (and port, if NAT traversal is used) with which it has an IKE SA MAY send an =20 IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. 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. All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, unrecognized ID, untrusted certificate issuer, revoked or expired certificate, etc.) MUST result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification MUST be returned in the protected response, and MUST be the only payload in that response. If the error occurs on the initiator, the notification MUST be returned in a separate INFORMATIONAL exchange, with no other payloads. Note, however, that messages that contain an unsupported critical payload, or that are otherwise malformed, MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The receiver MUST NOT verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, provided that there are no unsupported critical payloads. Establishing the child SA, or requesting configuration information may still fail, but they do not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete =20 such an IKE SA. Only authentication failures and malformed packets lead to a =20 deletion of the IKE SA without requiring an explicit DELETE payload. Other error conditions require such a payload. In an IKE_SA_INIT =20 exchange, any error notification causes the exchange to fail. In an IKE_AUTH exchange, or in the subsequent INFORMATIONAL exchnage, only the following notifications cause the IKE SA to be deleted or not created, without a DELETE payload: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer is known to understand them.