From mobike-bounces@machshav.com Fri Dec 02 18:50:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKfM-0000Xq-8X for mobike-archive@megatron.ietf.org; Fri, 02 Dec 2005 18:50:13 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15046 for ; Fri, 2 Dec 2005 18:49:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 89316FB2A3; Fri, 2 Dec 2005 18:50:09 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 76FCDFB2A0; Fri, 2 Dec 2005 18:50:08 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 75971FB2A1; Fri, 2 Dec 2005 18:50:06 -0500 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id ADEC0FB29B for ; Fri, 2 Dec 2005 18:50:05 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EiKfB-0002dH-R2; Fri, 02 Dec 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Dec 2005 18:50:01 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-05.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : Design of the MOBIKE Protocol Author(s) : T. Kivinen, H. Tschofenig Filename : draft-ietf-mobike-design-05.txt Pages : 37 Date : 2005-12-2 The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing extensions for the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-design-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-design-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-2155259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-2155259.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Mon Dec 05 09:36:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjHRu-0002TK-Ng for mobike-archive@megatron.ietf.org; Mon, 05 Dec 2005 09:36:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25772 for ; Mon, 5 Dec 2005 09:35:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 33C2AFB2A0; Mon, 5 Dec 2005 09:36:08 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5925BFB297; Mon, 5 Dec 2005 09:36:06 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EC429FB29B; Mon, 5 Dec 2005 09:36:03 -0500 (EST) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by machshav.com (Postfix) with ESMTP id D08C3FB291 for ; Mon, 5 Dec 2005 09:36:02 -0500 (EST) Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AE29011A for ; Mon, 5 Dec 2005 15:35:58 +0100 (MET) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 27326-02 for ; Mon, 5 Dec 2005 15:35:56 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id A39D2149 for ; Mon, 5 Dec 2005 15:35:55 +0100 (NFT) Message-ID: <4394504B.4070606@uni-tuebingen.de> Date: Mon, 05 Dec 2005 15:35:55 +0100 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Subject: [Mobike] MOBIKE Implementation X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1605192367==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is a cryptographically signed message in MIME format. --===============1605192367== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020905000907030103030407" This is a cryptographically signed message in MIME format. --------------ms020905000907030103030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, we are planning to start with a MOBIKE implementation at our university. So, I'm wondering if there is any hint that could help us or any open source implementation that already exist?! I haven't even found any information in the archive of the mailing list about any MOBIKE interop workshop that took place. Any information would be helpful. Thanks, ali -- Ali Fessi University of Tuebingen, Germany --------------ms020905000907030103030407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGOTCC AvIwggJboAMCAQICAw37QTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjA3MTQxOTE3WhcNMDYwMjA3MTQxOTE3 WjBdMQ4wDAYDVQQEEwVGZXNzaTEMMAoGA1UEKhMDQWxpMRIwEAYDVQQDEwlBbGkgRmVzc2kx KTAnBgkqhkiG9w0BCQEWGmFsaS5mZXNzaUB1bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2SH7H2KK6H3jYVitFjxylVOsL/TRXXnwlqTjUQmPU1yl 0sK3nv5xWD2lHqL/5v+n2YjYqi2kdG6ORyks51/QKVOB0NYCEVlQFWdT5DNNw6RvjGQd715K XXO4b7XRQJFcZc1Qc8L2G/fER9fvWHfCX09KhFqrJRQ2mahZ+sWcoXZlV9k5M1/jPTECR9dC iVdtI4SYdye9Aryu/P5S6mT0XgZ4JDb41qYTlUyYQpqp77VOFG4odh0vrINac0KdlHrhCjDJ PQ1c23a8/s7VbdG44GsGw5SoFJiDXjQrLhsxh62c88qhNiqMtRPvsnxgqUvv0YKEvYCS5O0e nFiUakz/kwIDAQABozcwNTAlBgNVHREEHjAcgRphbGkuZmVzc2lAdW5pLXR1ZWJpbmdlbi5k ZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAAm748hVdHcNCjCezGHTtFHr7n/K /EnCMrAABvW3oGjM8C9xuzULk7TUubotA1GROGFIcQfDIOqDGirope4asWdEiG9NARtlJkpc JTXv0v1Dl6vEZhXLGF7efTUCI6/mANlQ3sLc22vqceYU/kDSYUijRCz68F0gyiWJ9Z/wR7ic MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIz NTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50 aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkG A1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAkQwggJAAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMN+0EwCQYFKw4DAhoFAKCBsTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEyMDUxNDM1NTVaMCMG CSqGSIb3DQEJBDEWBBQgLCXxbMWYsMHmRe1BWT+ZKd0UtDBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCQKM3BZBFQ6xldRW/yP9oixajldGUzCdWY XqQY8G0MUmJl1wydbgSpxkQsiwYKfHxoGMRgxBEo22uEjjziTb37UoFPJWabPhsWAdLVX54J wUFRRTQSye13+kAlPnehvkFCGEk3RF0kOJ3uPOT16AXuoujvh018+QsfCz8tJ1ua/aP029dY WWLe14/Qbwd0aXRCTe6ETd88UnY1VopRpo+bSGQdIQ918hheWqPZ7QYPtQpIIq1cKEfhEM5G JFbNIc/YQEsKuN8H4xGq5RNERa0Z3em8JgNFuHVpty51ww5C6EBiwjcGkceSnQQfwWN9EvTW f1FoJadWVvUCxA2n67x3AAAAAAAA --------------ms020905000907030103030407-- --===============1605192367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============1605192367==-- From mobike-bounces@machshav.com Fri Dec 09 06:10:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekg9N-00089E-TB for mobike-archive@megatron.ietf.org; Fri, 09 Dec 2005 06:10:56 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18366 for ; Fri, 9 Dec 2005 06:09:51 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5AB0CFB29B; Fri, 9 Dec 2005 06:10:35 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 63D73FB297; Fri, 9 Dec 2005 06:10:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CAD61FB298; Fri, 9 Dec 2005 06:10:31 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3D960FB280 for ; Fri, 9 Dec 2005 06:10:31 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 306A88980C; Fri, 9 Dec 2005 13:10:29 +0200 (EET) Message-ID: <4399660A.5040106@piuha.net> Date: Fri, 09 Dec 2005 13:10:02 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Cc: Paul Hoffman Subject: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit We are now starting the Working Group Last Call on the design document. Here is the URL: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-05.txt The WGLC will end on December 24th, 2005. Please review this document and post your review results to the list (even if you found no complaints). If you have multiple issues, it would help the subsequent discussion if you broke them up in parts that are sent in separate e-mails and with appropriate subject lines (e.g., "section N problem" or "editorial issues"). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 14 08:42:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWtx-0008Sd-0L for mobike-archive@megatron.ietf.org; Wed, 14 Dec 2005 08:42:37 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25497 for ; Wed, 14 Dec 2005 08:41:28 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CEF9EFB291; Wed, 14 Dec 2005 08:42:21 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4ED10FB28B; Wed, 14 Dec 2005 08:42:20 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EAA9EFB28F; Wed, 14 Dec 2005 08:42:17 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E2526FB28B for ; Wed, 14 Dec 2005 08:42:16 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBEDgCDB004051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2005 15:42:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBEDgCTP020044; Wed, 14 Dec 2005 15:42:12 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17312.8500.50593.592318@fireball.acr.fi> Date: Wed, 14 Dec 2005 15:42:12 +0200 From: Tero Kivinen To: MOBIKE Mailing List In-Reply-To: <4399660A.5040106@piuha.net> References: <4399660A.5040106@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Subject: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > We are now starting the Working Group Last Call on > the design document. Here is the URL: > > http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-05.txt > > The WGLC will end on December 24th, 2005. Please review > this document and post your review results to the list (even if > you found no complaints). If you have multiple issues, it would As I haven't received any comments yet (not even ones saying "no complaints"), I would like to remind people to read this document... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 20 15:50:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooRC-0006zT-BH for mobike-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:50:22 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04421 for ; Tue, 20 Dec 2005 15:49:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E7D7BFB294; Tue, 20 Dec 2005 15:50:06 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 94B5EFB286; Tue, 20 Dec 2005 15:50:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B3B2CFB28D; Tue, 20 Dec 2005 15:50:03 -0500 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id E6ADEFB284 for ; Tue, 20 Dec 2005 15:50:02 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQs-0008TE-8e; Tue, 20 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Dec 2005 15:50:02 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-07.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : IKEv2 Mobility and Multihoming Protocol (MOBIKE) Author(s) : P. Eronen Filename : draft-ietf-mobike-protocol-07.txt Pages : 37 Date : 2005-12-20 This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile VPN client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-protocol-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-protocol-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-20134712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20134712.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Tue Dec 20 17:48:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoqHg-00006F-An for mobike-archive@megatron.ietf.org; Tue, 20 Dec 2005 17:48:40 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10959 for ; Tue, 20 Dec 2005 17:47:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AA695FB299; Tue, 20 Dec 2005 17:48:38 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A13A8FB294; Tue, 20 Dec 2005 17:48:35 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DB894FB297; Tue, 20 Dec 2005 17:48:33 -0500 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 66E4FFB293 for ; Tue, 20 Dec 2005 17:48:33 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EoqHZ-0001kK-08; Tue, 20 Dec 2005 17:48:33 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 20 Dec 2005 17:48:33 -0500 Cc: mobike@machshav.com Subject: [Mobike] Last Call: 'IKEv2 Mobility and Multihoming Protocol (MOBIKE)' to Proposed Standard X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit The IESG has received a request from the IKEv2 Mobility and Multihoming WG to consider the following document: - 'IKEv2 Mobility and Multihoming Protocol (MOBIKE) ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-07.txt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:50:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1YI-0005mq-Ku for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:50:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22999 for ; Wed, 21 Dec 2005 05:49:28 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 54CE5FB293; Wed, 21 Dec 2005 05:50:32 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25FA7FB281; Wed, 21 Dec 2005 05:50:27 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 407BCFB282; Wed, 21 Dec 2005 05:50:25 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 11B9EFB27F for ; Wed, 21 Dec 2005 05:50:23 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A04DB898BF for ; Wed, 21 Dec 2005 12:50:20 +0200 (EET) Message-ID: <43A93351.7090105@piuha.net> Date: Wed, 21 Dec 2005 12:49:53 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: editorial X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I have reviewed the design draft -05 revision. This and the following e-mails raise some issues that I have found. My overall conclusion is that the document is in good shape, but needs some additional editing and better alignment with terminology and other aspects of the protocol draft. This is why we are having the WGLC, but reviews by WG members are essential to get there! So please read the document now and comment. Abstract: ====== > The MOBIKE (IKEv2 Mobility and Multihoming) working group is > developing extensions for the Internet Key Exchange Protocol version > 2 (IKEv2). For someone that reads this later the references to WG may not make a lot of sense. Rewrite as "MOBIKE (...) is an extension of the ...". Section 1: ========== > However, this can be problematic, as the device > might be too slow for this task. Maybe "However, this is a relatively expensive operation, and can be problematic when such changes are frequent." > The work of the MOBIKE working group and therefore this document is > based on the assumption that the mobility and multi-homing extensions > are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on Another unnecessary reference to the WG. Just say "The MOBIKE protocol is assumed to work on top of ..." or something to that effect. > This document neither discusses mobility and multi- > homing support for IKEv1 [RFC2409] nor the IPsec architecture > described in RFC2401 [RFC2401]. There seems to be something wrong with "neither" here. Say "This document does not discuss ..." Section 2: ========== > Peer: I think the colon is unnecessary here. > local-addr]. That is, it is not an IPv6 link-local. ... address. > This definition is taken from [I-D.arkko-multi6dt-failure- > detection], and adapted to the MOBIKE context (we do allow > [RFC1918] addresses here, they are very common addresses used > inside NATs). Just add a plain reference, not explain the differences, since the differences keep changing as the SHIM6 work proceeds. Also, the reference is I-D.ietf-shim6-failure-detection. Similar for the other definitions. Section 3: ========== > Even if IP addresses change due to interface switching or mobility, > the IP address obtained via the configuration payloads within IKEv2 > remain unaffected. The IP address obtained via the IKEv2 > configuration payloads allow the configuration of the inner IP > address of the IPsec tunnel. As such, applications might not detect > any change at all. This text in Section 3.3 seems to apply to all scenarios. Say "In all of these scenarios, even if ..." Section 4: ========== > This > current design document focuses mainly on tunnel mode, everything > going inside the tunnel is unaffected by the changes in the tunnel > header IP address, and this is the mobility feature provided by the > MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec > tunnel might not detect the movement since their IP addresses remain > constant. s/This current/The/ "mainly"? And there's some duplication with end of Section 3. Suggest: merge the paragraphs and place them in Section 4. > MOBIKE interacts with the IPsec engine using for > example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon > can create entries in the Security Association (SAD) and Security > Policy Databases (SPD). Maybe say "... using an internal API (such as those based on PF_KEY [RFC2367]). Using such an API..." > Extensions of the PF_KEY interface required by MOBIKE are also within > the scope of the working group. Finally, certain optimizations for > wireless environments are also covered. Don't talk about the other work items in the WG. Delete this paragraph. Section 5: ========== > Choosing addresses for > the IKEv2 request is a somewhat separate problem: in many cases, they > will be the same (and in some design choice they will always be the > same). ... will be the same, and could be forced to be the same by design. > MOBIKE > does not support unidirectional address pairs (i.e. where you can > only send traffic in one direction when using single address pair). No need to redefine the term here. Just end after the word "pairs". > Note that MOBIKE is not really concerned about the actual path used, > it cannot even detect if some path is unidirectionally operational if > the same address pair has some other unidirectional path back. s/really// > To detect connectivity, i.e., failures along the path, the MOBIKE > protocol needs to have a mechanism to test connectivity. If a MOBIKE s/, i.e., failures along the path// > problem worse by sending lots of DPD packets. s/lots/many/ > One of the main decisions in designing the MOBIKE protocol is who s/decisions/questions/ s/is/was/ > As a consequence the outcome cannot > be asymmetric decisions. ... the outcome is always the same for both parties. > The NAT-T support should also be optional, i.e., if the IKEv2 > implementation does not implement NAT-T, as it is not required in > some particular environment, implementing MOBIKE should not require > adding support for NAT-T as well. s/as well/either/ > There are some cases which cannot be carried out within the > restrictions of the MOBIKE charter. To avoid talking about the charter, just say "... within MOBIKE". > On the other hand, as all implementations supporting NAT-T must be > able to respond to port 4500 all the time, it is simpler from the > protocol point of view to change the port numbers from 500 to 4500 > immediately when we detect that the other end supports NAT-T. This > way we do not need to start changing ports after we later detected > NAT, which would have caused complications to the protocol. s/when we detect/upon detecting/ s/we do not need to start changing/it is not necessary to change/ (Its better style to not use "we", I think. Go through the rest of the document, too, there are multiple occurrences. Such as in the next paragraph.) > The working group decided that MOBIKE uses NAT-T mechanisms from the > IKEv2 protocol as much as possible, but decided to change the dynamic > address update for IKEv2 packets to MUST NOT (it would break path > testing using IKEv2 packets, see Section 6.2). The working group > also decided to only send keepalives to the current address pair. Dynamic address update for IPsec packets? I'm unsure what you mean here. In any case, pointing to the actual requirement in IKEv2 spec would be useful here. > From a technical point of view this feature addresses two issues: > > o There is no need to transmit IPsec data traffic. IPsec protected > data can be dropped which saves bandwidth. This does not provide > a functional benefit, i.e., nothing breaks if this feature is not > provided. > > o MOBIKE signaling messages are also ignored. The IKE-SA must not > be deleted and the suspend functionality (realized with the zero > address set) may require the IKE-SA to be tagged with a lifetime > value since the IKE-SA should not be kept alive for an undefined > period of time. Note that IKEv2 does not require that the IKE-SA > has a lifetime associated with it. In order to prevent the IKE-SA > from being deleted the dead-peer detection mechanism needs to be > suspended as well. ... this feature raises two issues? > Due to the fact that this extension could be complicated and there > was no clear need for it, a first version of the MOBIKE protocol will > not provide this feature. Due to its complexity and no clear requirement for it, it was decided that MOBIKE does not support this feature. > What happens there is that the initiator does the normal address > update, and that succeeds, and then the responder starts a return > routability check. s/does/performs/ > the same as the return routability check in MIP6: The MIP6 WG decided is different from Mobile IPv6 [RFC 3775], which does not perform return routability operations between the mobile node and its home agent at all. > Working group decided to use a protocol format where both ends send a > full list of their addresses to the other end, and that list > overwrites the previous list. To support NAT-T the IP-addresses of > the received packet is added to the list (and they are not present in > the list). ...are considered as one address of the peer, even if not present in the list. Other: ===== > be routed along a different path, for example by load balancers. s/by load balancers/due to load balancing/ (My speller didn't think "balancer" is a word.) > the correct IP addresses before the initiator can belive it is alive s/belive/believe/ > redirections by an authenticated attacker. Return routability checks s/redirections/redirection/ --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:50:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1YT-00060u-H8 for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:50:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23068 for ; Wed, 21 Dec 2005 05:49:40 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 410F9FB29F; Wed, 21 Dec 2005 05:50:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 776A4FB284; Wed, 21 Dec 2005 05:50:42 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AC669FB299; Wed, 21 Dec 2005 05:50:39 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 54536FB286 for ; Wed, 21 Dec 2005 05:50:30 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A27AB898BF for ; Wed, 21 Dec 2005 12:50:29 +0200 (EET) Message-ID: <43A9335A.2020906@piuha.net> Date: Wed, 21 Dec 2005 12:50:02 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: existing documents claim X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > IKEv2 assumes that an IKE SA is created implicitly between the IP > address pair that is used during the protocol execution when > establishing the IKEv2 SA. This means that, in each host, only one > IP address pair is stored for the IKEv2 SA as part of a single IKEv2 > protocol session, and, for tunnel mode SAs, the hosts places this > single pair in the outer IP headers. Existing documents make no > provision to change this pair after an IKE SA is created. But doesn't NAT-T allow a limited form of changes? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:51:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1Z2-0006Hm-4H for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:51:20 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23094 for ; Wed, 21 Dec 2005 05:50:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9A40DFB29D; Wed, 21 Dec 2005 05:51:18 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E5A46FB282; Wed, 21 Dec 2005 05:51:13 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 16EBBFB286; Wed, 21 Dec 2005 05:51:12 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 993D5FB23C for ; Wed, 21 Dec 2005 05:51:10 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ADD75898BF for ; Wed, 21 Dec 2005 12:51:09 +0200 (EET) Message-ID: <43A93382.2060600@piuha.net> Date: Wed, 21 Dec 2005 12:50:42 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > Primary Path: > > The sequence of routers traversed by an IP packet that carries the > default source and destination addresses is said to be the Primary > Path. This definition is taken from [RFC2960] and adapted to the > MOBIKE context. The protocol draft uses the term "current path" (and so does the latest version of the SHIM6 draft where the primary path term was originally taken from). Use the term "current path" instead here in Section 2 as well as in the rest of the document. > Preferred Address: > > The IP address of a peer to which MOBIKE and IPsec traffic should > be sent by default. A given peer has only one active preferred > address at a given point in time, except for the small time period > where it switches from an old to a new preferred address. This > definition is taken from [I-D.ietf-hip-mm] and adapted to the > MOBIKE context. The protocol draft does not use this term. Peer address set is closer to what we want here? (Also, I'm not sure the protocol we have actually communicates the address preferences. The initiator makes a decision, but does the ordering in an address update indicate preference?) Also, > The MOBIKE protocol should be able to perform the following > operations: > > o Inform the other peer about the peer address set > > o Inform the other peer about the preferred address > > o Test connectivity along a path and thereby to detect an outage > situation > > o Change the preferred address Again, not sure we actually communicate the preferred information -- but I may be missing something. > Another MOBIKE usage scenario is depicted in Figure 2. In this > scenario, the MOBIKE peers are equipped with multiple interfaces (and > multiple IP addresses). Peer A has two interface cards with two IP > addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 > and IP_B2. Each peer selects one of its IP addresses as the > preferred address which is used for subsequent communication. > Various reasons (e.g., hardware or network link failures), may > require a peer to switch from one interface to another. Is this in line with what the protocol draft does? > Operational address pair: > > A pair of operational addresses are said to be an operational > address pair, if and only if bidirectional connectivity can be > shown between the two addresses. Note that sometimes it is > necessary to consider connectivity on a per-flow level between two > endpoints. This differentiation might be necessary to address > certain Network Address Translation types or specific firewalls. > This definition is taken from [I-D.arkko-multi6dt-failure- > detection] and adapted for the MOBIKE context. Although it is > possible to further differentiate unidirectional and bidirectional > operational address pairs, only bidirectional connectivity is > relevant to this document and unidirectional connectivity is out > of scope. (snip) > Bidirectional Address Pair:: > > The address pair, where traffic can be sent to the both > directions, simply by reversing the IP addresses. Note, that the > path of the packets going to each direction might be different. > > Unidirectional Address Pair:: > > The address pair, where traffic can only be sent in one direction, > and reversing the IP addresses and sending reply back does not > work. The explanation of directionality on the first definition seems superfluous. > Figure 1 shows a break-before-make mobility scenario where a mobile > node changes its point of network attachment. Prior to the change, > the mobile node had established an IPsec connection with a security > gateway which offered, for example, access to a corporate network. > The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took > place over the path labeled as 'old path'. The involved packets > carried the MN's "old" IP address and were forwarded by the "old" > access router (OAR) to the security gateway (GW). Consider talking only about routers, not access routers. > MOBIKE interacts with the IPsec engine using for > example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon > can create entries in the Security Association (SAD) and Security > Policy Databases (SPD). The IPsec engine may also interact with > IKEv2 and MOBIKE daemon using this API. "IPsec engine" is a term that exists in RFC2401, I think. Use "IPsec implementation" or some other term. > In order to address certain failure > cases, MOBIKE should perform connectivity tests between the peers > (potentially over a number of different paths). I think they are called "path tests" in the protocol draft. > Those external hole punching mechanisms are beyond the scope of Firewall pinhole opening is a better term, I think. > One type of attack that needs to be taken care of in the MOBIKE > protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec] > and [Aur02] for more information about flooding attacks. Called bombing attack earlier, and in the protocol draft. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:51:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1Zd-0006fl-Bo for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:51:57 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23178 for ; Wed, 21 Dec 2005 05:50:51 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F3944FB299; Wed, 21 Dec 2005 05:51:56 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7373CFB282; Wed, 21 Dec 2005 05:51:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5974CFB286; Wed, 21 Dec 2005 05:51:52 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CE228FB23C for ; Wed, 21 Dec 2005 05:51:51 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2023D898BF for ; Wed, 21 Dec 2005 12:51:51 +0200 (EET) Message-ID: <43A933AB.8060704@piuha.net> Date: Wed, 21 Dec 2005 12:51:23 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: definition of load balancing X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > Note that MOBIKE does not aim to support load balancing between > multiple IP addresses. That is, each peer uses only one of the > available IP addresses at a given point in time. This may not be exact enough. I suppose we mean "... only one of the available address pairs at a given point in time". --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:52:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1Zz-00073f-Qy for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:52:19 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23247 for ; Wed, 21 Dec 2005 05:51:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 96AD8FB29B; Wed, 21 Dec 2005 05:52:18 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9F99EFB282; Wed, 21 Dec 2005 05:52:16 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 450A5FB286; Wed, 21 Dec 2005 05:52:15 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 4E55FFB23C for ; Wed, 21 Dec 2005 05:52:14 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 73810898BF for ; Wed, 21 Dec 2005 12:52:13 +0200 (EET) Message-ID: <43A933C2.1000305@piuha.net> Date: Wed, 21 Dec 2005 12:51:46 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: figure 3 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > +-------------+ +---------+ > |User-space | | MOBIKE | > |Protocols | +-->>| Daemon | > |relevant for | | | | > |MOBIKE | | +---------+ > +-------------+ | ^ > User Space ^ | ^ > ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ > Kernel Space v | v > _______ | v > +-------------+ / \ | +--------------+ > |Routing | / Trigger \ | | IPsec | > |Protocols |<<-->>| Database |<<-+ +>+ Engine | > | | \ / | | (+Databases) | > +-----+---+---+ \_______/ | +------+-------+ > ^ ^ ^ | ^ > | +---------------+-------------+--------+-----+ > | v | | | > | +-------------+ | | | > I | |Kernel-space | | | | I > n | +-------->+Protocols +<----+-----+ | | n > t v v |relevant for | | v v v t > e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e > r | Input | +-------------+ | | Outgoing | r > f | Packet +<--------------------------+ | Interface | f > ==a>|Processing|===============================| Processing |=a> > c | | | | c > e +----------+ +------------+ e > s s > ===> = IP packets arriving/leaving a MOBIKE node > <-> = control and configuration operations > > Figure 3: Framework I am confused by the role of the "Kernel-space protocols relevant for MOBIKE" box in this figure. There are parts of a node implementation that have to deal with IPsec processing; is this what you mean? And there are parts of a node implementation that may provide information to, e.g., MOBIKE and MOBILE IP -- such as IPv6 NUD or DNA. Is this what you mean? I think the latter is an important part that should be shown, but such components would appear to provide input to the MOBIKE daemon directly or via a "trigger database" rather than effect input and output processing directly. What are "User-space Protocols Relevant for MOBIKE"? I can't think of any... Also, I'd rather not see "routing protocols" in this figure, as it will confuse people. And while a trigger database is a good idea, I'd rather not introduce it here. It would be better to have a simplified ascii version of the slide from IETF-62: http://www3.ietf.org/proceedings/05mar/slides/mobike-1/sld6.htm --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:52:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1aQ-0007H7-2j for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:52:46 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23268 for ; Wed, 21 Dec 2005 05:51:40 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E5532FB2A0; Wed, 21 Dec 2005 05:52:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0F66EFB2A3; Wed, 21 Dec 2005 05:52:29 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C263CFB2AB; Wed, 21 Dec 2005 05:52:26 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8CA91FB2A8 for ; Wed, 21 Dec 2005 05:52:24 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E2F23898BF for ; Wed, 21 Dec 2005 12:52:23 +0200 (EET) Message-ID: <43A933CC.30605@piuha.net> Date: Wed, 21 Dec 2005 12:51:56 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: nat-p X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > This gives extra > protection against 3rd party bombing attacks (the attacker cannot > divert the traffic to some 3rd party). This seems inaccurate, or at least too strong. We have other mechanisms to prevent that, and the NAT-T based attack only works for on-path attackers. Just say "This avoids any possibility of on-path attackers modifying addresses in headers" and refer to Francis's pseudonat attack draft. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:53:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1bS-0007vl-PZ for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:53:50 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23352 for ; Wed, 21 Dec 2005 05:52:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C8DF0FB29E; Wed, 21 Dec 2005 05:53:48 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EF49CFB286; Wed, 21 Dec 2005 05:53:46 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BF65DFB28A; Wed, 21 Dec 2005 05:53:44 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AAAA8FB24A for ; Wed, 21 Dec 2005 05:53:43 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0F384898BF for ; Wed, 21 Dec 2005 12:53:43 +0200 (EET) Message-ID: <43A9341B.9050808@piuha.net> Date: Wed, 21 Dec 2005 12:53:15 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: section 5.5 nits X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > If the addresses are part of the certificate then it is > not necessary to execute the weaker return routability check. The > return routability check is a form of authorization check, although > it provides weaker guarantees than the inclusion of the IP address as > a part of a certificate. If multiple addresses are communicated to > the remote peer then some of these addresses may be already verified > even if the primary address is still operational. s/the weaker/the/ (the strength is explained in next sentence) Also, it seems like there is some text missing here that we had in the protocol draft about the need to have some authority involved in the certs... surely the pure inclusion of data in a self-signed certificate, for instance, does not make the data reliable. I do not understand the last sentence. I guess you are trying to say that verification can take place in parallel with ongoing use of another, current address pair? > Another option is to use the [I-D.dupont-mipv6-3bombing] approach > which suggests to perform a return routability check only when an > address update needs to be sent from some address other than the > indicated preferred address. I would delete this paragraph. There are a zillion variations of the return routability procedure, and there is no need to point to one of the variants here, particularly if that variant has not been in use in other contexts. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:54:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1bh-0008Je-UM for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:54:05 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23398 for ; Wed, 21 Dec 2005 05:53:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C0C72FB2A4; Wed, 21 Dec 2005 05:54:04 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ABB15FB28A; Wed, 21 Dec 2005 05:54:02 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 78642FB294; Wed, 21 Dec 2005 05:54:01 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id DB887FB24A for ; Wed, 21 Dec 2005 05:53:59 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0934B898BF for ; Wed, 21 Dec 2005 12:53:59 +0200 (EET) Message-ID: <43A9342B.6050207@piuha.net> Date: Wed, 21 Dec 2005 12:53:31 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: ikev2 payloads X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > Some implementations might have problems parsing more > than certain number of IKEv2 payloads, but if the sender sends them > in the most preferred first, the receiver can only use the first > addresses, it was willing to parse. Hmm... the IKEv2 spec seems to say that you MUST be able to reject Critical=1 payloads that you don't recognize. This seems to imply that you must go through all the payloads, or am I missing something? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:54:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1c9-0008Mb-1k for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:54:33 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23439 for ; Wed, 21 Dec 2005 05:53:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EBDA6FB2AC; Wed, 21 Dec 2005 05:54:30 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 66386FB298; Wed, 21 Dec 2005 05:54:29 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5D773FB2AC; Wed, 21 Dec 2005 05:54:27 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A484FFB24A for ; Wed, 21 Dec 2005 05:54:26 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 07C45898BF for ; Wed, 21 Dec 2005 12:54:25 +0200 (EET) Message-ID: <43A93446.4080907@piuha.net> Date: Wed, 21 Dec 2005 12:53:58 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: references X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > 10.1. Normative references > > [I-D.ietf-ipsec-ikev2] > Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", > draft-ietf-ipsec-ikev2-17 (work in progress), > October 2004. > > [I-D.ietf-ipsec-rfc2401bis] > Kent, S. and K. Seo, "Security Architecture for the > Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work > in progress), April 2005. It might be that the MOBIKE protocol spec is a useful reference to the reader as well... > [I-D.arkko-multi6dt-failure-detection] > Arkko, J., "Failure Detection and Locator Selection in > Multi6", draft-arkko-multi6dt-failure-detection-00 (work > in progress), October 2004. Refer to draft-ietf-shim6-failure-detection-03 instead (to appear today). > [I-D.ietf-mip6-ro-sec] > Nikander, P., "Mobile IP version 6 Route Optimization > Security Design Background", draft-ietf-mip6-ro-sec-03 > (work in progress), May 2005. This is now RFC 4225. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 05:54:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1cP-0008OO-CP for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:54:49 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23465 for ; Wed, 21 Dec 2005 05:53:43 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D4654FB2A9; Wed, 21 Dec 2005 05:54:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 84CDBFB2A2; Wed, 21 Dec 2005 05:54:45 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 87B1FFB2A3; Wed, 21 Dec 2005 05:54:43 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2E91AFB2A2 for ; Wed, 21 Dec 2005 05:54:42 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8740F898BF for ; Wed, 21 Dec 2005 12:54:41 +0200 (EET) Message-ID: <43A93455.7020507@piuha.net> Date: Wed, 21 Dec 2005 12:54:13 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Subject: [Mobike] design draft issue: security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > 7. Security Considerations This section seems weak compared to the one in the protocol draft. Consider simply referring to the protocol spec unless there is some new information (e.g. design decisions not covered in the protocol spec). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 09:38:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep56d-0003Dc-Cj for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 09:38:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20427 for ; Wed, 21 Dec 2005 09:37:10 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8221CFB299; Wed, 21 Dec 2005 09:38:13 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B15DFFB28A; Wed, 21 Dec 2005 09:38:10 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 01FA7FB294; Wed, 21 Dec 2005 09:38:09 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 50747FB286 for ; Wed, 21 Dec 2005 09:38:07 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jBLEbmn25933; Wed, 21 Dec 2005 15:37:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jBLEblls099898; Wed, 21 Dec 2005 15:37:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512211437.jBLEblls099898@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Fri, 09 Dec 2005 13:10:02 +0200. <4399660A.5040106@piuha.net> Date: Wed, 21 Dec 2005 15:37:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: We are now starting the Working Group Last Call on the design document. => here are my comments: Abstract ... This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. => there is nothing about the fact the design and the protocol are about a first version of the MOBIKE tools. I support anyone who'd like to make it an issue as the current solution addresses only one part of the charter scenarios. 1. Introduction ... single pair in the outer IP headers. Existing documents make no provision to change this pair after an IKE SA is created. => this is not true: RFC 3775 and 3776 K bit stuff does exactly this. 3.2. Multihoming Scenario ... Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available IP addresses at a given point in time. => this is not the common definition of load balancing (where the restriction to only one address is per communication). 3.3. Multihomed Laptop Scenario ... GPRS adaptor, a Bluetooth interface or USB hardware. Not all interfaces are used for communication all the time for a number of reasons (e.g., cost, network availability, user convenience). The => "not all" is not "only one". 5.3. Scope of SA Changes ... If IPsec SAs should be updated separately then a more efficient format than the Notify payload is needed to preserve bandwidth. A Notify payload can only store one SPI per payload. A separate payload could have a list of IPsec SA SPIs and the new preferred address. If there is a large number of IPsec SAs, those payloads can be quite large unless ranges of SPI values are supported. If we => ranges of SPI values don't make sense: please use a reasonnable argument or no argument at all! automatically move all IPsec SAs when the IKE SA moves, then we only need to keep track of which IKE SA was used to create the IPsec SA, and fetch the IP addresses from the IKE SA, i.e. there is no need to store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec- => I don't believe there is an implementation which doesn't store IP addresses per IPsec SA. If we do allow address set of each IPsec SA to be updated separately, then we can support scenarios where the machine has fast and/or cheap connections and slow and/or expensive connections, and wants to allow moving some of the SAs to the slower and/or more expensive connection, and prevent the move, for example, of the news video stream from the WLAN to the GPRS link. => exactly On the other hand, even if we tie the IKE SA update to the IPsec SA update, then we can create separate IKE SAs for this scenario, e.g., we create one IKE SA which has both links as endpoints, and it is used for important traffic, and then we create another IKE SA which has only the fast and/or cheap connection, which is then used for that kind of bulk traffic. => we can drop the whole MOBIKE stuff using the same argument. The working group decided to move all IPsec SAs implicitly when the IKE SA address pair changes. If more granular handling of the IPsec SA is required, then multiple IKE SAs can be created one for each set of IPsec SAs needed. => please keep this and not try to give poor arguments to defend the decision (it is the WG decision ".") 5.4. Zero Address Set Functionality (I've stopped here, I'll put comments about next stuff in another message). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 11:52:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7C9-0005Sj-Ve for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:52:06 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14309 for ; Wed, 21 Dec 2005 11:51:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EE49CFB28A; Wed, 21 Dec 2005 11:52:03 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 71C79FB282; Wed, 21 Dec 2005 11:51:58 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 079FAFB284; Wed, 21 Dec 2005 11:51:57 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id DCCFFFB27F for ; Wed, 21 Dec 2005 11:51:54 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jBLGpZn09469; Wed, 21 Dec 2005 17:51:35 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jBLGpY3b000570; Wed, 21 Dec 2005 17:51:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512211651.jBLGpY3b000570@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Fri, 09 Dec 2005 13:10:02 +0200. <4399660A.5040106@piuha.net> Date: Wed, 21 Dec 2005 17:51:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: We are now starting the Working Group Last Call on the design document. Here is the URL: => comments from 5.4... 5.6. IPsec Tunnel or Transport Mode Current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behavior would also be useful, but will be discussed in future documents. => (this is a comment for the mailing list) as the issue is the addresses are in the traffic selectors so it is hard to change them a priori, I'll extend my proposed document about transport mode to handle all the cases where the issue does not exist, in particular SCTP (without dynamic addresses) where all the addresses are already in the selectors (so one only changes the "active" part of selectors) and tunnels a la Joe Touch where there is no addresses in selectors (i.e., the interface is the only meaningful selector). 6.3. Message presentation ... Load balancing is currently outside the scope of MOBIKE, however => as you shot in your feet with the non standard definition of load balancing now you are in trouble because you still don't want the real load balancing (multiple addresses in the same SA at the same time) but want the thing in the middle (one address per SA but different addresses in SAs and/or in time). future work might include support for it. The selected format needs to be flexible enough to include additional information in future versions of the protocol (e.g. to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As there may arise other information which may have to be tied to an address in the future, a reserved field seems like a prudent design in any case. 6.4. Updating address list => s/list/set/ (this is important because lists should be ordered but not sets). Here we have sets with a particular element. MOBIKE could send the full peer address list every time any of the IP => s/full/whole/ ? 7. Security Considerations As all the messages are already authenticated by IKEv2 there is no risk that any attackers would modify the contents of the packets. => as messages and packets are not the same this is not correct (as the following show), so s/packets/messages/ The IP addresses in the IP header of the packets are not authenticated, thus the protocol defined must take care that they are only used as an indication that something might be different, and that do not cause any direct actions, except when doing NAT Traversal. => I strongly disagree: not authenticate the IP addresses just leaves the protocol vulnerable to attacks modifying them, i.e., you can establish the IKE SA and IPsec SAs with a bad address (cf what I call the "transient pseudo-NAT" attack. There are three "solutions" - authenticate the IP address using something else, for instance check if it is in the certificate (this is the usual way) - don't care and leave a security flaw (I am afraid this is the option of many road-warrior VPNs :-) - reflect the IP address in messages in order to detect changes. This is the option used by Mobike which requires either NAT dectection or NAT prevention So please update the design security considerations! 10.2. Informative References [I-D.dupont-mipv6-3bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), June 2005. => I submitted a 03 version this morning. [I-D.ietf-mip6-ro-sec] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-03 (work in progress), May 2005. => this was published as the RFC 4225 (with many authors). [I-D.ietf-ipv6-optimistic-dad] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in progress), September 2005. => not referenced (it seems the last xml2rfc detects this) [I-D.ietf-ipv6-unique-local-addr] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in progress), January 2005. => same issue. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 12:07:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7R1-0000ce-1E for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 12:07:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16161 for ; Wed, 21 Dec 2005 12:06:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 639BBFB298; Wed, 21 Dec 2005 12:07:24 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 025C7FB286; Wed, 21 Dec 2005 12:07:22 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 74783FB28A; Wed, 21 Dec 2005 12:07:20 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 5847BFB282 for ; Wed, 21 Dec 2005 12:07:19 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B614E898BF; Wed, 21 Dec 2005 19:07:17 +0200 (EET) Message-ID: <43A98B82.8090203@piuha.net> Date: Wed, 21 Dec 2005 19:06:10 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200512211651.jBLGpY3b000570@givry.rennes.enst-bretagne.fr> In-Reply-To: <200512211651.jBLGpY3b000570@givry.rennes.enst-bretagne.fr> Cc: MOBIKE Mailing List Subject: [Mobike] References (Was: Re: WGLC on the design draft) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit >10.2. Informative References > > [I-D.dupont-mipv6-3bombing] > Dupont, F., "A note about 3rd party bombing in Mobile > IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), > June 2005. > >=> I submitted a 03 version this morning. > > Ack. > [I-D.ietf-mip6-ro-sec] > Nikander, P., "Mobile IP version 6 Route Optimization > Security Design Background", draft-ietf-mip6-ro-sec-03 > (work in progress), May 2005. > >=> this was published as the RFC 4225 (with many authors) > > Yes. > [I-D.ietf-ipv6-optimistic-dad] > Moore, N., "Optimistic Duplicate Address Detection for > IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in > progress), September 2005. > >=> not referenced (it seems the last xml2rfc detects this) > > [I-D.ietf-ipv6-unique-local-addr] > Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast > Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in > progress), January 2005. > >=> same issue. > > Both of these ARE referenced. The other reference has a linebreak I think, which may have caused you to not notice. The references are from the definitions in Sect. 2. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 21 12:43:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep80G-00023D-H4 for mobike-archive@megatron.ietf.org; Wed, 21 Dec 2005 12:43:52 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21777 for ; Wed, 21 Dec 2005 12:42:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 08C21FB297; Wed, 21 Dec 2005 12:43:51 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7A0C4FB286; Wed, 21 Dec 2005 12:43:47 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 547BCFB28A; Wed, 21 Dec 2005 12:43:46 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 11516FB282 for ; Wed, 21 Dec 2005 12:43:45 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jBLHhbn14353; Wed, 21 Dec 2005 18:43:37 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jBLHhbrN000844; Wed, 21 Dec 2005 18:43:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512211743.jBLHhbrN000844@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Wed, 21 Dec 2005 19:06:10 +0200. <43A98B82.8090203@piuha.net> Date: Wed, 21 Dec 2005 18:43:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List Subject: Re: [Mobike] References (Was: Re: WGLC on the design draft) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: Both of these ARE referenced. => you're right (I did the grep in the wrong file). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 23 07:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eplxn-0004L9-91 for mobike-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:23:59 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04217 for ; Fri, 23 Dec 2005 07:22:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 83D7CFB289; Fri, 23 Dec 2005 07:23:52 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AAC6DFB286; Fri, 23 Dec 2005 07:23:49 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 392ADFB289; Fri, 23 Dec 2005 07:23:47 -0500 (EST) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 2ADF9FB281 for ; Fri, 23 Dec 2005 07:23:46 -0500 (EST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNCManK011873 for ; Fri, 23 Dec 2005 14:22:41 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:23:41 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:23:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Dec 2005 14:23:41 +0200 Message-ID: Thread-Topic: Design draft, overall comments Thread-Index: AcYHu7W8qoHveaZHStOL/7Nztx3BNg== From: To: X-OriginalArrivalTime: 23 Dec 2005 12:23:41.0308 (UTC) FILETIME=[B590C3C0:01C607BB] Subject: [Mobike] Design draft, overall comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit - My first impression is that the document probably isn't very easy to read for someone who hasn't followed the design discussions. But I don't know what exactly should be done to help this, and perhaps it's not even that important. - The document should probably more explicitly say that the scope is the design of draft-ietf-mobike-protocol, not any other work items that MOBIKE WG may decide to work on. - There's some overlap in the general background/motivation text and scenarios (sections 1 and 3) with draft-ietf-mobike-protocol. Perhaps it would be easier to say that this document is meant to be read with draft-ietf-mobike-protocol, not alone. - I'd suggest placing all instances of MAY/SHOULD/MUST etc. in quotes (or changing them to lowercase) to show that we're just describing that e.g. we decided to add this requirement in the protocol, but this document itself is not imposing any requirements for anyone. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 23 07:25:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eplyv-0004V8-Qi for mobike-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:25:09 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04345 for ; Fri, 23 Dec 2005 07:24:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2C4D7FB299; Fri, 23 Dec 2005 07:25:04 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5D0AFFB289; Fri, 23 Dec 2005 07:25:02 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E83B4FB28E; Fri, 23 Dec 2005 07:24:59 -0500 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id B86AEFB281 for ; Fri, 23 Dec 2005 07:24:57 -0500 (EST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNCKwvC017365 for ; Fri, 23 Dec 2005 14:21:02 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:24:43 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:24:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Dec 2005 14:24:43 +0200 Message-ID: Thread-Topic: Design draft, terminology Thread-Index: AcYHu9qmhQY6ufJQQiSUFjqFIzpP6A== From: To: X-OriginalArrivalTime: 23 Dec 2005 12:24:42.0544 (UTC) FILETIME=[DA10A300:01C607BB] Subject: [Mobike] Design draft, terminology X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit - Overall: My impression is that most of this section is baggage we accumulated from other documents, but don't actually need anymore. Some of the terms are never used outside the terminology section, and some others are used only once or twice. - "Available address": Neither IKEv2, 2401bis nor draft-ietf-mobike-protocol prohibits using IPsec for link-local addresses (although it's probably not very useful in most cases), so this definition is not totally accurate. - "Available address": RFC2462 defines "tentative address" as "an address whose uniqueness on a link is being verified, prior to its assignment to an interface." Thus, it seems mentioning tentative addresses in this context is redundant. - "Locally operational address" is not used anywhere else except the terminology section. - "Full Cone", "Restricted Cone", and "Port Restricted Cone" are not used anywhere in the document. - "Preferred Address": This term is quite unclear (as I've pointed out earlier). Does this mean the "current address" ("what was in the newest UPDATE_SA_ADDRESSES message" -- but then calling it "preferred" is misleading), or something different? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 23 07:25:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eplz2-0004VU-Ta for mobike-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:25:17 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04357 for ; Fri, 23 Dec 2005 07:24:10 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 720D2FB2A2; Fri, 23 Dec 2005 07:25:15 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9BDF5FB28E; Fri, 23 Dec 2005 07:25:13 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BE0C2FB297; Fri, 23 Dec 2005 07:25:11 -0500 (EST) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id BE977FB28E for ; Fri, 23 Dec 2005 07:25:09 -0500 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNCO45M013025 for ; Fri, 23 Dec 2005 14:24:05 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:25:03 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:25:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Dec 2005 14:25:04 +0200 Message-ID: Thread-Topic: Design draft, return routability Thread-Index: AcYHu+cVAWBXzKnbRxGM8CS3H3IlDQ== From: To: X-OriginalArrivalTime: 23 Dec 2005 12:25:03.0325 (UTC) FILETIME=[E67390D0:01C607BB] Subject: [Mobike] Design draft, return routability X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit - "Finally it would be possible not to execute return routability checks at all. In case of indirect change notifications we only move to the new preferred address after successful dead-peer detection (i.e., a response to a DPD test) on the new address, which is already a return routability check." Confusing text; we don't execute return routability checks at all, but we do it already. And what exactly are the indirect change notifications we're talking about here? - "but potential attacks are possible if a return routability check does not include some kind of a nonce." A return routability check verifies that the peer can receive messages sent to this address. If the message doesn't do this, then IMHO it's not a return routability check at all. So I'd rewrite this section to say something like "A successful IKEv2 informational exchange itself does not perform a return routability check because ... and thus a nonce is needed ...". - The text about different levels of return routability checks is very confusing. A return routability check should verify the IKEv2 peer can receive packets sent to the given address; a check that just verifies that "someone can receive packets at the given address" is something quite different! I'd suggest removing most of this text. - Section 5.5.1: Again, confusing text: if some other protocol wants to know "can remote entity A receive packets sent to X?", MOBIKE might be able to provide information that "remote entity B can receive packets sent to X" -- but this is not very useful unless we can also know that A and B are the same entity (with some reasonable definition of "sameness"). I'd suggest shortening this text and stating that this was deemed complex, not absolutely needed, and thus beyond the scope. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 23 07:26:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epm02-0004bs-9X for mobike-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:26:18 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04413 for ; Fri, 23 Dec 2005 07:25:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0B729FB29D; Fri, 23 Dec 2005 07:26:17 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D14BAFB289; Fri, 23 Dec 2005 07:26:14 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C5D68FB28E; Fri, 23 Dec 2005 07:26:13 -0500 (EST) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 21B84FB281 for ; Fri, 23 Dec 2005 07:26:12 -0500 (EST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNCQAPn001044 for ; Fri, 23 Dec 2005 14:26:11 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:25:33 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 14:25:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Dec 2005 14:25:33 +0200 Message-ID: Thread-Topic: Design draft, misc. comments Thread-Index: AcYHu/hinYUjqjs+QGCclntO0l7zxg== From: To: X-OriginalArrivalTime: 23 Dec 2005 12:25:32.0323 (UTC) FILETIME=[F7BC4F30:01C607BB] Subject: [Mobike] Design draft, misc. comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit - Section 1, "for example when using SecurID cards" -> "for example, when using human-operated token cards" - Section 3.2: "Each peer selects one of its IP addresses as the preferred address which is used for subsequent communication." There's some conflict here. It's the initiator who selects which addresses are used for subsequent communication (except in relatively rare situations, ie. responder address changes). - Section 4: "The MOBIKE protocol should be able to perform...": this text may need to be rewritten once we either come up with a reasonable definition for "preferred address", or get rid of the term completely. - Section 4: The talk about "MOBIKE daemon" creates the impression that there typically would be both an "IKEv2 daemon" and "MOBIKE daemon", running as separate processes. While this is not impossible, I would find it a very strange way to implement a relatively minor extension to IKEv2. (After all, if we implement some other IKEv2 extension like draft-nir-ikev2-auth-lt, we don't call it the "Repeated Authentication Daemon" or something.) - Section 5.1.4, 1st paragraph: closing parenthesis missing. - Section 5.2.1, a couple of informative references might be in order (UNSAF, MIDCOM, NSIS NATFW) - Section 6.3: "The selected format needs to be flexible enough to include additional information in future versions of the protocol (e.g. to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As there may arise other information which may have to be tied to an address in the future, a reserved field seems like a prudent design in any case." IMHO it would be quite difficult to design the protocol in a way that would totally prevent future extensions from sending additional information. But currently we don't have any "reserved" fields there (simply because they're not needed -- the normal IKEv2 extension mechanisms will allow us to add more stuff later). - References: should draft-ietf-mobike-protocol be normative? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike