From mailman-bounces@machshav.com Fri Apr 1 00:03:17 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20523 for ; Fri, 1 Apr 2005 00:03:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0F363FB2B0; Fri, 1 Apr 2005 00:03:18 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 34DB8FB378 for ; Fri, 1 Apr 2005 00:01:26 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: machshav.com mailing list memberships reminder From: mailman-owner@machshav.com To: mobike-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Apr 2005 05:00:18 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.5 List-Id: mailman.machshav.com X-List-Administrivia: yes Sender: mailman-bounces@machshav.com Errors-To: mailman-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your machshav.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@machshav.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@machshav.com. Thanks! Passwords for mobike-archive@lists.ietf.org: List Password // URL ---- -------- mobike@machshav.com behoef https://www.machshav.com/mailman/options.cgi/mobike/mobike-archive%40lists.ietf.org From mobike-bounces@machshav.com Sun Apr 3 14:12:36 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15555 for ; Sun, 3 Apr 2005 14:12:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 333BFFB29D; Sun, 3 Apr 2005 14:12:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 564F4FB297; Sun, 3 Apr 2005 14:12:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 67E51FB298; Sun, 3 Apr 2005 14:12:27 -0400 (EDT) Received: from massilia.int-evry.fr (massilia.int-evry.fr [157.159.10.13]) by machshav.com (Postfix) with ESMTP id B8AA3FB293 for ; Sun, 3 Apr 2005 14:12:24 -0400 (EDT) Received: from massilia.int-evry.fr (localhost.localdomain [127.0.0.1]) by massilia.int-evry.fr (8.12.11/8.12.11) with ESMTP id j33ICM3E022651; Sun, 3 Apr 2005 20:12:22 +0200 Received: (from apache@localhost) by massilia.int-evry.fr (8.12.11/8.12.11/Submit) id j33ICHrS022639; Sun, 3 Apr 2005 20:12:17 +0200 X-Authentication-Warning: massilia.int-evry.fr: apache set sender to Khaled.Masmoudi@int-evry.fr using -f Received: from bob75-1-82-234-75-191.fbx.proxad.net (bob75-1-82-234-75-191.fbx.proxad.net [82.234.75.191]) by imp.int-evry.fr (IMP) with HTTP for ; Sun, 3 Apr 2005 20:12:17 +0200 Message-ID: <1112551937.42503201c6e84@imp.int-evry.fr> Date: Sun, 3 Apr 2005 20:12:17 +0200 From: Khaled Masmoudi To: mobike@machshav.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 82.234.75.191 Cc: hossam.afifi@int-evry.fr, djamal.zeghlache@int-evry.fr Subject: [Mobike] ASWN 2005 CFP - extended deadline : April 11th X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 8bit [My sincere apologies if you receive multiple copies of this CFP] CALL FOR PAPERS ------------------------------------------------------ ASWN 2005 5th Workshop on Applications and Services in Wireless Networks Maison de la Chimie 28 rue Saint Dominique- 75007, Paris - FRANCE June 29th - July 1st, 2005 -------------------------------------------------------- ASWN 2005 is the fifth workshop on Applications and Services in Wireless Networks. The workshop addresses the challenges and advances in future wireless applications and services that span all wireless architectures and technologies, such as cellular, WLAN, WPAN, ad hoc, and sensor networks. The format of the workshop is based on three-day single-track sessions, with presentations of invited and regular papers from academia and industry. This year's special theme is the impact of newly emerging technologies, such as sensor networks, embedded systems, systems on chip, and nanotechnologies, on wireless applications and services. The workshop solicits original technical paper contributions in the scope of the workshop, describing theoretical and practical recent results or developments. In particular, we seek submissions that present advances in open programmable and directory enabled networking, overlay networks, user-centric open service frameworks, and ambient service and network paradigms. Papers should be submitted according to the instructions and schedule below. All submissions, including invited papers, will undergo a thorough review process. We also solicit tutorial proposals on topics of interest to the workshop's community. -------------------------------------------------------------------- PAPERS Submitted papers should be full-scope manuscripts, and should not have been previously published, in part or in full, or be under consideration of another conference or journal. Submissions should be written in English, following the IEEE double-column standard format, using fonts no smaller than 10 points, and should not exceed 10 single-spaced pages. All submissions will be handled electronically, and only PDF and PostScript formats will be accepted. Authors can find further details on the submission procedure on of the workshop main page at: http://www.int-evry.fr/aswn/ To facilitate the production of papers in the required IEEE formatting standard, you may consult IEEE Transactions LaTeX and Microsoft Word Style Files at http://www.ieee.org/organizations/pubs/transactions/stylesheets.htm . Tutorial proposals should not exceed 3 pages and should outline in sufficient details the topic and the credentials of the instructor. Tutorial proposals should follow the same schedule and submission procedure as the workshop's papers. All accepted papers will be published in the Workshop proceedings. Selected best papers will be published in a journal in a second phase. --------------------------------------------------------------------- IMPORTANT DEADLINES Full paper submission (EXTENDED DEADLINE): April 11, 2005 Notification of acceptance: April 29, 2005 Camera ready due: May 15, 2005 --------------------------------------------------------------------- TOPICS Specific areas of interest in Applications and Services on Wireless Networks include, but are not limited to, the following topics: Advances in WPAN, Personal Services and Networks Mobile Ad-Hoc Networks and Multihop Wireless Sensor Networks Self Organizing Systems Moving Networks Inter Domain and System Mobility Service discovery : protocols and frameworks Naming and Addressing Peer to Peer communications and paradigms Media & content distribution over wireless networks Audio-visual and Mobile Multimedia Applications Nomadic Services Middleware for Mobile Applications and Services Service Execution Environments, Service Life Cycle and Mobile Service Interworking Context Awareness and Personalization QoS Profiling and Pricing, end-to-end QoS Security architectures and mechanisms Reconfigurable Systems and Networks Cooperative Networks Beyond 3G Enabling Technologies and Architectures Performance of Wireless Networks and Systems ---------------------------------------------------------- GENERAL Co-CHAIRs Zygmunt J. Haas, Cornell University, USA Ramjee Prasad, AAU, Denmark TECHNICAL PROGRAM Co-CHAIRS Hossam Afifi, INT-GET, Evry, France Djamal Zeghlache, INT-GET, France --------------------------------------------------------- STEERING COMMITTEE Hossam Afifi, INT-GET, Evry, France Torsten Braun, University of Bern, Switzerland Sudhir Dixit, Nokia, USA Nada Golmie, NIST, USA Ibrahim Matta, Boston University, USA Ramjee Prasad, Aalborg University, Denmark John Farserotou, CSEM, Switzerland Djamal Zeghlache, INT-GET, France -------------------------------------------------------- TECHNICAL COMMITTEE Alhussein Abouzeid, RPI, USA Hossam Afifi, INT-GET, France Nancy Alonistioti, UoA, Greece Stefan Arbanowski, FOKUS, Germany Khaled Ben Letaief, UHKST, Hong Kong Torsten Braun, University of Bern, Switzerland Stefano Bregni, Politecnico di Milano, Italy Doru Calin, Lucent, USA Brigitte Cardinael, FT R & D, France Anna Cavalli, INT-GET, France Mark Corner, University of Massachusetts, USA Isabelle Demeure, ENST-GET, Paris, France Panagiotis Demistichas, University of Pireaus, Greece Olaf Droegehorn, Uni. Kassel, Germany Henk Ertink, Telematica Institut, Netherlands Ioanis Fikouras, BIBA, Germany Savo Glisic, University of Oulu, Finland Nada Golmie, NIST, USA Wendi Heinzelman, University of Rochester, USA Sonia Heemstra de Groot, TI-WMC, Netherlands Dimitris Kalofonos, Nokia, USA Wolfgang Kellerer, NTT DoCoMo Europe, Germany Farooq Khan, Samsung, USA Bhaskar Krishnamachari, USC, USA Houda Labiod, ENST-GET, France Peter Langendoerfer, IHP Microelectronics, Germany Whay Lee, Motorola Labs, USA Victor C.M. Leung, Univ. British Columbia, Canada Migyan Liu, University of Michigan, USA Mikael Latvala, Nokia , Finland Maryline Laurent-Maknavicius, INT-GET, France Petri, Mahonen, Aachen University, Germany Antonis Markopoulos, NTUA, Greece Ibrahim Matta, Boston University, USA Ingrid Moerman, IMEC, Belgium Luis Munoz, Univ. Cantabria, Spain Ignas Niemegeers, TU Delft, Netherlands Kaisa Nyberg, Nokia, Finland (TBC) Simon Oosthoek, TI-WMC, Netherlands Neeli Prasad, CTIF, Denmark Guy Pujolle, LIP6 France Hamed Al-Raweshidy, Brunel, UK Vincent Roca, INRIA, Grenoble Laurent Reynaud, France Telecom, France Jochen H. Schiller, Freie University, Germany Ahmed Serhrouchni, ENST-GET, France Dorgham Sisalem, Fokus, Germany Weilian Su, Naval Post Graduate School, CA, USA Tricha Anjali, Illinois Institute of Technology, USA Hector Velayos, KTH, Sweden Cedric Westphal, Nokia Research, USA Alec Woo, Berkeley, CA, USA Jiang Xie, University of North Carolina, USA Herma Van Kranenburg, Telematica Institut, Netherlands Halim Yanikomeroglu, Carleton, CA Djamal Zeghlache, INT-GET, France ------------------------------------------------------------------------- ORGANIZING COMMITTEE Khaled Masmoudi, INT-GET, France Kaouthar Sethom, INT-GET, France Wajdi Louati, INT-GET, France Mehdi Sabeur, INT-GET, France Marc Girod Genet, INT-GET, France Badii Jouaber, INT-GET, France Isabelle Rebillard, INT-GET, France Mélanie Blanchard, INT-GET, France --------------------------------------------------------------------- TECHNICAL SPONSORSHIPS and SPONSORS IEEE TCPC Groupe des Ecoles de Télécommunications (GET) Working groups 2, 3 and 6 of WWRF Special Participation of IST-FP6 Project MAGNET ---------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Khaled Masmoudi (PhD student) Institut National des Télécommunications RS2M Dep. CNRS UMR Samovar 5157 9, rue Charles Fourier - 91011 Evry Cedex Tél : +33 1 60 76 42 65 Fax : +33 1 60 76 45 78 khaled.masmoudi@int-evry.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Apr 4 06:58:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17179 for ; Mon, 4 Apr 2005 06:58:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0DFA2FB2A9; Mon, 4 Apr 2005 06:58:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 51CEDFB299; Mon, 4 Apr 2005 06:58:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CE555FB2A6; Mon, 4 Apr 2005 06:58:00 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 41ACCFB298 for ; Mon, 4 Apr 2005 06:57:59 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j34Avu29021513 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Apr 2005 13:57:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j34AvteF021510; Mon, 4 Apr 2005 13:57:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16977.7603.98381.2831@fireball.kivinen.iki.fi> Date: Mon, 4 Apr 2005 13:57:55 +0300 From: Tero Kivinen To: Jari Arkko Subject: [Mobike] issue 11 -- window size In-Reply-To: <424AB7FF.3080408@piuha.net> References: <424AB7FF.3080408@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 28 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Jari Arkko writes: > > This issue is about the window size. Mobike needs to be able to > send multiple messages, given that a regular IKEv2 exchange > may be in progress when we suddenly change our IP address. > The question is whether we should expect IKEv2 implementations > to support window size greater than 1, or if Mobike's own > exchanges are in some sense outside the regular IKEv2 > window (as proposed in Pasi's MOPO protocol). > > The background information we got in the meeting was that > in the IKEv2 bakeoff many implementors did not have > support for larger than 1 window sizes. > > So we could either require a larger window size or do MOBIKE > exchanges outside the window. I did not sense a conclusion > in the meeting about this, but on the other hand I'm not sure > if people care about this issue very deeply. For the purpose > of making progress, let me propose one approach. If the > decision was "do it outside the window", would people have > problems with that? There is also one other option, i.e. the way my original protocol proposal did it, i.e. every IKE packet can be used to test the paths. If you add also so that every IKE packet also includes the information needed to do mobility that solves the problem with window size 1. I.e. if mobike needs n payload for its processing, you add those n payloads to all IKE packets, and then when you are retransmitting the IKE packet you simply also use that packet to do path finding, i.e. change the source and destination addresses but keep the packet same. The responder will reply to reversed addresses, and after that IKE exchange both ends know that the path has changed, and can take appropriate actions (either automatically or manually by sending another exchange). That protocol will work with window size of 1, and it does not need any packets that are outside of the normal window processing. If we still do manual actions, then we actually do not need any special payloads in the IKE packets. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Apr 4 08:51:16 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01965 for ; Mon, 4 Apr 2005 08:51:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 46AB0FB2AA; Mon, 4 Apr 2005 08:51:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3FC74FB298; Mon, 4 Apr 2005 08:51:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5F2F3FB299; Mon, 4 Apr 2005 08:51:08 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C8499FB297 for ; Mon, 4 Apr 2005 08:51:07 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B198689862; Mon, 4 Apr 2005 15:51:05 +0300 (EEST) Message-ID: <42513836.1040308@piuha.net> Date: Mon, 04 Apr 2005 15:51:02 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] issue 11 -- window size References: <424AB7FF.3080408@piuha.net> <16977.7603.98381.2831@fireball.kivinen.iki.fi> In-Reply-To: <16977.7603.98381.2831@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Hi Tero, This is interesting, I think it looks attractive! (So what exactly would "information needed to do mobility and path testing" constitute? Presumably, one of the things that we would probably need is a NAT-D payload. Would this mean that if we have send request X and later realize that we don't get a response and have to retransmit on another, new interface, we resubmit X exactly as-is? Or can we add "mobility data", such as NAT-D payload? Or perhaps "mobility data" is simply the source address and NAT-D payloads are always included...?) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Apr 5 03:58:44 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19820 for ; Tue, 5 Apr 2005 03:58:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E7954FB2A1; Tue, 5 Apr 2005 03:58:40 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A8B30FB298; Tue, 5 Apr 2005 03:58:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1AF3CFB299; Tue, 5 Apr 2005 03:58:36 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7BADDFB28F for ; Tue, 5 Apr 2005 03:58:33 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j357wUJN005876 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 10:58:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j357wTHd005873; Tue, 5 Apr 2005 10:58:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.17701.446055.840859@fireball.kivinen.iki.fi> Date: Tue, 5 Apr 2005 10:58:29 +0300 From: Tero Kivinen To: Jari Arkko Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <42513836.1040308@piuha.net> References: <424AB7FF.3080408@piuha.net> <16977.7603.98381.2831@fireball.kivinen.iki.fi> <42513836.1040308@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 31 min X-Total-Time: 30 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Jari Arkko writes: > (So what exactly would "information needed to > do mobility and path testing" constitute? Depends about the answers to issue 3... > Presumably, one of the things that we would probably need is a NAT-D > payload. Not necessarely, in the simplies form it would be simply outer IP addresses and ports. > Would this mean that if we have send request X and later > realize that we don't get a response and have to retransmit > on another, new interface, we resubmit X exactly as-is? Yes. The packet must be resubmitted as-is, only IP-addresses and ports can change. There responder might be taking HASH of the packet when processing it and store the reply packet, and when he sees the retransmission he must be able to match the hash of the previous retransmission to this new one. > Or can we add "mobility data", such as NAT-D payload? No, we cannot add those. > Or perhaps "mobility data" is simply the source address > and NAT-D payloads are always included...?) That would be one option. I.e. in the simpliest way to get the protocol working would be something like this: Host A has 3 IP-addresses A1, A2, A3 Host B has 2 IP-addresses B1, B2 IKE SA is currently using (A1, B1) Host A starts CREATE_CHILD_SA (message ID 55), and sends packet to B. (A1, B1, 55) CREATE_CHILD_SA -> (dropped) There is something wrong with the path A1,B1 and packet is dropped (B1 does not work...) Host A retransmits few times: (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA -> (dropped) Host A notices he is not getting packets back, he starts searching for the working address pair: (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B2, 55) CREATE_CHILD_SA -> Host B gets the packet.. Host B will immediately notice that there is something wrong with the path as the Host A is using different ports, but he simply continues processing the packet normally, and replies (with message id 55R) to the reversed addresses <- (B2, A1, 55R) CREATE_CHILD_SA reply Host A gets the packet and notices that he has found a working path. He decides that the he should move the traffic to that new address pair too, so he sends address update packet to host B: (A1, B2, 56) N(UPDATE ADDRESSES) -> Host B updates his SAs to new address pair, and replies. <- (B2, A1, 56R) N(UPDATE ADDRESS reply) Now if we want to see why we cannot modify the packet between retranmissions take the next case where we have also shorter temporary failures or one way connections. Connection between A1 and B2 breaks down (A1 address does not work). Host A notices that he hasn't received anything and starts DPD. (A1, B2, 57) DPD -> (dropped) (A1, B2, 57) DPD -> (dropped) (A1, B2, 57) DPD -> (dropped) Host A notices that he is not getting anything back so he starts searching for the working address pair: (A2, B1, 57) DPD -> Host B gets the packet, and replies to it, but the packet is dropped because of some other reason (one way path etc). Host B has now calculated HASH(DPD) and stored it in his incoming window for message id 57, and also has stored the "DPD reply" to be sent back in case the message id 57 (HASH(DPD)) is retranmitted. (drop) <- (B1, A2, 57R) DPD reply Host A retransmits (A2, B1, 57) DPD -> Host B gets retramission of 57, he verifies that it is retranmission by checking the HASH(DPD), and because it matches, he sends stored copy of message id 57R back, without doing any more processing for the packet (i.e. he does not run any IKE state machines to process the packet). (drop) <- (B1, A2, 57R) DPD reply Host A moves to next address and retransmits (A3, B1, 57) DPD -> Host B again notices about retranmission, and replies with his stored packet. <- (B1, A3, 57R) DPD reply Now host A gets the packet, and he notices that the previously working path (A1, B2) does not work anymore, but path (A3, B1) works, so he updates the SAs to that new address pair (A3, B1, 58) N(UPDATE ADDRESSES) -> Host B process this new notify, and replies <- (B1, A3, 58R) N(UPDATE ADDRESSES reply) Host A and Host B again has working SAs. So any packets between A and B needs to be processed identically, i.e. all of them are finding the working address pair. After we have found out the working address pair, we start the actual movement request with the specific exchange N(UPDATE ADDRESS). Of course also the N(UPDATE ADDRESS) packets gets the same processing, i.e. if the packets do not get through we start searching for the working address pair. Depending on the protocol and contents of N(UPDATE ADDRESS) we need to decide what we do if the address pair changes during the N(UPDATE ADDRESS) exchange. I.e. if the addresses are also stored inside the N(UPDATE ADDRESSES) then we can see that the addresses of outer header and inside notify does not match, so either there is NAT or the initiator needed to start address pair search after construction the packet. In that case B can either reject the update (NAT prevention) or simply accept it. If host A needed to start address pair search, and he didn't like the result he can start searching new address pair and when he has found the one he likes, he can redo the N(UPDATE ADDRESS). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Apr 5 04:22:59 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22769 for ; Tue, 5 Apr 2005 04:22:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E5BC5FB29E; Tue, 5 Apr 2005 04:22:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 02091FB298; Tue, 5 Apr 2005 04:22:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D57EAFB299; Tue, 5 Apr 2005 04:22:52 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id B745AFB28F for ; Tue, 5 Apr 2005 04:22:51 -0400 (EDT) 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 j358MdW02374; Tue, 5 Apr 2005 10:22:39 +0200 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 j358Mcvj093590; Tue, 5 Apr 2005 10:22:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mobike] issues 18, 15, 6 -- return routability In-reply-to: Your message of Wed, 30 Mar 2005 17:12:41 +0300. <424AB3D9.60008@piuha.net> Date: Tue, 05 Apr 2005 10:22:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 In your previous mail you wrote: - If the specific IP address can be found in the peer's certificate, you can skip the test => I maintain my proposal to change this into "if the specific IP address is already authorized, you can skip the test". This is more general (as there can be other ways to authorized an address) and more accurate (so it should answer Vijay's concern). 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 Tue Apr 5 05:34:55 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29147 for ; Tue, 5 Apr 2005 05:34:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2FFD5FB2A1; Tue, 5 Apr 2005 05:34:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2D0C3FB298; Tue, 5 Apr 2005 05:34:50 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E1CC2FB299; Tue, 5 Apr 2005 05:34:47 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 9C7B4FB28F for ; Tue, 5 Apr 2005 05:34:46 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j359YcXR006921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 12:34:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j359Yb4p006918; Tue, 5 Apr 2005 12:34:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.23469.695763.696396@fireball.kivinen.iki.fi> Date: Tue, 5 Apr 2005 12:34:37 +0300 From: Tero Kivinen To: Francis Dupont Subject: Re: [Mobike] issues 18, 15, 6 -- return routability In-Reply-To: <200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> References: <424AB3D9.60008@piuha.net> <200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 13 min Cc: mobike@machshav.com, Jari Arkko X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Francis Dupont writes: > In your previous mail you wrote: > > - If the specific IP address can be found in the peer's certificate, > you can skip the test > > => I maintain my proposal to change this into "if the specific IP address > is already authorized, you can skip the test". > This is more general (as there can be other ways to authorized an address) > and more accurate (so it should answer Vijay's concern). Agree on Francis on this. We do not need to specify how it is already authorized. Certificate is one way, typed in to the configuration, or authorized by the dnssec information are others. Most of the cases where the IP-address is already authorized are the cases where there is multihoming SGW so all IP-addresses are already known when the machine is installed, but mobike is simply used because of the multihoming aspect to select which of those IP-addresses are used. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Apr 5 11:59:19 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03501 for ; Tue, 5 Apr 2005 11:59:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 62931FB2A2; Tue, 5 Apr 2005 11:59:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 90C73FB2A0; Tue, 5 Apr 2005 11:59:14 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7EBEBFB2A1; Tue, 5 Apr 2005 11:59:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id E7CB3FB298 for ; Tue, 5 Apr 2005 11:59:11 -0400 (EDT) Message-ID: <030201c539f8$91082570$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tero Kivinen" , "Francis Dupont" References: <424AB3D9.60008@piuha.net><200504050822.j358Mcvj093590@givry.rennes.enst-bretagne.fr> <16978.23469.695763.696396@fireball.kivinen.iki.fi> Subject: Re: [Mobike] issues 18, 15, 6 -- return routability Date: Tue, 5 Apr 2005 09:00:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Jari Arkko , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit How about CGA? jak ----- Original Message ----- From: "Tero Kivinen" To: "Francis Dupont" Cc: ; "Jari Arkko" Sent: Tuesday, April 05, 2005 2:34 AM Subject: Re: [Mobike] issues 18, 15, 6 -- return routability > Francis Dupont writes: > > In your previous mail you wrote: > > > > - If the specific IP address can be found in the peer's certificate, > > you can skip the test > > > > => I maintain my proposal to change this into "if the specific IP address > > is already authorized, you can skip the test". > > This is more general (as there can be other ways to authorized an address) > > and more accurate (so it should answer Vijay's concern). > > Agree on Francis on this. We do not need to specify how it is already > authorized. Certificate is one way, typed in to the configuration, or > authorized by the dnssec information are others. > > Most of the cases where the IP-address is already authorized are the > cases where there is multihoming SGW so all IP-addresses are already > known when the machine is installed, but mobike is simply used because > of the multihoming aspect to select which of those IP-addresses are > used. > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Apr 5 20:41:27 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05789 for ; Tue, 5 Apr 2005 20:41:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 94E57FB2A1; Tue, 5 Apr 2005 20:41:24 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 39072FB28F; Tue, 5 Apr 2005 20:41:23 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 53B36FB298; Tue, 5 Apr 2005 20:41:21 -0400 (EDT) Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by machshav.com (Postfix) with SMTP id 43FEDFB284 for ; Tue, 5 Apr 2005 20:41:20 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.81.9 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 00:41:19 -0000 Message-ID: <003001c53a41$570d93c0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <424AB7FF.3080408@piuha.net><16977.7603.98381.2831@fireball.kivinen.iki.fi><42513836.1040308@piuha.net> <16978.17701.446055.840859@fireball.kivinen.iki.fi> Subject: Re: [Mobike] issue 11 -- window size Date: Tue, 5 Apr 2005 17:41:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Tero, Some questions/clarifications.. > > Now if we want to see why we cannot modify the packet between > retranmissions take the next case where we have also shorter temporary > failures or one way connections. > > Connection between A1 and B2 breaks down (A1 address does not work). > Host A notices that he hasn't received anything and starts DPD. > > (A1, B2, 57) DPD -> (dropped) > (A1, B2, 57) DPD -> (dropped) > (A1, B2, 57) DPD -> (dropped) > > Host A notices that he is not getting anything back so he starts > searching for the working address pair: > > (A2, B1, 57) DPD -> > > Host B gets the packet, and replies to it, but the > packet is dropped because of some other reason (one > way path etc). Host B has now calculated HASH(DPD) and > stored it in his incoming window for message id 57, > and also has stored the "DPD reply" to be sent back in > case the message id 57 (HASH(DPD)) is retranmitted. > > (drop) <- (B1, A2, 57R) DPD reply > > Host A retransmits > > (A2, B1, 57) DPD -> > > Host B gets retramission of 57, he verifies that it is > retranmission by checking the HASH(DPD), and because > it matches, he sends stored copy of message id 57R > back, without doing any more processing for the > The receiver needs to do a HASH to detect the change. Today the receiver on receiving the above message, just sends the stored response out as he knows it is a retransmission by just looking at the Message-id. > packet (i.e. he does not run any IKE state machines to > process the packet). > > (drop) <- (B1, A2, 57R) DPD reply > > Host A moves to next address and retransmits > > (A3, B1, 57) DPD -> > > Host B again notices about retranmission, and replies > with his stored packet. > When the host detects the HASH change, he notes down *just* the new addresses so that the response can be sent to the new place. This implies that the retransmitted request from the other end cannot have any changes in the payload (except the IP header). If any other change is in the payload, then the stored response won't work. This might be a bit restrictive depending on how the protocol evolves. So, the main advantage and difference of moving the PATH_TEST message outside the normal window processing is that it can be a totally new message. Hence NAT-D need not be included in every message i guess. Perhaps, there might be something else in the future. Even if we move the PATH_TEST message outside the normal window, we might still have to potentially retransmit the pending message with new address (as described here) and hence the new processing from the receiver is still required. -mohan > <- (B1, A3, 57R) DPD reply > > Now host A gets the packet, and he notices that the previously working > path (A1, B2) does not work anymore, but path (A3, B1) works, so he > updates the SAs to that new address pair > > (A3, B1, 58) N(UPDATE ADDRESSES) -> > > Host B process this new notify, and replies > > <- (B1, A3, 58R) N(UPDATE ADDRESSES reply) > > Host A and Host B again has working SAs. > > So any packets between A and B needs to be processed identically, i.e. > all of them are finding the working address pair. After we have found > out the working address pair, we start the actual movement request > with the specific exchange N(UPDATE ADDRESS). Of course also the > N(UPDATE ADDRESS) packets gets the same processing, i.e. if the > packets do not get through we start searching for the working address > pair. > > Depending on the protocol and contents of N(UPDATE ADDRESS) we need to > decide what we do if the address pair changes during the N(UPDATE > ADDRESS) exchange. I.e. if the addresses are also stored inside the > N(UPDATE ADDRESSES) then we can see that the addresses of outer header > and inside notify does not match, so either there is NAT or the > initiator needed to start address pair search after construction the > packet. In that case B can either reject the update (NAT prevention) > or simply accept it. > > If host A needed to start address pair search, and he didn't like the > result he can start searching new address pair and when he has found > the one he likes, he can redo the N(UPDATE ADDRESS). > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Apr 6 09:03:15 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08747 for ; Wed, 6 Apr 2005 09:03:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 847D3FB291; Wed, 6 Apr 2005 09:03:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED071FB284; Wed, 6 Apr 2005 09:03:06 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C1200FB285; Wed, 6 Apr 2005 09:03:04 -0400 (EDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id CEB68FB283 for ; Wed, 6 Apr 2005 09:03:03 -0400 (EDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2005 09:24:20 -0400 X-IronPort-AV: i="3.92,78,1112587200"; d="scan'208"; a="43351570:sNHT29229200" Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j36D2xjI015375; Wed, 6 Apr 2005 09:03:00 -0400 (EDT) Received: from stephanew2k02 (dhcp-kta1-161-44-192-93.cisco.com [161.44.192.93]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABT13810; Wed, 6 Apr 2005 06:02:58 -0700 (PDT) Message-Id: <200504061302.ABT13810@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Tero Kivinen'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 6 Apr 2005 09:02:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <16977.7603.98381.2831@fireball.kivinen.iki.fi> Thread-Index: AcU5BUjdZZPzPYNPTti/by89IAhySwBoqmsg X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephane@cisco.com 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 Content-Transfer-Encoding: 7bit Hi Tero, > > There is also one other option, i.e. the way my original > protocol proposal did it, i.e. every IKE packet can be used > to test the paths. > If you add also so that every IKE packet also includes the > information needed to do mobility that solves the problem > with window size 1. > > I.e. if mobike needs n payload for its processing, you add > those n payloads to all IKE packets, and then when you are > retransmitting the IKE packet you simply also use that packet > to do path finding, i.e. > change the source and destination addresses but keep the packet same. > The responder will reply to reversed addresses, and after > that IKE exchange both ends know that the path has changed, > and can take appropriate actions (either automatically or > manually by sending another exchange). So, if you have two peers PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the initial connection. Given the following sequence of events - Window Size = 1 A1 --> B1 (CREATE_CHILD_SA request) Interface A1 goes down A1 x-- B1 (CREATE_CHILD_SA response) How would PeerA inform PeerB to start using A2? It is unable to send any IKE pkts at all without exceeding the window size. Or are you relying on PeerB to retransmit the response to A1 a few times, and then automatically switch to A2? Stephane. > > That protocol will work with window size of 1, and it does > not need any packets that are outside of the normal window > processing. If we still do manual actions, then we actually > do not need any special payloads in the IKE packets. > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Apr 6 10:26:09 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16536 for ; Wed, 6 Apr 2005 10:26:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7343BFB2A1; Wed, 6 Apr 2005 10:26:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9816CFB2A1; Wed, 6 Apr 2005 10:26:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 96DB3FB2A2; Wed, 6 Apr 2005 10:25:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id 90D06FB298 for ; Wed, 6 Apr 2005 10:25:58 -0400 (EDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2005 10:25:58 -0400 Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j36EPn1j026232; Wed, 6 Apr 2005 10:25:55 -0400 (EDT) Received: from stephanew2k02 (dhcp-kta1-161-44-192-93.cisco.com [161.44.192.93]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABT15539; Wed, 6 Apr 2005 07:25:48 -0700 (PDT) Message-Id: <200504061425.ABT15539@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: , "'Tero Kivinen'" , "'Jari Arkko'" Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [Mobike] issue 11 -- window size Date: Wed, 6 Apr 2005 10:25:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200504061302.ABT13810@mira-kan-a.cisco.com> Thread-Index: AcU5BUjdZZPzPYNPTti/by89IAhySwBoqmsgAAL8fPA= X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephane@cisco.com 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 Content-Transfer-Encoding: 7bit Sorry, I didn't notice your other post until I sent this. Your follow up post answers my questions. > > Hi Tero, > > > > > There is also one other option, i.e. the way my original protocol > > proposal did it, i.e. every IKE packet can be used to test > the paths. > > If you add also so that every IKE packet also includes the > information > > needed to do mobility that solves the problem with window size 1. > > > > I.e. if mobike needs n payload for its processing, you add those n > > payloads to all IKE packets, and then when you are > retransmitting the > > IKE packet you simply also use that packet to do path finding, i.e. > > change the source and destination addresses but keep the > packet same. > > The responder will reply to reversed addresses, and after that IKE > > exchange both ends know that the path has changed, and can take > > appropriate actions (either automatically or manually by sending > > another exchange). > > So, if you have two peers > > PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the > initial connection. > > Given the following sequence of events > - Window Size = 1 > > A1 --> B1 (CREATE_CHILD_SA request) > Interface A1 goes down > A1 x-- B1 (CREATE_CHILD_SA response) > > How would PeerA inform PeerB to start using A2? It is unable > to send any IKE pkts at all without exceeding the window > size. Or are you relying on PeerB to retransmit the response > to A1 a few times, and then automatically switch to A2? > > Stephane. > > > > > That protocol will work with window size of 1, and it does not need > > any packets that are outside of the normal window processing. If we > > still do manual actions, then we actually do not need any special > > payloads in the IKE packets. > > -- > > kivinen@safenet-inc.com > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Apr 6 10:31:25 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17443 for ; Wed, 6 Apr 2005 10:31:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5BBB3FB2A9; Wed, 6 Apr 2005 10:31:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 075B5FB2A5; Wed, 6 Apr 2005 10:31:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E76D3FB2A6; Wed, 6 Apr 2005 10:31:19 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id 41CB3FB2A4 for ; Wed, 6 Apr 2005 10:31:18 -0400 (EDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2005 10:31:18 -0400 Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j36EVEjI004518; Wed, 6 Apr 2005 10:31:15 -0400 (EDT) Received: from stephanew2k02 (dhcp-kta1-161-44-192-93.cisco.com [161.44.192.93]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABT15697; Wed, 6 Apr 2005 07:31:13 -0700 (PDT) Message-Id: <200504061431.ABT15697@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Tero Kivinen'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 6 Apr 2005 10:31:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <16978.17701.446055.840859@fireball.kivinen.iki.fi> Thread-Index: AcU5tYOeH258evCSTfWqD7RovYc/zAA/x6HA X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephane@cisco.com 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 Content-Transfer-Encoding: 7bit Given the limitation of window sizes, I think this proposal is the best we've discussed so far. Unless someone can find something technically wrong with Tero's proposal, I vote that we proceed with this approach. Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Tero Kivinen > Sent: Tuesday, April 05, 2005 3:58 AM > To: Jari Arkko > Cc: mobike@machshav.com > Subject: Re: [Mobike] issue 11 -- window size > > Jari Arkko writes: > > (So what exactly would "information needed to do mobility and path > > testing" constitute? > > Depends about the answers to issue 3... > > > Presumably, one of the things that we would probably need > is a NAT-D > > payload. > > Not necessarely, in the simplies form it would be simply > outer IP addresses and ports. > > > Would this mean that if we have send request X and later > realize that > > we don't get a response and have to retransmit on another, new > > interface, we resubmit X exactly as-is? > > Yes. The packet must be resubmitted as-is, only IP-addresses > and ports can change. There responder might be taking HASH of > the packet when processing it and store the reply packet, and > when he sees the retransmission he must be able to match the > hash of the previous retransmission to this new one. > > > Or can we add "mobility data", such as NAT-D payload? > > No, we cannot add those. > > > Or perhaps "mobility data" is simply the source address and NAT-D > > payloads are always included...?) > > That would be one option. > > I.e. in the simpliest way to get the protocol working would > be something like this: > > Host A has 3 IP-addresses A1, A2, A3 > Host B has 2 IP-addresses B1, B2 > > IKE SA is currently using (A1, B1) > > Host A starts CREATE_CHILD_SA (message ID 55), and sends packet to B. > > (A1, B1, 55) CREATE_CHILD_SA -> (dropped) > > There is something wrong with the path A1,B1 and > packet is dropped (B1 does not work...) > > Host A retransmits few times: > > (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) > CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA -> (dropped) > > Host A notices he is not getting packets back, he starts > searching for the working address pair: > > (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A2, B1, 55) > CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> > (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B2, > 55) CREATE_CHILD_SA -> Host B gets the packet.. > > Host B will immediately notice that there is something > wrong with the path as the Host A is using different > ports, but he simply continues processing the packet > normally, and replies (with message id 55R) to the > reversed addresses > > <- (B2, A1, 55R) CREATE_CHILD_SA reply > > Host A gets the packet and notices that he has found a working path. > He decides that the he should move the traffic to that new > address pair too, so he sends address update packet to host B: > > (A1, B2, 56) N(UPDATE ADDRESSES) -> > > Host B updates his SAs to new address pair, and > replies. > > <- (B2, A1, 56R) N(UPDATE ADDRESS reply) > > Now if we want to see why we cannot modify the packet between > retranmissions take the next case where we have also shorter > temporary failures or one way connections. > > Connection between A1 and B2 breaks down (A1 address does not work). > Host A notices that he hasn't received anything and starts DPD. > > (A1, B2, 57) DPD -> (dropped) > (A1, B2, 57) DPD -> (dropped) > (A1, B2, 57) DPD -> (dropped) > > Host A notices that he is not getting anything back so he > starts searching for the working address pair: > > (A2, B1, 57) DPD -> > > Host B gets the packet, and replies to it, but the > packet is dropped because of some other reason (one > way path etc). Host B has now calculated HASH(DPD) and > stored it in his incoming window for message id 57, > and also has stored the "DPD reply" to be sent back in > case the message id 57 (HASH(DPD)) is retranmitted. > > (drop) <- (B1, A2, 57R) DPD reply > > Host A retransmits > > (A2, B1, 57) DPD -> > > Host B gets retramission of 57, he verifies that it is > retranmission by checking the HASH(DPD), and because > it matches, he sends stored copy of message id 57R > back, without doing any more processing for the > packet (i.e. he does not run any IKE state machines to > process the packet). > > (drop) <- (B1, A2, 57R) DPD reply > > Host A moves to next address and retransmits > > (A3, B1, 57) DPD -> > > Host B again notices about retranmission, and replies > with his stored packet. > > <- (B1, A3, 57R) DPD reply > > Now host A gets the packet, and he notices that the > previously working path (A1, B2) does not work anymore, but > path (A3, B1) works, so he updates the SAs to that new address pair > > (A3, B1, 58) N(UPDATE ADDRESSES) -> > > Host B process this new notify, and replies > > <- (B1, A3, 58R) N(UPDATE ADDRESSES reply) > > Host A and Host B again has working SAs. > > So any packets between A and B needs to be processed identically, i.e. > all of them are finding the working address pair. After we > have found out the working address pair, we start the actual > movement request with the specific exchange N(UPDATE > ADDRESS). Of course also the N(UPDATE ADDRESS) packets gets > the same processing, i.e. if the packets do not get through > we start searching for the working address pair. > > Depending on the protocol and contents of N(UPDATE ADDRESS) > we need to decide what we do if the address pair changes > during the N(UPDATE > ADDRESS) exchange. I.e. if the addresses are also stored > inside the N(UPDATE ADDRESSES) then we can see that the > addresses of outer header and inside notify does not match, > so either there is NAT or the initiator needed to start > address pair search after construction the packet. In that > case B can either reject the update (NAT prevention) or > simply accept it. > > If host A needed to start address pair search, and he didn't > like the result he can start searching new address pair and > when he has found the one he likes, he can redo the N(UPDATE > ADDRESS). > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Apr 6 13:04:51 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05409 for ; Wed, 6 Apr 2005 13:04:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6C0BBFB2AC; Wed, 6 Apr 2005 13:04:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 99246FB2A5; Wed, 6 Apr 2005 13:04:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9E738FB2A6; Wed, 6 Apr 2005 13:04:41 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id F3172FB2A3 for ; Wed, 6 Apr 2005 13:04:39 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2005 10:04:39 -0700 X-IronPort-AV: i="3.92,80,1112598000"; d="scan'208"; a="246445755:sNHT220760044" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j36H4aZV024940; Wed, 6 Apr 2005 10:04:36 -0700 (PDT) Received: from ghuangx31 (dhcp-128-107-176-80.cisco.com [128.107.176.80]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDS04793; Wed, 6 Apr 2005 10:04:35 -0700 (PDT) Message-Id: <200504061704.BDS04793@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: , "'Tero Kivinen'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 6 Apr 2005 10:04:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcU5tYOeH258evCSTfWqD7RovYc/zAA/x6HAAAVqhLA= X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 In-Reply-To: <200504061431.ABT15697@mira-kan-a.cisco.com> Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit The only hang-up I have is Jari's question below; namely, what exactly constitutes "information needed to do mobility and path testing"? It has to be fairly lightweight since the expectation is that this information would be included in each packet. -g > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Stephane Beaulieu > Sent: Wednesday, April 06, 2005 7:31 AM > To: 'Tero Kivinen'; 'Jari Arkko' > Cc: mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > Given the limitation of window sizes, I think this proposal > is the best > we've discussed so far. > > Unless someone can find something technically wrong with > Tero's proposal, I > vote that we proceed with this approach. > > Stephane. > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com] On Behalf Of Tero Kivinen > > Sent: Tuesday, April 05, 2005 3:58 AM > > To: Jari Arkko > > Cc: mobike@machshav.com > > Subject: Re: [Mobike] issue 11 -- window size > > > > Jari Arkko writes: > > > (So what exactly would "information needed to do mobility > and path > > > testing" constitute? > > > > Depends about the answers to issue 3... > > > > > Presumably, one of the things that we would probably need > > is a NAT-D > > > payload. > > > > Not necessarely, in the simplies form it would be simply > > outer IP addresses and ports. > > > > > Would this mean that if we have send request X and later > > realize that > > > we don't get a response and have to retransmit on another, new > > > interface, we resubmit X exactly as-is? > > > > Yes. The packet must be resubmitted as-is, only IP-addresses > > and ports can change. There responder might be taking HASH of > > the packet when processing it and store the reply packet, and > > when he sees the retransmission he must be able to match the > > hash of the previous retransmission to this new one. > > > > > Or can we add "mobility data", such as NAT-D payload? > > > > No, we cannot add those. > > > > > Or perhaps "mobility data" is simply the source address and NAT-D > > > payloads are always included...?) > > > > That would be one option. > > > > I.e. in the simpliest way to get the protocol working would > > be something like this: > > > > Host A has 3 IP-addresses A1, A2, A3 > > Host B has 2 IP-addresses B1, B2 > > > > IKE SA is currently using (A1, B1) > > > > Host A starts CREATE_CHILD_SA (message ID 55), and sends > packet to B. > > > > (A1, B1, 55) CREATE_CHILD_SA -> (dropped) > > > > There is something wrong with the path A1,B1 and > > packet is dropped (B1 does not work...) > > > > Host A retransmits few times: > > > > (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) > > CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA > -> (dropped) > > > > Host A notices he is not getting packets back, he starts > > searching for the working address pair: > > > > (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A2, B1, 55) > > CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> > > (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B2, > > 55) CREATE_CHILD_SA -> Host B gets the packet.. > > > > Host B will immediately notice that there is something > > wrong with the path as the Host A is using different > > ports, but he simply continues processing the packet > > normally, and replies (with message id 55R) to the > > reversed addresses > > > > <- (B2, A1, 55R) CREATE_CHILD_SA reply > > > > Host A gets the packet and notices that he has found a working path. > > He decides that the he should move the traffic to that new > > address pair too, so he sends address update packet to host B: > > > > (A1, B2, 56) N(UPDATE ADDRESSES) -> > > > > Host B updates his SAs to new address pair, and > > replies. > > > > <- (B2, A1, 56R) N(UPDATE ADDRESS reply) > > > > Now if we want to see why we cannot modify the packet between > > retranmissions take the next case where we have also shorter > > temporary failures or one way connections. > > > > Connection between A1 and B2 breaks down (A1 address does not work). > > Host A notices that he hasn't received anything and starts DPD. > > > > (A1, B2, 57) DPD -> (dropped) > > (A1, B2, 57) DPD -> (dropped) > > (A1, B2, 57) DPD -> (dropped) > > > > Host A notices that he is not getting anything back so he > > starts searching for the working address pair: > > > > (A2, B1, 57) DPD -> > > > > Host B gets the packet, and replies to it, but the > > packet is dropped because of some other reason (one > > way path etc). Host B has now calculated HASH(DPD) and > > stored it in his incoming window for message id 57, > > and also has stored the "DPD reply" to be sent back in > > case the message id 57 (HASH(DPD)) is retranmitted. > > > > (drop) <- (B1, A2, 57R) DPD reply > > > > Host A retransmits > > > > (A2, B1, 57) DPD -> > > > > Host B gets retramission of 57, he verifies that it is > > retranmission by checking the HASH(DPD), and because > > it matches, he sends stored copy of message id 57R > > back, without doing any more processing for the > > packet (i.e. he does not run any IKE state machines to > > process the packet). > > > > (drop) <- (B1, A2, 57R) DPD reply > > > > Host A moves to next address and retransmits > > > > (A3, B1, 57) DPD -> > > > > Host B again notices about retranmission, and replies > > with his stored packet. > > > > <- (B1, A3, 57R) DPD reply > > > > Now host A gets the packet, and he notices that the > > previously working path (A1, B2) does not work anymore, but > > path (A3, B1) works, so he updates the SAs to that new address pair > > > > (A3, B1, 58) N(UPDATE ADDRESSES) -> > > > > Host B process this new notify, and replies > > > > <- (B1, A3, 58R) N(UPDATE ADDRESSES reply) > > > > Host A and Host B again has working SAs. > > > > So any packets between A and B needs to be processed > identically, i.e. > > all of them are finding the working address pair. After we > > have found out the working address pair, we start the actual > > movement request with the specific exchange N(UPDATE > > ADDRESS). Of course also the N(UPDATE ADDRESS) packets gets > > the same processing, i.e. if the packets do not get through > > we start searching for the working address pair. > > > > Depending on the protocol and contents of N(UPDATE ADDRESS) > > we need to decide what we do if the address pair changes > > during the N(UPDATE > > ADDRESS) exchange. I.e. if the addresses are also stored > > inside the N(UPDATE ADDRESSES) then we can see that the > > addresses of outer header and inside notify does not match, > > so either there is NAT or the initiator needed to start > > address pair search after construction the packet. In that > > case B can either reject the update (NAT prevention) or > > simply accept it. > > > > If host A needed to start address pair search, and he didn't > > like the result he can start searching new address pair and > > when he has found the one he likes, he can redo the N(UPDATE > > ADDRESS). > > -- > > kivinen@safenet-inc.com > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Apr 6 17:39:49 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07249 for ; Wed, 6 Apr 2005 17:39:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 46A60FB2A1; Wed, 6 Apr 2005 17:39:46 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 93E7AFB28E; Wed, 6 Apr 2005 17:39:41 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1E034FB28F; Wed, 6 Apr 2005 17:39:40 -0400 (EDT) Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by machshav.com (Postfix) with SMTP id AA7A6FB28A for ; Wed, 6 Apr 2005 17:39:38 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.80.22 with login) by smtp816.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 21:39:36 -0000 Message-ID: <002401c53af1$205751d0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , "'Tero Kivinen'" , "'Jari Arkko'" References: <200504061431.ABT15697@mira-kan-a.cisco.com> Subject: Re: [Mobike] issue 11 -- window size Date: Wed, 6 Apr 2005 14:39:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > Given the limitation of window sizes, I think this proposal is the best > we've discussed so far. > > Unless someone can find something technically wrong with Tero's proposal, I > vote that we proceed with this approach. > There is nothing wrong with Tero's proposal. I like it. But we should at least look at other options. They are : 1) Define a separate window for PATH_TEST messages 2) Do the PATH_TEST message outside the protection IKE SA [MOPO protocol] This gives the flexibility in what PATH_TEST messages contain. Otherwise, you have to include all possible options with all the packets if you ever do MOBIKE for that IKE SA. Once we know the new PATH, rest of it follows as per Tero's mail. Another advantage of keeping PATH_TEST message separate (like in (1) and (2) above), is that we can look for a new PATH even when there is no failure. This might be a useful feature. I don't know whether it is possible with Tero's proposal. -mohan > Stephane. > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com] On Behalf Of Tero Kivinen > > Sent: Tuesday, April 05, 2005 3:58 AM > > To: Jari Arkko > > Cc: mobike@machshav.com > > Subject: Re: [Mobike] issue 11 -- window size > > > > Jari Arkko writes: > > > (So what exactly would "information needed to do mobility and path > > > testing" constitute? > > > > Depends about the answers to issue 3... > > > > > Presumably, one of the things that we would probably need > > is a NAT-D > > > payload. > > > > Not necessarely, in the simplies form it would be simply > > outer IP addresses and ports. > > > > > Would this mean that if we have send request X and later > > realize that > > > we don't get a response and have to retransmit on another, new > > > interface, we resubmit X exactly as-is? > > > > Yes. The packet must be resubmitted as-is, only IP-addresses > > and ports can change. There responder might be taking HASH of > > the packet when processing it and store the reply packet, and > > when he sees the retransmission he must be able to match the > > hash of the previous retransmission to this new one. > > > > > Or can we add "mobility data", such as NAT-D payload? > > > > No, we cannot add those. > > > > > Or perhaps "mobility data" is simply the source address and NAT-D > > > payloads are always included...?) > > > > That would be one option. > > > > I.e. in the simpliest way to get the protocol working would > > be something like this: > > > > Host A has 3 IP-addresses A1, A2, A3 > > Host B has 2 IP-addresses B1, B2 > > > > IKE SA is currently using (A1, B1) > > > > Host A starts CREATE_CHILD_SA (message ID 55), and sends packet to B. > > > > (A1, B1, 55) CREATE_CHILD_SA -> (dropped) > > > > There is something wrong with the path A1,B1 and > > packet is dropped (B1 does not work...) > > > > Host A retransmits few times: > > > > (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) > > CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA -> (dropped) > > > > Host A notices he is not getting packets back, he starts > > searching for the working address pair: > > > > (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A2, B1, 55) > > CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> > > (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B2, > > 55) CREATE_CHILD_SA -> Host B gets the packet.. > > > > Host B will immediately notice that there is something > > wrong with the path as the Host A is using different > > ports, but he simply continues processing the packet > > normally, and replies (with message id 55R) to the > > reversed addresses > > > > <- (B2, A1, 55R) CREATE_CHILD_SA reply > > > > Host A gets the packet and notices that he has found a working path. > > He decides that the he should move the traffic to that new > > address pair too, so he sends address update packet to host B: > > > > (A1, B2, 56) N(UPDATE ADDRESSES) -> > > > > Host B updates his SAs to new address pair, and > > replies. > > > > <- (B2, A1, 56R) N(UPDATE ADDRESS reply) > > > > Now if we want to see why we cannot modify the packet between > > retranmissions take the next case where we have also shorter > > temporary failures or one way connections. > > > > Connection between A1 and B2 breaks down (A1 address does not work). > > Host A notices that he hasn't received anything and starts DPD. > > > > (A1, B2, 57) DPD -> (dropped) > > (A1, B2, 57) DPD -> (dropped) > > (A1, B2, 57) DPD -> (dropped) > > > > Host A notices that he is not getting anything back so he > > starts searching for the working address pair: > > > > (A2, B1, 57) DPD -> > > > > Host B gets the packet, and replies to it, but the > > packet is dropped because of some other reason (one > > way path etc). Host B has now calculated HASH(DPD) and > > stored it in his incoming window for message id 57, > > and also has stored the "DPD reply" to be sent back in > > case the message id 57 (HASH(DPD)) is retranmitted. > > > > (drop) <- (B1, A2, 57R) DPD reply > > > > Host A retransmits > > > > (A2, B1, 57) DPD -> > > > > Host B gets retramission of 57, he verifies that it is > > retranmission by checking the HASH(DPD), and because > > it matches, he sends stored copy of message id 57R > > back, without doing any more processing for the > > packet (i.e. he does not run any IKE state machines to > > process the packet). > > > > (drop) <- (B1, A2, 57R) DPD reply > > > > Host A moves to next address and retransmits > > > > (A3, B1, 57) DPD -> > > > > Host B again notices about retranmission, and replies > > with his stored packet. > > > > <- (B1, A3, 57R) DPD reply > > > > Now host A gets the packet, and he notices that the > > previously working path (A1, B2) does not work anymore, but > > path (A3, B1) works, so he updates the SAs to that new address pair > > > > (A3, B1, 58) N(UPDATE ADDRESSES) -> > > > > Host B process this new notify, and replies > > > > <- (B1, A3, 58R) N(UPDATE ADDRESSES reply) > > > > Host A and Host B again has working SAs. > > > > So any packets between A and B needs to be processed identically, i.e. > > all of them are finding the working address pair. After we > > have found out the working address pair, we start the actual > > movement request with the specific exchange N(UPDATE > > ADDRESS). Of course also the N(UPDATE ADDRESS) packets gets > > the same processing, i.e. if the packets do not get through > > we start searching for the working address pair. > > > > Depending on the protocol and contents of N(UPDATE ADDRESS) > > we need to decide what we do if the address pair changes > > during the N(UPDATE > > ADDRESS) exchange. I.e. if the addresses are also stored > > inside the N(UPDATE ADDRESSES) then we can see that the > > addresses of outer header and inside notify does not match, > > so either there is NAT or the initiator needed to start > > address pair search after construction the packet. In that > > case B can either reject the update (NAT prevention) or > > simply accept it. > > > > If host A needed to start address pair search, and he didn't > > like the result he can start searching new address pair and > > when he has found the one he likes, he can redo the N(UPDATE > > ADDRESS). > > -- > > kivinen@safenet-inc.com > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 06:21:10 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05084 for ; Thu, 7 Apr 2005 06:21:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CB8C9FB2A1; Thu, 7 Apr 2005 06:21:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42AE7FB292; Thu, 7 Apr 2005 06:21:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 27BA2FB29B; Thu, 7 Apr 2005 06:21:00 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 62587FB28A for ; Thu, 7 Apr 2005 06:20:58 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37AKqv5002706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:20:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37AKohv002703; Thu, 7 Apr 2005 13:20:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.2434.30434.819709@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:20:50 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <003001c53a41$570d93c0$6501a8c0@adithya> References: <424AB7FF.3080408@piuha.net> <16977.7603.98381.2831@fireball.kivinen.iki.fi> <42513836.1040308@piuha.net> <16978.17701.446055.840859@fireball.kivinen.iki.fi> <003001c53a41$570d93c0$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 15 min X-Total-Time: 16 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > > Host B gets retramission of 57, he verifies that it is > > retranmission by checking the HASH(DPD), and because > > it matches, he sends stored copy of message id 57R > > back, without doing any more processing for the > > > The receiver needs to do a HASH to detect the change. > Today the receiver on receiving the above message, just > sends the stored response out as he knows it is a retransmission > by just looking at the Message-id. You could do it also based only on the message-ids, but then you do not notice if the other end is acting incorrectly (i.e. the packet changes) etc. You also open reflection attack, as attacker need to simply guess the message-id in use to be able to trig you to send retransmission to forged addresses. If you do the hash, then attacker must have also been seen the original packet too. Calculating and storing the hash is already done by some implementations of IKEv2 (without mobike), just to protect agains those attacks, and as that is how people do it in IKEv2, I used the same explination for the mobike. The protocol does not require to do the hash, it works perfectly without that too, but as there is implementations out there who do calculate the hash (or store the whole packet), you cannot change the packet after you have first time sent it. You can change the IP and port, but you cannot add any payloads etc to it. IP and port are not included in the HASH as the IKEv2 draft says you need to respond even to the retransmission coming from different IP and port. Actually for the authenticated packets, it is enough to store the MAC of the packet... > > packet (i.e. he does not run any IKE state machines to > > process the packet). > > > > (drop) <- (B1, A2, 57R) DPD reply > > > > Host A moves to next address and retransmits > > > > (A3, B1, 57) DPD -> > > > > Host B again notices about retranmission, and replies > > with his stored packet. > > > When the host detects the HASH change, he notes down > *just* the new addresses so that the response can be > sent to the new place. Responder does not detecth HASH change, as it does not change. The HASH is calculated over the IKE packet, and that does (cannot) not change. IP address and port are not covered by the hash. > This implies that the retransmitted > request from the other end cannot have any changes in the payload > (except the IP header). Yes. Retransmission == sending same packet again, so it MUST be identical to the previous one, as it MUST be ignored by responder, but MUST trigger retransmission of reply. > If any other change is in the payload, > then the stored response won't work. Yes. > This might be a bit > restrictive depending on how the protocol evolves. This how it is done in the IKEv2, and I do not think we should be changing it in the MOBIKE. > So, the main advantage and difference of moving the PATH_TEST > message outside the normal window processing is that it can be a > totally new message. That is one option. I just explained another option, which does not require it to be outside the normal window processing. > Hence NAT-D need not be included in every > message i guess. That depends what we do for the NAT-T and MOBIKE. If we want MOBIKE to work with NATs, we need to take IP-addresses from outer IP-header anyways, so we do not necessary need any NAT-D packets. > Perhaps, there might be something else in the > future. Even if we move the PATH_TEST message outside > the normal window, we might still have to potentially retransmit > the pending message with new address (as described here) > and hence the new processing from the receiver is still required. Yes, we might need the same processing anyways, so my suggestion was that one option could be to simply use it always, thus there would not be need for the separate PATH_TEST message. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 06:32:02 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05870 for ; Thu, 7 Apr 2005 06:32:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F40A5FB2A5; Thu, 7 Apr 2005 06:32:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 880A3FB29B; Thu, 7 Apr 2005 06:31:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5624FFB2A1; Thu, 7 Apr 2005 06:31:55 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E11D4FB292 for ; Thu, 7 Apr 2005 06:31:53 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37ATbiY002825 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:29:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37ATaKx002822; Thu, 7 Apr 2005 13:29:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.2960.25304.155287@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:29:36 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: <200504061302.ABT13810@mira-kan-a.cisco.com> References: <16977.7603.98381.2831@fireball.kivinen.iki.fi> <200504061302.ABT13810@mira-kan-a.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: mobike@machshav.com, "'Jari Arkko'" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Stephane Beaulieu writes: > So, if you have two peers > > PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the initial > connection. > > Given the following sequence of events > - Window Size = 1 > > A1 --> B1 (CREATE_CHILD_SA request) > Interface A1 goes down > A1 x-- B1 (CREATE_CHILD_SA response) > > How would PeerA inform PeerB to start using A2? It is unable to send any > IKE pkts at all without exceeding the window size. Or are you relying on > PeerB to retransmit the response to A1 a few times, and then automatically > switch to A2? As only party doing retranmissions in the IKE is the initiator, the PeerA would continue retransmitting the CREATE_CHILD_SA to the PeerB as long as it does not get reply back. After a while after it haven't received reply (or immediately when it detects that A1 goes down) initiator (peerA) should start path finding, i.e it should send next retranmission of packet: A2 --> B1 (CREATE_CHILD_SA request) PeerB would retransmit its reply to new IP-address A2 <-- B1 (CREATE_CHILD_SA response) And they have now finished the exchange, and continue processing. Now next thing what PeerA would like to do, is probably update his addresses to the PeerB, if A1 really went away, or at least move existing IPsec SA traffic to use address pair of A2, B1 which is known to work now (this update could also be automatic). There are some other options how this protocol could be written, but this is just one example how the protocol could be written (i.e. mostly to give proof that we do not necessarely need PATH_TEST exchange which is outside the window, or we do not necessarely need window size > 1). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 06:34:26 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06035 for ; Thu, 7 Apr 2005 06:34:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F08D2FB2A9; Thu, 7 Apr 2005 06:34:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B23D6FB2A1; Thu, 7 Apr 2005 06:34:25 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4E80BFB2A7; Thu, 7 Apr 2005 06:34:24 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 4B4D0FB29B for ; Thu, 7 Apr 2005 06:34:23 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37AWAtu002980 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:32:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37AWACd002977; Thu, 7 Apr 2005 13:32:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.3114.111377.56481@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:32:10 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: <200504061425.ABT15539@mira-kan-a.cisco.com> References: <200504061302.ABT13810@mira-kan-a.cisco.com> <200504061425.ABT15539@mira-kan-a.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: mobike@machshav.com, "'Jari Arkko'" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Stephane Beaulieu writes: > Sorry, I didn't notice your other post until I sent this. Your follow up > post answers my questions. Good. I hope my answer you your mail still clarifies things more. I was planning to put the example in the first email already, but I had some other interruptions, and noticed that I do not have time to do at that point, so I sent the first description then and then came back later to write the example of protocol. Perhaps I should have waited with the first post until I had the example done... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 07:01:10 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08120 for ; Thu, 7 Apr 2005 07:01:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3C854FB2A9; Thu, 7 Apr 2005 07:01:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EA34DFB2A5; Thu, 7 Apr 2005 07:01:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B7620FB2A7; Thu, 7 Apr 2005 07:01:06 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 86158FB2A1 for ; Thu, 7 Apr 2005 07:01:05 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37Axtj3003144 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 13:59:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37AxsEN003141; Thu, 7 Apr 2005 13:59:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.4778.858267.845945@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 13:59:54 +0300 From: Tero Kivinen To: "Geoffrey Huang" Subject: RE: [Mobike] issue 11 -- window size In-Reply-To: <200504061704.BDS04793@mira-sjc5-b.cisco.com> References: <200504061431.ABT15697@mira-kan-a.cisco.com> <200504061704.BDS04793@mira-sjc5-b.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: mobike@machshav.com, "'Jari Arkko'" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Geoffrey Huang writes: > The only hang-up I have is Jari's question below; namely, what exactly > constitutes "information needed to do mobility > and path testing"? It has to be fairly lightweight since the expectation is > that this information would be included in each packet. Depending on the NAT issue, it could even be simply the IP-addresses already there in the outer header. Especially if we do not do automatic updates based on the path tests, but after we detect from the path test that the IP-addresses pair has changed, we do actual notification of movement as a separate exchange (which still gets the same processing, so the packets will get trough and exchange ends even when change happens again during that exchange). Perhaps the largest thing that could be there would be list of IP-addresses peer has, but I am not sure we need that. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 07:06:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08619 for ; Thu, 7 Apr 2005 07:06:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EAE1EFB2AF; Thu, 7 Apr 2005 07:06:38 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9F795FB2A7; Thu, 7 Apr 2005 07:06:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1C7D5FB2A8; Thu, 7 Apr 2005 07:06:36 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7F146FB286 for ; Thu, 7 Apr 2005 07:06:34 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j37B6SFP003278 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 14:06:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j37B6SHS003275; Thu, 7 Apr 2005 14:06:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16981.5172.54140.66265@fireball.kivinen.iki.fi> Date: Thu, 7 Apr 2005 14:06:28 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <002401c53af1$205751d0$6501a8c0@adithya> References: <200504061431.ABT15697@mira-kan-a.cisco.com> <002401c53af1$205751d0$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: mobike@machshav.com, "'Jari Arkko'" X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > 1) Define a separate window for PATH_TEST messages Hmm... I am not sure what you mean by that. Can you exlain it more. > 2) Do the PATH_TEST message outside the protection IKE SA [MOPO > protocol] Yes, that is another option. I just send my proposal to offer another option for that proposal :-) > Another advantage of keeping PATH_TEST message separate (like in (1) > and (2) above), is that we can look for a new PATH even when there > is no failure. This might be a useful feature. I don't know whether > it is possible with Tero's proposal. My proposal didn't give out any exact details of the path test process, but as it will be done for all packets, you can use DPD packets to do it, for example you could make the DPD path test checks so that they will always start the different address pair, so that finding of list of working address pairs happens on the background during the DPD tests. When the actual failure happens the path test process could use that information too. On the other hand, I do not think there is that much value for the old information, as clearly something has changed in the paths as the current (previously working address pair) has stopped working, thus all the old information we have might be obsolete now anyways. I think we need to separate the actual process how to send the PATH_TEST packets (i.e. path test process, what IP address try, and in which order, what information to use, what timers to use etc), from the packet format used for the PATH_TEST packets (i.e. separate PATH_TEST exchange, or any IKE packet). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 19:18:46 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19622 for ; Thu, 7 Apr 2005 19:18:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9498FFB2A1; Thu, 7 Apr 2005 19:18:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AA552FB28A; Thu, 7 Apr 2005 19:18:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1664EFB28E; Thu, 7 Apr 2005 19:18:38 -0400 (EDT) Received: from smtp817.mail.sc5.yahoo.com (smtp817.mail.sc5.yahoo.com [66.163.170.3]) by machshav.com (Postfix) with SMTP id 01C4DFB286 for ; Thu, 7 Apr 2005 19:18:36 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.55.60 with login) by smtp817.mail.sc5.yahoo.com with SMTP; 7 Apr 2005 23:18:35 -0000 Message-ID: <001c01c53bc8$1e23d550$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <424AB7FF.3080408@piuha.net><16977.7603.98381.2831@fireball.kivinen.iki.fi><42513836.1040308@piuha.net><16978.17701.446055.840859@fireball.kivinen.iki.fi><003001c53a41$570d93c0$6501a8c0@adithya> <16981.2434.30434.819709@fireball.kivinen.iki.fi> Subject: Re: [Mobike] issue 11 -- window size Date: Thu, 7 Apr 2005 16:18:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > > > > > The receiver needs to do a HASH to detect the change. > > Today the receiver on receiving the above message, just > > sends the stored response out as he knows it is a retransmission > > by just looking at the Message-id. > > You could do it also based only on the message-ids, but then you do > not notice if the other end is acting incorrectly (i.e. the packet > changes) etc. You also open reflection attack, as attacker need to > simply guess the message-id in use to be able to trig you to send > retransmission to forged addresses. If you do the hash, then attacker > must have also been seen the original packet too. Calculating and > storing the hash is already done by some implementations of IKEv2 > (without mobike), just to protect agains those attacks, and as that is > how people do it in IKEv2, I used the same explination for the mobike. > Ok, thanks for the clarification. > The protocol does not require to do the hash, it works perfectly > without that too, but as there is implementations out there who do > calculate the hash (or store the whole packet), you cannot change the > packet after you have first time sent it. You can change the IP and This is an important point. The IKEv2 draft says: An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) the number of previous responses equal to its declared window size in case its response was lost and the initiator requests its retransmission by retransmitting the request. It is hard to regenerate an exact copy without storing and hence implementations store the packet i guess. We want to honor that here i guess. Otherwise, the retransmitted message can change from the first time. > > > Hence NAT-D need not be included in every > > message i guess. > > That depends what we do for the NAT-T and MOBIKE. If we want MOBIKE to > work with NATs, we need to take IP-addresses from outer IP-header > anyways, so we do not necessary need any NAT-D packets. > It depends on what you mean by working with NATs. If i move behind a NAT (where there was no NAT previously), and want to detect NAT, Prevent NAT etc. you want MOBIKE to work in these cases. In a previous discussion on this mailing list, at least some of us felt that it should work with NAT and taking addresses from the IP header should not be the only way to do it. > > Perhaps, there might be something else in the > > future. Even if we move the PATH_TEST message outside > > the normal window, we might still have to potentially retransmit > > the pending message with new address (as described here) > > and hence the new processing from the receiver is still required. > > Yes, we might need the same processing anyways, so my suggestion was > that one option could be to simply use it always, thus there would not > be need for the separate PATH_TEST message. Okay. -mohan > -- > kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Apr 7 19:42:25 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20629 for ; Thu, 7 Apr 2005 19:42:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 78553FB28E; Thu, 7 Apr 2005 19:42:23 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BEC91FB286; Thu, 7 Apr 2005 19:42:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D01BFB28A; Thu, 7 Apr 2005 19:42:20 -0400 (EDT) Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by machshav.com (Postfix) with SMTP id B51DCFB262 for ; Thu, 7 Apr 2005 19:42:19 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.55.60 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 7 Apr 2005 23:42:19 -0000 Message-ID: <005801c53bcb$6edf8770$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <200504061431.ABT15697@mira-kan-a.cisco.com><002401c53af1$205751d0$6501a8c0@adithya> <16981.5172.54140.66265@fireball.kivinen.iki.fi> Subject: Re: [Mobike] issue 11 -- window size Date: Thu, 7 Apr 2005 16:42:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: "'Jari Arkko'" , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > > 1) Define a separate window for PATH_TEST messages > > Hmm... I am not sure what you mean by that. Can you exlain it more. > This is one way to do it, but not the only way to do it. Define a new flag value indicating "Mobility messages". The message-id carried in the IKE header has its own window space. Thus not constrained by the current window used by "normal IKEv2 messages". This can be used by PATH_TEST in the same way as you described. Message-ids can be used to match request to response and hence you know which path works. Would that work ? > > 2) Do the PATH_TEST message outside the protection IKE SA [MOPO > > protocol] > > Yes, that is another option. I just send my proposal to offer another > option for that proposal :-) > I am not sure i understood this. Are you saying that your PATH_TEST option could be used by MOPO or something else ? > > Another advantage of keeping PATH_TEST message separate (like in (1) > > and (2) above), is that we can look for a new PATH even when there > > is no failure. This might be a useful feature. I don't know whether > > it is possible with Tero's proposal. > > My proposal didn't give out any exact details of the path test > process, but as it will be done for all packets, you can use DPD > packets to do it, for example you could make the DPD path test checks > so that they will always start the different address pair, so that > finding of list of working address pairs happens on the background > during the DPD tests. When the actual failure happens the path test > process could use that information too. > Ok, the other end knows that it is "DPD path" test, so just reply and don't affect the SAs. > On the other hand, I do not think there is that much value for the old > information, as clearly something has changed in the paths as the > current (previously working address pair) has stopped working, thus > all the old information we have might be obsolete now anyways. > Agreed that it is a potential problem. But perhaps it can be used as a hint to start trying from the address pair that was known to work sometime back. Implementations can be smart enough to age the information and periodically refresh. I think providing such a mechnaism is useful. > I think we need to separate the actual process how to send the > PATH_TEST packets (i.e. path test process, what IP address try, and in > which order, what information to use, what timers to use etc), from > the packet format used for the PATH_TEST packets (i.e. separate > PATH_TEST exchange, or any IKE packet). Agreed. The former is more implementation dependent and should MOBIKE really say anything at all ? Also, note that which end does the PATH_TEST has not been resolved yet i guess. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Apr 8 03:42:33 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14834 for ; Fri, 8 Apr 2005 03:42:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BF57FFB292; Fri, 8 Apr 2005 03:42:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DE964FB28A; Fri, 8 Apr 2005 03:42:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3702EFB28E; Fri, 8 Apr 2005 03:42:25 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E56A4FB286 for ; Fri, 8 Apr 2005 03:42:23 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j387gK4D013729 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Apr 2005 10:42:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j387gJq7013726; Fri, 8 Apr 2005 10:42:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16982.13787.382550.756541@fireball.kivinen.iki.fi> Date: Fri, 8 Apr 2005 10:42:19 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <001c01c53bc8$1e23d550$6501a8c0@adithya> References: <424AB7FF.3080408@piuha.net> <16977.7603.98381.2831@fireball.kivinen.iki.fi> <42513836.1040308@piuha.net> <16978.17701.446055.840859@fireball.kivinen.iki.fi> <003001c53a41$570d93c0$6501a8c0@adithya> <16981.2434.30434.819709@fireball.kivinen.iki.fi> <001c01c53bc8$1e23d550$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > This is an important point. The IKEv2 draft says: > > An IKE endpoint MUST keep a copy of (or be > able to regenerate exactly) the number of previous responses equal to > its declared window size in case its response was lost and the > initiator requests its retransmission by retransmitting the request. This is different case. This is for the responses send based on the request. > It is hard to regenerate an exact copy without storing and hence > implementations store the packet i guess. We want to honor that here > i guess. Otherwise, the retransmitted message can change from the > first time. There are two cases there. 1) How to check that the request is same. 2) How to retransmit the response if retransmission of request is found. For 1) simply checking the message ID would be enough, but as people do consider that somewhat bad to retransmit packet so easily, they will store the hash of the request packet and use that to verify that the retransmission is really a retransmission, not some random garbage from net. For 2) implementations need to store the response packet they are sending back, or at least store enough information that they can regenerate the previous packet exactly. > It depends on what you mean by working with NATs. If i move behind a NAT > (where there was no NAT previously), and want to detect NAT, Prevent NAT etc. > you want MOBIKE to work in these cases. > > In a previous discussion on this mailing list, at least some of us > felt that it should work with NAT and taking addresses from the IP > header should not be the only way to do it. If you want it to work with NATs, your only option is to take addresses from IP header. You can store information inside the packet also to do detection of NAT, but you cannot really use that information inside the packet for anything else than NAT detection. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Apr 8 03:52:48 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15437 for ; Fri, 8 Apr 2005 03:52:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C973BFB2A4; Fri, 8 Apr 2005 03:52:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 13FBAFB2A2; Fri, 8 Apr 2005 03:52:46 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 40547FB2A3; Fri, 8 Apr 2005 03:52:45 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 66295FB28E for ; Fri, 8 Apr 2005 03:52:42 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j387qcNT013783 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Apr 2005 10:52:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j387qbkx013780; Fri, 8 Apr 2005 10:52:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16982.14405.606701.19386@fireball.kivinen.iki.fi> Date: Fri, 8 Apr 2005 10:52:37 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <005801c53bcb$6edf8770$6501a8c0@adithya> References: <200504061431.ABT15697@mira-kan-a.cisco.com> <002401c53af1$205751d0$6501a8c0@adithya> <16981.5172.54140.66265@fireball.kivinen.iki.fi> <005801c53bcb$6edf8770$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 9 min X-Total-Time: 9 min Cc: "'Jari Arkko'" , mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > > > 1) Define a separate window for PATH_TEST messages > > > > Hmm... I am not sure what you mean by that. Can you exlain it more. > > > This is one way to do it, but not the only way to do it. Define a new flag > value indicating "Mobility messages". The message-id carried in the > IKE header has its own window space. Thus not constrained by > the current window used by "normal IKEv2 messages". This can > be used by PATH_TEST in the same way as you described. > Message-ids can be used to match request to response and hence > you know which path works. Would that work ? So to create overlay IKE SA message IDs using the same SPIs, but separate flag to specify that you these messages are not constrained by the window of normal message IDs? Yes, that would also work. > > > 2) Do the PATH_TEST message outside the protection IKE SA [MOPO > > > protocol] > > > > Yes, that is another option. I just send my proposal to offer another > > option for that proposal :-) > > > I am not sure i understood this. Are you saying that your PATH_TEST option > could be used by MOPO or something else ? Most of those options, could be used by most of the protocols. There is nothing that exactly ties in the PATH_TEST message format and the actual mobike protocol. Thats why we are now trying to decide which one to use. > Ok, the other end knows that it is "DPD path" test, so just reply > and don't affect the SAs. Yes. Of course it need to reply to the DPD packets all the time, and I think we do not want to tie in path test and moving of SAs, i.e. in my example I used separate information exchange sending notification which actually made the changes to the SA addresses. I.e. the change operation is explicitly done, instead of implictly happening after we notice that path changed. IKEv2 NAT-T does the implicit path changing, i.e. every time the address changes then addresses of SAs are updated. I think mobike should do explicit updating, but that is one option we need to decide too. > > I think we need to separate the actual process how to send the > > PATH_TEST packets (i.e. path test process, what IP address try, and in > > which order, what information to use, what timers to use etc), from > > the packet format used for the PATH_TEST packets (i.e. separate > > PATH_TEST exchange, or any IKE packet). > > Agreed. The former is more implementation dependent and should > MOBIKE really say anything at all ? I think we need to give at least some implementation hints or description how it could be done, so we have some kind of common way of doing it. Exact details what information is used etc can be left to implementations, as different implementations have different hints available for them. > Also, note that which end does the PATH_TEST has not been resolved > yet i guess. That mostly depends on other questions, like if we do initiator decides then he is the one doing path tests etc... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Apr 8 20:00:29 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23340 for ; Fri, 8 Apr 2005 20:00:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 83558FB282; Fri, 8 Apr 2005 20:00:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2FBB7FB280; Fri, 8 Apr 2005 20:00:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7C949FB281; Fri, 8 Apr 2005 20:00:25 -0400 (EDT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by machshav.com (Postfix) with SMTP id BD8D3FB27F for ; Fri, 8 Apr 2005 20:00:24 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.214.170 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 9 Apr 2005 00:00:18 -0000 Message-ID: <018f01c53c97$1d23a250$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <424AB7FF.3080408@piuha.net><16977.7603.98381.2831@fireball.kivinen.iki.fi><42513836.1040308@piuha.net><16978.17701.446055.840859@fireball.kivinen.iki.fi><003001c53a41$570d93c0$6501a8c0@adithya><16981.2434.30434.819709@fireball.kivinen.iki.fi><001c01c53bc8$1e23d550$6501a8c0@adithya> <16982.13787.382550.756541@fireball.kivinen.iki.fi> Subject: Re: [Mobike] issue 11 -- window size Date: Fri, 8 Apr 2005 17:00:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > > > It is hard to regenerate an exact copy without storing and hence > > implementations store the packet i guess. We want to honor that here > > i guess. Otherwise, the retransmitted message can change from the > > first time. > > There are two cases there. > > 1) How to check that the request is same. > 2) How to retransmit the response if retransmission of request is > found. > > For 1) simply checking the message ID would be enough, but as people > do consider that somewhat bad to retransmit packet so easily, they > will store the hash of the request packet and use that to verify that > the retransmission is really a retransmission, not some random garbage > from net. > Sorry to beat up on the same point again.. The reason the retransmitted request cannot change (except IP headers) is because it would break implementations that store the hash of the request to detect retransmissions. Is that right ? > For 2) implementations need to store the response packet they are > sending back, or at least store enough information that they can > regenerate the previous packet exactly. > > > It depends on what you mean by working with NATs. If i move behind a NAT > > (where there was no NAT previously), and want to detect NAT, Prevent NAT etc. > > you want MOBIKE to work in these cases. > > > > In a previous discussion on this mailing list, at least some of us > > felt that it should work with NAT and taking addresses from the IP > > header should not be the only way to do it. > > If you want it to work with NATs, your only option is to take > addresses from IP header. You can store information inside the packet > also to do detection of NAT, but you cannot really use that > information inside the packet for anything else than NAT detection. > I was talking about an "option" for detecting the presence of NATs securely where you don't accept blindly what you see in IP headers but also check the payload (if address is present in the MOBIKE NAT-D payload) to see if the address on the IP header is same. -mohan > -- > kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Apr 9 10:12:30 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10593 for ; Sat, 9 Apr 2005 10:12:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6FE4DFB29D; Sat, 9 Apr 2005 10:12:28 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5E564FB280; Sat, 9 Apr 2005 10:12:25 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E968EFB281; Sat, 9 Apr 2005 10:12:23 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7C2BDFB27F for ; Sat, 9 Apr 2005 10:12:22 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j39ECGcY029285 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 9 Apr 2005 17:12:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j39ECFw7029282; Sat, 9 Apr 2005 17:12:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16983.58047.278167.446495@fireball.kivinen.iki.fi> Date: Sat, 9 Apr 2005 17:12:15 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <018f01c53c97$1d23a250$6501a8c0@adithya> References: <424AB7FF.3080408@piuha.net> <16977.7603.98381.2831@fireball.kivinen.iki.fi> <42513836.1040308@piuha.net> <16978.17701.446055.840859@fireball.kivinen.iki.fi> <003001c53a41$570d93c0$6501a8c0@adithya> <16981.2434.30434.819709@fireball.kivinen.iki.fi> <001c01c53bc8$1e23d550$6501a8c0@adithya> <16982.13787.382550.756541@fireball.kivinen.iki.fi> <018f01c53c97$1d23a250$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > Sorry to beat up on the same point again.. The reason the retransmitted > request cannot change (except IP headers) is because it would break > implementations that store the hash of the request to detect retransmissions. > Is that right ? Yes. > I was talking about an "option" for detecting the presence of NATs > securely where you don't accept blindly what you see in IP headers but also There is no way to detect NATs securely, unless you have co-operation of NAT. NAT is an attacker on the way from initiator to the responder who changes the IP-addresses. There is no way to distinguish that from the real attacker, without changing NATs. > check the payload (if address is present in the MOBIKE NAT-D > payload) to see if the address on the IP header is same. It is easy to securely detect that there is NO NAT between, and that does not require changing of packets for retransmission. We simply need to keep the other end up to date which addresses we might be using, and if the address is one of those, then there is no NAT between. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Apr 10 15:11:37 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12027 for ; Sun, 10 Apr 2005 15:11:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DCBCFFB2A5; Sun, 10 Apr 2005 15:11:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7E4F7FB29D; Sun, 10 Apr 2005 15:11:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B9801FB29D; Sun, 10 Apr 2005 15:11:26 -0400 (EDT) Received: from web80601.mail.yahoo.com (web80601.mail.yahoo.com [66.218.79.90]) by machshav.com (Postfix) with SMTP id 0F402FB240 for ; Sun, 10 Apr 2005 15:11:26 -0400 (EDT) Message-ID: <20050410191125.69206.qmail@web80601.mail.yahoo.com> Received: from [64.172.58.48] by web80601.mail.yahoo.com via HTTP; Sun, 10 Apr 2005 12:11:25 PDT Date: Sun, 10 Apr 2005 12:11:25 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [Mobike] issue 11 -- window size To: Tero Kivinen In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 > > > I was talking about an "option" for detecting the > presence of NATs > > securely where you don't accept blindly what you > see in IP headers but also > > There is no way to detect NATs securely, unless you > have co-operation > of NAT. NAT is an attacker on the way from initiator > to the responder > who changes the IP-addresses. There is no way to > distinguish that from > the real attacker, without changing NATs. > Agreed. I wanted to say something and wrote something different. But if there are other protocols (outside of MOBIKE) used to detect NAT and also learn the bindings, can we use MOBIKE to carry that information ? > > check the payload (if address is present in the > MOBIKE NAT-D > > payload) to see if the address on the IP header > is same. > > It is easy to securely detect that there is NO NAT > between, and that > does not require changing of packets for > retransmission. We simply > need to keep the other end up to date which > addresses we might be > using, and if the address is one of those, then > there is no NAT > between. > I am not sure i follow this. If i am moving and acquiring a new address, you have to tell the other end about the new address securely for detecting "NO NAT" securely. This implies that the packets have to change in retransmission. You could not have told about the new address beforehand. So, if we want to prevent NAT from appearing in the path (NAT_PREVENTION), you still need to add the newly acquired address to the payload. Now if there is some other protocol outside of MOBIKE which can tell us what the NAT binding is (e.g. MIDCOM), i can use the same mechanism (as in NAT_PREVENTION above) to tell the other end about what address is allowed to appear in the IP header. The attacker cannot modify the IP header anymore. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Apr 11 07:27:08 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03423 for ; Mon, 11 Apr 2005 07:27:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7E5B8FB282; Mon, 11 Apr 2005 07:27:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 096A8FB27F; Mon, 11 Apr 2005 07:27:03 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 17B08FB280; Mon, 11 Apr 2005 07:27:01 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id B3084FB27D for ; Mon, 11 Apr 2005 07:26:59 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j3BBQjOd022610 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 14:26:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j3BBQh5u022607; Mon, 11 Apr 2005 14:26:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.24307.271771.674074@fireball.kivinen.iki.fi> Date: Mon, 11 Apr 2005 14:26:43 +0300 From: Tero Kivinen To: Mohan Parthasarathy Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <20050410191125.69206.qmail@web80601.mail.yahoo.com> References: <20050410191125.69206.qmail@web80601.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 88 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > I am not sure i follow this. If i am moving and > acquiring a new address, you have to tell the other > end about the new address securely for detecting "NO > NAT" securely. This implies that the packets have to > change in retransmission. You could not have told > about the new address beforehand. So, if we want to > prevent NAT from appearing in the path > (NAT_PREVENTION), you still need to add the newly > acquired address to the payload. If you send separate notification to the other end when ever you address changes, the responder can check if the source address of the packet is from that list, and if so it knows there is no NAT. If the address is not in the list, there is now two possible things: 1) There is NAT between 2) The other end got new address after it started this exchange, thus it needed to retransmit the packet using this new source address without telling you. If this is the case, then immediately after you answer to this the other end will send and address list update message which should include this address. So temporarely it seems there is NAT between, but as soon as the window is cleared then there will be new packet that will update the address lists so that they have all new source addresses. I.e. the process flow would be: CREATE_SHILD_SA -> (lost) CREATE_SHILD_SA retransmit (with other IPs) -> (lost) getting new IP address A3 CREATE_SHILD_SA retransmit (with A3) -> (gets through) <- CREATE_SHILD_SA reply (to A3, notices that A3 is not in list of IPs) N(UPDATE LIST) (adds A3 to list) -> <- ACK (notices now that A3 is again on list, so no NAT) N(MOVE TRAFFIC) -> (lost) N(MOVE TRAFFIC) (with other IPs) -> (lost) getting new IP address A4 N(MOVE TRAFFIC) (with A4) -> (gets through) <- N(ERROR-NAT-DETECTED) (returns error as A4 is not in the list, and nat prevention set) N(UPDATE LIST), N(MOVE TRAFFIC) (updates list to have A4, moves traffic) -> <- ACK (adds A4 to list, moves traffic to new address). > Now if there is some other protocol outside of MOBIKE > which can tell us what the NAT binding is (e.g. > MIDCOM), i can use the same mechanism (as in > NAT_PREVENTION above) to tell the other end about > what address is allowed to appear in the IP header. > The attacker cannot modify the IP header anymore. Yes. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Apr 11 14:22:52 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06360 for ; Mon, 11 Apr 2005 14:22:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BDF25FB281; Mon, 11 Apr 2005 14:22:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41AA4FB27D; Mon, 11 Apr 2005 14:22:49 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2203CFB280; Mon, 11 Apr 2005 14:22:47 -0400 (EDT) Received: from web80605.mail.yahoo.com (web80605.mail.yahoo.com [66.218.79.94]) by machshav.com (Postfix) with SMTP id 4DA5BFB27C for ; Mon, 11 Apr 2005 14:22:46 -0400 (EDT) Message-ID: <20050411182245.2991.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.2] by web80605.mail.yahoo.com via HTTP; Mon, 11 Apr 2005 11:22:45 PDT Date: Mon, 11 Apr 2005 11:22:45 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [Mobike] issue 11 -- window size To: Tero Kivinen In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Tero, > > I am not sure i follow this. If i am moving and > > acquiring a new address, you have to tell the > other > > end about the new address securely for detecting > "NO > > NAT" securely. This implies that the packets have > to > > change in retransmission. You could not have told > > about the new address beforehand. So, if we want > to > > prevent NAT from appearing in the path > > (NAT_PREVENTION), you still need to add the newly > > acquired address to the payload. > > If you send separate notification to the other end > when ever you > address changes, the responder can check if the > source address of the > packet is from that list, and if so it knows there > is no NAT. > > If the address is not in the list, there is now two > possible things: > > 1) There is NAT between > 2) The other end got new address after it started > this exchange, thus > it needed to retransmit the packet using this new > source address > without telling you. If this is the case, then > immediately after you > answer to this the other end will send and address > list update message > which should include this address. > The address list update message may not be the next message as there might be others in the window if window size is > 1. So, the peer has to wait for a max of windows worth of messages before it would see the update with the new address. This could be long if we have a few addresses to try. > So temporarely it seems there is NAT between, but as > soon as the > window is cleared then there will be new packet that > will update the > address lists so that they have all new source > addresses. > Agreed. Perhaps if we can send the UPDATE message also outside the normal window, the peer can know earlier. Not sure whether it is a big advantage or not. > I.e. the process flow would be: > > CREATE_SHILD_SA -> (lost) > > CREATE_SHILD_SA retransmit (with other IPs) -> > (lost) > > getting new IP address A3 > > CREATE_SHILD_SA retransmit (with A3) -> (gets > through) > > <- CREATE_SHILD_SA reply (to A3, notices that A3 is > not in list of IPs) > > N(UPDATE LIST) (adds A3 to list) -> > <- ACK (notices now that A3 is again on list, so no > NAT) > > N(MOVE TRAFFIC) -> (lost) > > N(MOVE TRAFFIC) (with other IPs) -> (lost) > > getting new IP address A4 > > N(MOVE TRAFFIC) (with A4) -> (gets through) > > <- N(ERROR-NAT-DETECTED) (returns error as A4 is not > in the list, and > nat prevention set) > > N(UPDATE LIST), N(MOVE TRAFFIC) (updates list to > have A4, moves traffic) -> > > <- ACK (adds A4 to list, moves traffic to new > address). > Okay, you allow "NAT/attacker" temporarily till the update message is sent so that you don't have to modify the retransmitted packet. Can the on-path attacker (assume that the attacker needs to know the full message and not just the message-ids), can generate lot of packets with bogus address/es and can cause some meaningful attack ? Anyway, it is required by IKEv2 today, so we don't worsen the security any more than what is there today. Will it improve the current situation if we can update the other end about the new address before the window clears up ? -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Apr 12 04:28:08 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08212 for ; Tue, 12 Apr 2005 04:28:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4E87DFB27D; Tue, 12 Apr 2005 04:28:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DAD41FB262; Tue, 12 Apr 2005 04:28:00 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E6C6FFB277; Tue, 12 Apr 2005 04:27:58 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 15343FB24A for ; Tue, 12 Apr 2005 04:27:57 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j3C8Riq2005044 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Apr 2005 11:27:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j3C8Rhwe005041; Tue, 12 Apr 2005 11:27:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16987.34431.220420.990813@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2005 11:27:43 +0300 From: Tero Kivinen To: Mohan Parthasarathy Subject: Re: [Mobike] issue 11 -- window size In-Reply-To: <20050411182245.2991.qmail@web80605.mail.yahoo.com> References: <20050411182245.2991.qmail@web80605.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 15 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > The address list update message may not be the next > message as there might be others in the window if > window size is > 1. So, the peer has to wait for a max > of windows worth of messages before it would see the > update with the new address. This could be long if we > have a few addresses to try. I do not consider this a problem. When the first message of the window is ACKed then the other end can send the notification packets to inform about the situation. Only thing this will do is to delay the updating of the address list for some fraction of seconds while this is busy processing messages in window. In normal case there will not be any messages (or there will be one DPD message) in the window. > Agreed. Perhaps if we can send the UPDATE message > also outside the normal window, the peer can know > earlier. Not sure whether it is a big advantage or > not. The peer could get the information a bit earlier, but I do not really consider NAT prevention that important feature that it needs to be communicated immediately to the other end, I think we can wait for a round trip for that. And if we do not use NAT prevention we do not even need the update packets, we only need move traffic style packets, but for those we need to know the working address pair anyways, so we want to finish the address pair discovery before we send those anyways. > Okay, you allow "NAT/attacker" temporarily till the > update message is sent so that you don't have to > modify the retransmitted packet. No, I do not allow it (if the NAT prevention is turned on), I tell the other end that there is NAT/attacker, your request was rejected, i.e. we do allow replying to packets, but we do not allow it to be there for IPsec traffic. > Can the on-path > attacker (assume that the attacker needs to know the > full message and not just the message-ids), can > generate lot of packets with bogus address/es and can > cause some meaningful attack ? He can get us to retransmit replies for each request he sends to address specified by him (reflection attack), but he cannot amplify the number of messages (i.e. there will not be more messages sent to given address than what was sent by attacker). > Anyway, it is required by IKEv2 today, so we don't worsen the > security any more than what is there today. Will it improve the > current situation if we can update the other end about the new > address before the window clears up ? I do not think it will help. It might remove a bit of latency when you loose the only address you have, but we are talking about one round trip or so. But I think we are talking too much about the actual protocol, we should get back to upper level issue 11. My hole point of going in the details of protocol was just to say that it could be done this way too. Now we need to decide which way we want it to be done. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Apr 26 04:11:55 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12138 for ; Tue, 26 Apr 2005 04:11:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 13997FB3E3; Tue, 26 Apr 2005 04:11:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 87666FB311; Tue, 26 Apr 2005 04:11:45 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 145A1FB3E0; Tue, 26 Apr 2005 04:11:44 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 7692FFB2D9 for ; Tue, 26 Apr 2005 04:11:43 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 91D9A8985D for ; Tue, 26 Apr 2005 11:11:41 +0300 (EEST) Message-ID: <426DF7BE.70008@piuha.net> Date: Tue, 26 Apr 2005 11:11:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com References: <200504252028.QAA19579@ietf.org> In-Reply-To: <200504252028.QAA19579@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] FW: I-D ACTION:draft-dupont-mobike-transport-02.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPsec transport mode in Mobike environments > Author(s) : F. Dupont > Filename : draft-dupont-mobike-transport-02.txt > Pages : 6 > Date : 2005-4-25 > >This document specifies how to use IPsec transport mode security > associations in a Mobike environment, i.e., in an environment with > sequential (mobility) or parallel (multi-homing) addresses. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dupont-mobike-transport-02.txt > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike