From mailman-bounces@machshav.com Tue Mar 1 00:03:54 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18576 for ; Tue, 1 Mar 2005 00:03:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BC15DFB292; Tue, 1 Mar 2005 00:03:53 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9A66DFB3A3 for ; Tue, 1 Mar 2005 00:01:18 -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: Tue, 01 Mar 2005 05:00:16 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.4 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 Tue Mar 1 03:14:11 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01251 for ; Tue, 1 Mar 2005 03:14:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 11ABDFB283; Tue, 1 Mar 2005 03:07:07 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 455CEFB266; Tue, 1 Mar 2005 03:07:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 422B6FB280; Tue, 1 Mar 2005 03:07:02 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A25E6FB24A for ; Tue, 1 Mar 2005 03:07:01 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 93CC189853; Tue, 1 Mar 2005 10:06:59 +0200 (EET) Message-ID: <422422A5.9090907@piuha.net> Date: Tue, 01 Mar 2005 10:07:01 +0200 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paul.hoffman@vpnc.org Subject: [Mobike] Agenda for MOBIKE at IETF-62 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 This is the preliminary agenda for next week. Comments, corrections, and other suggestions welcome: MONDAY, March 7, 2005 0900-1130 Morning Sessions SEC mobike IKEv2 Mobility and Multihoming WG 1. Preliminaries, chairs (10 mins) - Notes takers - Agenda bashing - Document status 2. Design document issues, Hannes Tschofenig (90 mins) - Discuss open issues, attempt to come to a common understanding on sufficient requirements and solutions to move forward 3. Protocol proposals update, TBD (30 mins) - Update on existing individual drafts and how they measure against the current design document - Slot reserved for spreading information and making the protocol design more concrete, not for fine tuning the specific documents _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 3 14:14:14 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02988 for ; Thu, 3 Mar 2005 14:14:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C7101FB291; Thu, 3 Mar 2005 14:14:10 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57C35FB28B; Thu, 3 Mar 2005 14:14:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7812AFB28F; Thu, 3 Mar 2005 14:14:03 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id DE293FB285 for ; Thu, 3 Mar 2005 14:14:01 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j23JDwU04893 for ; Thu, 3 Mar 2005 21:13:59 +0200 (EET) X-Scanned: Thu, 3 Mar 2005 21:12:42 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j23JCgjT025418 for ; Thu, 3 Mar 2005 21:12:42 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00tyUC38; Thu, 03 Mar 2005 21:12:40 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j23JCbM06366 for ; Thu, 3 Mar 2005 21:12:37 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Mar 2005 21:12:36 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Mar 2005 21:12:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2005 21:12:36 +0200 Message-ID: Thread-Topic: Thoughts about issues 10/19: changing address vs. paths, and so on... thread-index: AcUgJPWyRNQ6c1EqTXOECbsb/QXgmg== From: To: X-OriginalArrivalTime: 03 Mar 2005 19:12:36.0369 (UTC) FILETIME=[F5BDB810:01C52024] Subject: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... 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: quoted-printable Hi all, The recent discussions about issue #19 (same addresses for both directions?) lead me to do some thinking about different ways the tunnel header addresses for IPsec SAs can be chosen. It seems that there are a couple of quite different approaches to this (and some variations of those)... and I also have the feeling that some of the text in the design draft and protocol proposals has implicitly assumed one of these without really making the assumption explicit. Below I've gone through some of the approaches I've identified so far, but there probably are others that make sense as well. These aspects are also related to issue #17 (partial/full connectivity) ----- Option 1: "MOBIKE just informs the peer of our addresses; how=20 they get used is a matter of local policy beyond our scope." This would be the approach closest to SCTP, I think (and quite close to the approach in Francis's and Tero's protocol proposals, I think). The basic operation here would be as follows: Host A sends a list of its addresses to B (and when the list changes, sends either a new list or diffs to the previous one). And vice versa for B. Host A selects the (tunnel header) src/dst addresses for its IPsec SAs from its own list and the list it received from B in any manner it wants. (Most likely this would somehow take into account local policies and preferences, the order of addresses in B's list, knowledge about connectivity or lack of it, etc.)=20 And vice versa for B. Or in other words, the situation looks something like this: Host A Host B ------ ------- List_A =3D (decided by A) --> <-- List_B =3D (decided by B) src,dst =3D f_A(List_A, List_B, src,dst =3D f_B(List_B, List_A, local preferences, local preferences, local info about local info about connectivity, connectivity, whatever) whatever) Where f_A() and f_B() can be basically anything. Pros and cons: + Similar to SCTP + Symmetric behavior may make sense when the situation is=20 otherwise reasonably symmetric (such as site-to-site VPNs) + Handling partial connectivity and failures is reasonably clear:=20 if an address (interface) goes down, it is removed from the address=20 list. If the failure is in the "middle" (no connectivity, dpd fails),=20 the address lists don't change, but both parties choose address pairs=20 that work based on their own information. - Failure detection and recovery has to be done by both parties,=20 possibly increasing complexity - No guarantee that f_A() and f_B() choose the same address pair; this might not be desirable in e.g. "mobile client" case.=20 In particular, Host A can't move the "downstream" traffic (from B) to some particular interface (address) without deleting all the other addresses from List_A (unless we make=20 restrictions about f_A/f_B). =20 ----- Option 2: "Use the preferred/primary address" It seems that at least some text in previous versions of the design draft assumed that the address listed first in List_A/List_B is the "primary" or "preferred" address that will get used. We get this alternative by defining a very simple f_A() and f_B() for option 1. Host A Host B ------ ------- List_A =3D (decided by A) --> <-- List_B =3D (decided by B) src,dst =3D List_A[1],List_B[1] src,dst =3D List_B[1],List_A[1] Pros and cons: + Simple + Really simple for hosts that have a single static IP address + Symmetric behavior may make sense when the situation is=20 otherwise reasonably symmetric (such as site-to-site VPNs) + Same address pair used in both direction - Connectivity information can be taken into account only when determining List_A/List_B: traffic can be on a path=20 that both ends know to be unworkable - For instance, if both A and B have one IPv4 address and one=20 IPv6 address (and there's no v4/v6 translation), it's not clear=20 how traffic would be moved from one to the another. It seems that=20 the order of List_B has to depend on order of List_A which depends=20 on the order of List_B and so on: unless the protocol specifies=20 some tie-breaking mechanism (limits how the parties can choose=20 the order of List_A/List_B), we could even get a ping-pong effect. ----- Option 3: "Initiator decides" This is the approach chosen in MOPO-IKE. Host A Host B ------ ------- List_A =3D (decided by A) --> <-- List_B =3D (decided by B) =20 src,dst =3D f_A(List_A, List_B, =20 local preferences, =20 local info about connectivity, whatever) --> =20 src,dst =3D received from A (BTW, in this approach Host B does not use List_A for updating IPsec SAs at all; it's only used when List_B changes.) Pros and cons: + Simple to handle partial connectivity and IPv4/v6 cases, without the danger of ping-pong or other unspecified aspects + Very simple for B (VPN gateway in "mobile client" case) + In mobile client case, the client probably has a better information about which addresses should be used.=20 + Same address pair used in both directions + Easier to work with NATs and stateful firewalls - Asymmetric behavior, less elegant perhaps - A's preferences win even in symmetric situations (site-to-site) ----- Option 4: "Use the preferred/primary address if possible" We can clearly refine the approach of option 2 by including slightly more complicated f_A() and f_B(). For instance, Host A Host B ------ ------- List_A =3D (decided by A) --> <-- List_B =3D (decided by B) src,dst =3D src,dst=3D if (List_A[1],List_B[1] works) if(List_B[1],List_A[1] works) List_A[1],List_B[1] List_B[1],List_A[1] else else f_A2(List_A, List_B, f_B2(List_B, List_A, local preferences, local preferences, local info about local info about connectivity, connectivity, whatever) whatever) Pros and cons: + Often uses the same address pair in both directions=20 - Almost as complex as option 1 - List_B still depends on List_A and vice versa in some unspecified way, just like option 2 ----- There are of course many other variations of option 1 that place more or less restrictions of what f_A/f_B do and/or place restrictions on how List_A/List_B are chosen. But it seems that all the options involve some trade-offs and none of them is clearly superior in all circumstances. But according to my understand, options 2 and 4 have important missing pieces (how A and B choose the order of List_A/List_B based on the other) that are needed before their merits can be fully assessed. On the other hand, options 1 and 3 both seem to be working alternatives, since in them the hosts don't have to agree on f_A/f_B or choosing the order of List_A/List_B. (BTW, most of the differences between the approaches occur only when both parties have several addresses: otherwise, they're pretty similar.) These were just some initial thoughts, and comments are very=20 welcome (as are variants of options 2 and 4 that fill in the=20 missing pieces, and other variants). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 3 14:26:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04116 for ; Thu, 3 Mar 2005 14:26:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D3F61FB292; Thu, 3 Mar 2005 14:26:04 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A08DFB28B; Thu, 3 Mar 2005 14:26:00 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 477A9FB28F; Thu, 3 Mar 2005 14:25:58 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 346B3FB285 for ; Thu, 3 Mar 2005 14:25:56 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1666189853; Thu, 3 Mar 2005 21:25:47 +0200 (EET) Message-ID: <422764BE.7090105@piuha.net> Date: Thu, 03 Mar 2005 21:25:50 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... References: In-Reply-To: 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 Pasi.Eronen@nokia.com wrote: >Hi all, > >The recent discussions about issue #19 (same addresses for both >directions?) lead me to do some thinking about different ways >the tunnel header addresses for IPsec SAs can be chosen. > >It seems that there are a couple of quite different approaches >to this (and some variations of those)... and I also have the >feeling that some of the text in the design draft and protocol >proposals has implicitly assumed one of these without really >making the assumption explicit. > >Below I've gone through some of the approaches I've identified >so far, but there probably are others that make sense as well. > >These aspects are also related to issue #17 (partial/full >connectivity) > >----- > >Option 1: "MOBIKE just informs the peer of our addresses; how >they get used is a matter of local policy beyond our scope." > >This would be the approach closest to SCTP, I think (and quite >close to the approach in Francis's and Tero's protocol >proposals, I think). The basic operation here would be as >follows: Host A sends a list of its addresses to B (and when the >list changes, sends either a new list or diffs to the previous >one). And vice versa for B. > >Host A selects the (tunnel header) src/dst addresses for its >IPsec SAs from its own list and the list it received from B in >any manner it wants. (Most likely this would somehow take into >account local policies and preferences, the order of addresses >in B's list, knowledge about connectivity or lack of it, etc.) >And vice versa for B. > >Or in other words, the situation looks something like this: > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = f_A(List_A, List_B, src,dst = f_B(List_B, List_A, > local preferences, local preferences, > local info about local info about > connectivity, connectivity, > whatever) whatever) > >Where f_A() and f_B() can be basically anything. > >Pros and cons: >+ Similar to SCTP >+ Symmetric behavior may make sense when the situation is > otherwise reasonably symmetric (such as site-to-site VPNs) >+ Handling partial connectivity and failures is reasonably clear: > if an address (interface) goes down, it is removed from the address > list. If the failure is in the "middle" (no connectivity, dpd fails), > the address lists don't change, but both parties choose address pairs > that work based on their own information. >- Failure detection and recovery has to be done by both parties, > possibly increasing complexity > > If they are decoupled, it could also mean less complexity... but they probably need to be coupled at least in some sense. At least the "working pair" discovery protocol in draft-ietf-multi6-failure-detection-00.txt needs a fairly close sync between the operations on both sides. >- No guarantee that f_A() and f_B() choose the same address pair; > this might not be desirable in e.g. "mobile client" case. > In particular, Host A can't move the "downstream" traffic > (from B) to some particular interface (address) without > deleting all the other addresses from List_A (unless we make > restrictions about f_A/f_B). > Could this be a problem for firewall traversal? > >----- > >Option 2: "Use the preferred/primary address" > >It seems that at least some text in previous versions of the >design draft assumed that the address listed first in >List_A/List_B is the "primary" or "preferred" address that will >get used. We get this alternative by defining a very simple >f_A() and f_B() for option 1. > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = List_A[1],List_B[1] src,dst = List_B[1],List_A[1] > >Pros and cons: >+ Simple >+ Really simple for hosts that have a single static IP address >+ Symmetric behavior may make sense when the situation is > otherwise reasonably symmetric (such as site-to-site VPNs) >+ Same address pair used in both direction >- Connectivity information can be taken into account only > when determining List_A/List_B: traffic can be on a path > that both ends know to be unworkable >- For instance, if both A and B have one IPv4 address and one > IPv6 address (and there's no v4/v6 translation), it's not clear > how traffic would be moved from one to the another. It seems that > the order of List_B has to depend on order of List_A which depends > on the order of List_B and so on: unless the protocol specifies > some tie-breaking mechanism (limits how the parties can choose > the order of List_A/List_B), we could even get a ping-pong effect. > > Yes. To put it in other words, the working pair discovery protocol needs to run first, and only then we can send the lists. >----- > >Option 3: "Initiator decides" > >This is the approach chosen in MOPO-IKE. > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = f_A(List_A, List_B, > local preferences, > local info about > connectivity, > whatever) --> > > src,dst = received from A > >(BTW, in this approach Host B does not use List_A for updating >IPsec SAs at all; it's only used when List_B changes.) > >Pros and cons: >+ Simple to handle partial connectivity and IPv4/v6 cases, without > the danger of ping-pong or other unspecified aspects >+ Very simple for B (VPN gateway in "mobile client" case) >+ In mobile client case, the client probably has a better > information about which addresses should be used. >+ Same address pair used in both directions >+ Easier to work with NATs and stateful firewalls > > This could be important. >- Asymmetric behavior, less elegant perhaps >- A's preferences win even in symmetric situations (site-to-site) > >----- > >Option 4: "Use the preferred/primary address if possible" > >We can clearly refine the approach of option 2 by including >slightly more complicated f_A() and f_B(). For instance, > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = src,dst= > if (List_A[1],List_B[1] works) if(List_B[1],List_A[1] works) > List_A[1],List_B[1] List_B[1],List_A[1] > else else > f_A2(List_A, List_B, f_B2(List_B, List_A, > local preferences, local preferences, > local info about local info about > connectivity, connectivity, > whatever) whatever) > >Pros and cons: >+ Often uses the same address pair in both directions >- Almost as complex as option 1 >- List_B still depends on List_A and vice versa in some > unspecified way, just like option 2 > >----- > >There are of course many other variations of option 1 that place >more or less restrictions of what f_A/f_B do and/or place >restrictions on how List_A/List_B are chosen. > >But it seems that all the options involve some trade-offs and >none of them is clearly superior in all circumstances. But >according to my understand, options 2 and 4 have important >missing pieces (how A and B choose the order of List_A/List_B >based on the other) that are needed before their merits can be >fully assessed. On the other hand, options 1 and 3 both seem to >be working alternatives, since in them the hosts don't have to >agree on f_A/f_B or choosing the order of List_A/List_B. > > I would agree with this. Do people have a strong preference between 1 and 3? I don't... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 11:09:31 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01967 for ; Fri, 4 Mar 2005 11:09:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C64D1FB28F; Fri, 4 Mar 2005 11:09:27 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 90E7AFB27C; Fri, 4 Mar 2005 11:09:24 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 475CDFB286; Fri, 4 Mar 2005 11:09:23 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 35338FB277 for ; Fri, 4 Mar 2005 11:09:22 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8CA6589853; Fri, 4 Mar 2005 18:09:19 +0200 (EET) Message-ID: <422885D8.4000708@piuha.net> Date: Fri, 04 Mar 2005 17:59:20 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bora@cisco.com, Tschofenig Hannes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com Subject: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) 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 > > >>/ > In general, I think rename this draft to be "Framework for MOBIKE." >/>/ > Then do a requirements draft that has as little text as possible. >/>/ >/>/ i hope that we do not need a requirements draft since we >/>/ already came quite far and are hopefully finished with the >/>/ work in mobike. making progress would be a good thing. >/ >Well, I think the WG has a choice on this, I think this document is >suitable as a framework document, for requirements, I think we need >a more terse and succint document just pointing out what the implementation >needs to do. That is of course my opinion. > Sure. But isn't that what a protocol spec document should do? We don't have an official WG version of such a spec yet, but that's certainly the plan. The spec will give exact rules on what a MOBIKE implementation must/should/may do. The behaviour of the protocol. We expect this to be shorter than the design document. The role of the design document is to act as a problem definition and as a placeholder for talking about the various design issues and tradeoffs. Sometimes working groups also produce true requirements documents, as their first step before developing the protocol itself. The success of such documents has varied a lot, however. They can be useful. But they also tend to be lengthy, and unless they take the design tradeoffs into account, its kind of easy to get a bloated design. I'd rather not get into that process in MOBIKE. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 12:20:18 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07518 for ; Fri, 4 Mar 2005 12:20:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 500B2FB292; Fri, 4 Mar 2005 12:20:17 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 66E2BFB289; Fri, 4 Mar 2005 12:20:13 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2E332FB28B; Fri, 4 Mar 2005 12:20:12 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 82DEAFB27C for ; Fri, 4 Mar 2005 12:20:11 -0500 (EST) Message-ID: <09a201c520de$91ef6120$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , , "Tschofenig Hannes" References: <422885D8.4000708@piuha.net> Subject: Re: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) Date: Fri, 4 Mar 2005 09:21:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 I agree. I think the framework document should be sufficiently clear that a separate requirements document isn't necessary. As I understand it, the point of the framework document was to achieve some kind of concensus on the basic architecture. I think that should be sufficient. jak ----- Original Message ----- From: "Jari Arkko" To: ; "Tschofenig Hannes" Cc: Sent: Friday, March 04, 2005 7:59 AM Subject: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) > > > > > >>/ > In general, I think rename this draft to be "Framework for MOBIKE." > >/>/ > Then do a requirements draft that has as little text as possible. > >/>/ > >/>/ i hope that we do not need a requirements draft since we > >/>/ already came quite far and are hopefully finished with the > >/>/ work in mobike. making progress would be a good thing. > >/ > >Well, I think the WG has a choice on this, I think this document is > >suitable as a framework document, for requirements, I think we need > >a more terse and succint document just pointing out what the implementation > >needs to do. That is of course my opinion. > > > > Sure. But isn't that what a protocol spec document should > do? We don't have an official WG version of such a spec yet, > but that's certainly the plan. The spec will give exact > rules on what a MOBIKE implementation must/should/may > do. The behaviour of the protocol. We expect this to be > shorter than the design document. > > The role of the design document is to act as > a problem definition and as a placeholder for talking > about the various design issues and tradeoffs. > > Sometimes working groups also produce true requirements > documents, as their first step before developing the > protocol itself. The success of such documents has varied > a lot, however. They can be useful. But they also tend to be > lengthy, and unless they take the design tradeoffs into account, > its kind of easy to get a bloated design. I'd rather not get into > that process in MOBIKE. > > --Jari > > > _______________________________________________ > 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 Mar 4 12:24:26 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07998 for ; Fri, 4 Mar 2005 12:24:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ED067FB291; Fri, 4 Mar 2005 12:24:24 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7A084FB289; Fri, 4 Mar 2005 12:24:21 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7392FFB289; Fri, 4 Mar 2005 12:24:20 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by machshav.com (Postfix) with ESMTP id 821BEFB277 for ; Fri, 4 Mar 2005 12:24:19 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2005 09:37:31 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j24HOFZV005874; Fri, 4 Mar 2005 09:24:15 -0800 (PST) Received: from boraw2k05 ([10.32.241.195]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWZ35361; Fri, 4 Mar 2005 09:24:14 -0800 (PST) Message-Id: <200503041724.AWZ35361@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'James Kempf'" , "'Jari Arkko'" , "'Tschofenig Hannes'" Subject: RE: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) Date: Fri, 4 Mar 2005 09:24:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <09a201c520de$91ef6120$016115ac@dcml.docomolabsusa.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcUg3p0SWtdXspEJSMijZTH/U9mcEAAABvlA 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 I am fine with that, the problem is that this framework document is not sufficiently concise in the requirements area so that I can go ahead and write code off of. Specifically, it is hard to judge from this document, what is a MUST, what is a SHOULD, and what is purely optional and esoteric. Maybe we can add a final section to the document summarizing the requirements, I would be happy to contribute to that. Regards, Bora > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, March 04, 2005 9:21 AM > To: Jari Arkko; bora@cisco.com; Tschofenig Hannes > Cc: mobike@machshav.com > Subject: Re: [Mobike] Design draft role, implementation > requirements (Was: latest draft snapshot) > > I agree. I think the framework document should be > sufficiently clear that a separate requirements document > isn't necessary. As I understand it, the point of the > framework document was to achieve some kind of concensus on > the basic architecture. I think that should be sufficient. > > jak > > ----- Original Message ----- > From: "Jari Arkko" > To: ; "Tschofenig Hannes" > > Cc: > Sent: Friday, March 04, 2005 7:59 AM > Subject: [Mobike] Design draft role, implementation requirements (Was: > latest draft snapshot) > > > > > > > > > > >>/ > In general, I think rename this draft to be > "Framework for MOBIKE." > > >/>/ > Then do a requirements draft that has as little text > as possible. > > >/>/ > > >/>/ i hope that we do not need a requirements draft since we > > >/>/ already came quite far and are hopefully finished with the > > >/>/ work in mobike. making progress would be a good thing. > > >/ > > >Well, I think the WG has a choice on this, I think this document is > > >suitable as a framework document, for requirements, I think we need > > >a more terse and succint document just pointing out what the > implementation > > >needs to do. That is of course my opinion. > > > > > > > Sure. But isn't that what a protocol spec document should > > do? We don't have an official WG version of such a spec yet, > > but that's certainly the plan. The spec will give exact > > rules on what a MOBIKE implementation must/should/may > > do. The behaviour of the protocol. We expect this to be > > shorter than the design document. > > > > The role of the design document is to act as > > a problem definition and as a placeholder for talking > > about the various design issues and tradeoffs. > > > > Sometimes working groups also produce true requirements > > documents, as their first step before developing the > > protocol itself. The success of such documents has varied > > a lot, however. They can be useful. But they also tend to be > > lengthy, and unless they take the design tradeoffs into account, > > its kind of easy to get a bloated design. I'd rather not get into > > that process in MOBIKE. > > > > --Jari > > > > > > _______________________________________________ > > 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 Mar 4 12:48:47 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11761 for ; Fri, 4 Mar 2005 12:48:47 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8C9DBFB290; Fri, 4 Mar 2005 12:48:46 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E8C11FB28B; Fri, 4 Mar 2005 12:48:40 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DF172FB28F; Fri, 4 Mar 2005 12:48:39 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 3BAF1FB289 for ; Fri, 4 Mar 2005 12:48:39 -0500 (EST) Message-ID: <0a0c01c520e2$8c1fa8f0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Bora Akyol" , "'Jari Arkko'" , "'Tschofenig Hannes'" References: <200503041724.AWZ35361@mira-sjc5-e.cisco.com> Subject: Re: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) Date: Fri, 4 Mar 2005 09:49:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 > I am fine with that, the problem is that this framework document > is not sufficiently concise in the requirements area > so that I can go ahead and write code off of. > A framework document isn't ever sufficiently concise to write code off of. It should be sufficiently concise to guide the design of the protocol, which should be sufficiently precise to write code off of. Or, at least, that is my understanding of the usual relationship between framework documents and code design (i.e. Proposed Standard) documents. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 12:51:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12419 for ; Fri, 4 Mar 2005 12:51:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1D453FB291; Fri, 4 Mar 2005 12:51:05 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4D5D8FB28B; Fri, 4 Mar 2005 12:51:01 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5D0BCFB28F; Fri, 4 Mar 2005 12:51:00 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by machshav.com (Postfix) with ESMTP id B931DFB289 for ; Fri, 4 Mar 2005 12:50:59 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2005 09:50:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,135,1107763200"; d="scan'208"; a="165270700:sNHT20361732" Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j24HoFq8015813; Fri, 4 Mar 2005 09:50:16 -0800 (PST) Received: from boraw2k05 ([10.32.241.195]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWZ38082; Fri, 4 Mar 2005 09:50:16 -0800 (PST) Message-Id: <200503041750.AWZ38082@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'James Kempf'" , "'Jari Arkko'" , "'Tschofenig Hannes'" Subject: RE: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) Date: Fri, 4 Mar 2005 09:50:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <0a0c01c520e2$8c1fa8f0$016115ac@dcml.docomolabsusa.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcUg4m1lez/DNCltTjiG6B5noakhywAABCuQ 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 Do you disagree with putting a summary of requirements section somewhere in the framework? If you do disagree, why? Bora > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, March 04, 2005 9:50 AM > To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes' > Cc: mobike@machshav.com > Subject: Re: [Mobike] Design draft role, implementation > requirements (Was: latest draft snapshot) > > > > I am fine with that, the problem is that this framework document is > > not sufficiently concise in the requirements area so that I can go > > ahead and write code off of. > > > > A framework document isn't ever sufficiently concise to write > code off of. > It should be sufficiently concise to guide the design of the > protocol, which should be sufficiently precise to write code > off of. Or, at least, that is my understanding of the usual > relationship between framework documents and code design > (i.e. Proposed Standard) documents. > > > jak > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 12:58:17 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14348 for ; Fri, 4 Mar 2005 12:58:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2E835FB29D; Fri, 4 Mar 2005 12:58:15 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7E97EFB290; Fri, 4 Mar 2005 12:58:13 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D2993FB291; Fri, 4 Mar 2005 12:58:11 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 30726FB28F for ; Fri, 4 Mar 2005 12:58:11 -0500 (EST) Message-ID: <0a2401c520e3$e0df6910$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Bora Akyol" , "'Jari Arkko'" , "'Tschofenig Hannes'" References: <200503041750.AWZ38082@mira-sjc5-e.cisco.com> Subject: Re: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) Date: Fri, 4 Mar 2005 09:59:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 No, that's fine. The document needs to be concise as to what is required of the protocol, and the architecture. I was just commenting on what seemed to be an assumption in your email that the document was intended to be the protocol design, rather than to guide it, unless the intent of the WG in this case is to not abide by that customary relationship. jak ----- Original Message ----- From: "Bora Akyol" To: "'James Kempf'" ; "'Jari Arkko'" ; "'Tschofenig Hannes'" Cc: Sent: Friday, March 04, 2005 9:50 AM Subject: RE: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) > Do you disagree with putting a summary of requirements section > somewhere in the framework? > > If you do disagree, why? > > Bora > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, March 04, 2005 9:50 AM > > To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes' > > Cc: mobike@machshav.com > > Subject: Re: [Mobike] Design draft role, implementation > > requirements (Was: latest draft snapshot) > > > > > > > I am fine with that, the problem is that this framework document is > > > not sufficiently concise in the requirements area so that I can go > > > ahead and write code off of. > > > > > > > A framework document isn't ever sufficiently concise to write > > code off of. > > It should be sufficiently concise to guide the design of the > > protocol, which should be sufficiently precise to write code > > off of. Or, at least, that is my understanding of the usual > > relationship between framework documents and code design > > (i.e. Proposed Standard) documents. > > > > > > jak > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 13:00:44 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14995 for ; Fri, 4 Mar 2005 13:00:43 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0BACEFB2A1; Fri, 4 Mar 2005 13:00:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 17A84FB292; Fri, 4 Mar 2005 13:00:40 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D8ED2FB29D; Fri, 4 Mar 2005 13:00:37 -0500 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by machshav.com (Postfix) with ESMTP id B6165FB290 for ; Fri, 4 Mar 2005 13:00:36 -0500 (EST) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2005 19:20:07 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j24I0Vlu007725; Fri, 4 Mar 2005 19:00:31 +0100 (MET) Received: from boraw2k05 ([10.32.241.195]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWZ39113; Fri, 4 Mar 2005 10:00:29 -0800 (PST) Message-Id: <200503041800.AWZ39113@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'James Kempf'" , "'Jari Arkko'" , "'Tschofenig Hannes'" Subject: RE: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) Date: Fri, 4 Mar 2005 10:00:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <0a2401c520e3$e0df6910$016115ac@dcml.docomolabsusa.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcUg479a4cLyRKJSTzC0X5LGyaMG7gAACUsQ 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 Thanks, I did not mean to imply that this document should be the design of the protocol, just that it would be nice to have a summary of the requirements in this doc. Bora > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, March 04, 2005 9:59 AM > To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes' > Cc: mobike@machshav.com > Subject: Re: [Mobike] Design draft role, implementation > requirements (Was: latest draft snapshot) > > No, that's fine. The document needs to be concise as to what > is required of the protocol, and the architecture. > > I was just commenting on what seemed to be an assumption in > your email that the document was intended to be the protocol > design, rather than to guide it, unless the intent of the WG > in this case is to not abide by that customary relationship. > > jak > > ----- Original Message ----- > From: "Bora Akyol" > To: "'James Kempf'" ; "'Jari Arkko'" > ; "'Tschofenig Hannes'" > > Cc: > Sent: Friday, March 04, 2005 9:50 AM > Subject: RE: [Mobike] Design draft role, implementation > requirements (Was: > latest draft snapshot) > > > > Do you disagree with putting a summary of requirements section > > somewhere in the framework? > > > > If you do disagree, why? > > > > Bora > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, March 04, 2005 9:50 AM > > > To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes' > > > Cc: mobike@machshav.com > > > Subject: Re: [Mobike] Design draft role, implementation > > > requirements (Was: latest draft snapshot) > > > > > > > > > > I am fine with that, the problem is that this framework > document is > > > > not sufficiently concise in the requirements area so > that I can go > > > > ahead and write code off of. > > > > > > > > > > A framework document isn't ever sufficiently concise to write > > > code off of. > > > It should be sufficiently concise to guide the design of the > > > protocol, which should be sufficiently precise to write code > > > off of. Or, at least, that is my understanding of the usual > > > relationship between framework documents and code design > > > (i.e. Proposed Standard) documents. > > > > > > > > > jak > > > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 13:20:28 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16957 for ; Fri, 4 Mar 2005 13:20:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7B420FB292; Fri, 4 Mar 2005 13:20:25 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 16A48FB277; Fri, 4 Mar 2005 13:20:23 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B6789FB277; Fri, 4 Mar 2005 13:20:21 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1579BFB28B for ; Fri, 4 Mar 2005 13:20:21 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4BA7D89853; Fri, 4 Mar 2005 20:20:19 +0200 (EET) Message-ID: <4228A6E9.8010104@piuha.net> Date: Fri, 04 Mar 2005 20:20:25 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... References: In-Reply-To: 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 Thinking some more about this, I would actually like to go for approach #3. This would simplify our protocol, and would ensure an arhitecture where NAT and firewall traversal can happen easily. If make this decision, it seems that the following other open issues would also be solved: 1 (direct or indirect indicators): Because one side is responsible for the whole thing, we would have to support failure detection using DPD at the initiator side. Note that responder may still need to update its own list of addresses now and then, say if an interface goes down. unassigned issue # (the list complaint that large SGWs should not be forced to check the connectivity to clients): The client would be doing all the work. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 13:20:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16990 for ; Fri, 4 Mar 2005 13:20:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6BE80FB2A0; Fri, 4 Mar 2005 13:20:38 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 029DCFB290; Fri, 4 Mar 2005 13:20:31 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00C41FB29F; Fri, 4 Mar 2005 13:20:30 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A0932FB277 for ; Fri, 4 Mar 2005 13:20:28 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E8EE189871; Fri, 4 Mar 2005 20:20:23 +0200 (EET) Message-ID: <4228A6ED.2070202@piuha.net> Date: Fri, 04 Mar 2005 20:20:29 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bora Akyol Subject: Re: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot) References: <200503041724.AWZ35361@mira-sjc5-e.cisco.com> In-Reply-To: <200503041724.AWZ35361@mira-sjc5-e.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'James Kempf'" , mobike@machshav.com, "'Tschofenig Hannes'" 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 Bora Akyol wrote: >I am fine with that, the problem is that this framework document >is not sufficiently concise in the requirements area >so that I can go ahead and write code off of. > > Yes. We are not there yet, its in the future protocol doc! >Specifically, it is hard to judge from this document, what is a MUST, >what is a SHOULD, and what is purely optional and esoteric. > >Maybe we can add a final section to the document summarizing the >requirements, I would be happy to contribute to that. > > Thanks for offering to contribute! I can see two potential items where additional contributions like this would be useful: - A summary table at the end of the design document that lists the design choices and features that are needed. This is just a list or a table; not something that you can write code from. But it could help people grasp easier what conclusions the document has reached. Something like: - Indicating support for MOBIKE: Use FOO feature from IKEv2. - Storing peer addresses: Store multiple, not just one - ... - Another protocol spec proposal. We do have already some, but additional ones are very welcome too. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 14:12:28 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21809 for ; Fri, 4 Mar 2005 14:12:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 17E17FB2A0; Fri, 4 Mar 2005 14:12:25 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BB458FB298; Fri, 4 Mar 2005 14:12:22 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 444C0FB290; Fri, 4 Mar 2005 14:12:21 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A700AFB289 for ; Fri, 4 Mar 2005 14:12:20 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4E10E89853; Fri, 4 Mar 2005 21:12:19 +0200 (EET) Message-ID: <4228AE74.8010208@piuha.net> Date: Fri, 04 Mar 2005 20:52:36 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: touch@isi.edu, Tschofenig Hannes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com Subject: [Mobike] issue 16, recovering from problems that show just a lack of packets 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 Joe, Hannes, We had a lengthy discussion about this in December. Here's what I think the conclusion was: o MOBIKE can be affected by multiple sources of information, both local (L2 tells it no longer is connected) and path-related (DPD tells that we have a problem). o Retrying with new addresses (src and dst) is OK under such problem situations. Recommend leaving specific address selection to lower layers in the stack, e.g., unspecifed source address when using API to IP. o Potential interference with dynamic routing protocols needs to be noted & documented. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 14:14:30 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21894 for ; Fri, 4 Mar 2005 14:14:28 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 36DC3FB29E; Fri, 4 Mar 2005 14:14:28 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86D0DFB277; Fri, 4 Mar 2005 14:14:25 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BD3F4FB27C; Fri, 4 Mar 2005 14:14:23 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 15FDEFB266 for ; Fri, 4 Mar 2005 14:14:23 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B6A0C89853; Fri, 4 Mar 2005 21:14:15 +0200 (EET) Message-ID: <4228B38D.5040207@piuha.net> Date: Fri, 04 Mar 2005 21:14:21 +0200 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, paul.hoffman@vpnc.org, Tschofenig Hannes Subject: [Mobike] agenda for MOBIKE, take 2 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 MONDAY, March 7, 2005 0900-1130 Morning Sessions SEC mobike IKEv2 Mobility and Multihoming WG 1. Preliminaries, chairs (10 mins) - Notes takers - Agenda bashing - Document status 2. Design document issues, Hannes Tschofenig (90 mins) - Discuss open issues, attempt to come to a common understanding on sufficient requirements and solutions to move forward Issue 19: Same pair for addresses used for IPsec in both directions? Issue NN: Choosing outer IPsec addresses (Pasi's new thread) Issue 11: Window size problem Issue 18 & 6: Threats discussion and when to do RR? 3. Protocol proposals update (30 mins) - Update on existing individual drafts and how they measure against the current design document - Slot reserved for spreading information and making the protocol design more concrete, not for fine tuning the specific documents http://www.ietf.org/internet-drafts/draft-eronen-mobike-mopo-02.txt (Pasi Eronen) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 4 14:23:01 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22753 for ; Fri, 4 Mar 2005 14:23:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 520E7FB2A2; Fri, 4 Mar 2005 14:22:58 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 33E66FB29E; Fri, 4 Mar 2005 14:22:56 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9181FFB29F; Fri, 4 Mar 2005 14:22:54 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 06BB0FB299 for ; Fri, 4 Mar 2005 14:22:54 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E4D9989853; Fri, 4 Mar 2005 21:22:51 +0200 (EET) Message-ID: <4228B592.4020701@piuha.net> Date: Fri, 04 Mar 2005 21:22:58 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: maureen.stillman@nokia.com, Pasi.Eronen@nokia.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com Subject: [Mobike] Re: Issue #15 How to do RR (empty informational exchange is not enough) 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 Yes, I think we can consider this issue closed. Pasi, can you mark it closed on the issue web? Thanks. Note that we already have another open issue about the "when" part of RR, issue 6. That needs to be worked on. --Jari >Issue #15 How to do RR (empty informational exchange is not enough) > >I agree with Pasi that the cookie approach is a good one to circumvent >the problems associated with empty informational exchange messages. >This approach is successfully used in other IETF protocols and I see no >reason to invent a new mechanism. > >Is anyone opposed to this proposal for handling #15? > >-- Maureen > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Mar 7 08:53:52 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16003 for ; Mon, 7 Mar 2005 08:53:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9FC6EFB282; Mon, 7 Mar 2005 08:53:48 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 295CFFB277; Mon, 7 Mar 2005 08:53:45 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0EACCFB27F; Mon, 7 Mar 2005 08:53:44 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C98A9FB24A for ; Mon, 7 Mar 2005 08:53:42 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j27DrTI09407; Mon, 7 Mar 2005 14:53:29 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j27DrTF6062230; Mon, 7 Mar 2005 14:53:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200503071353.j27DrTF6062230@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] intermediate mobike design draft update In-reply-to: Your message of Wed, 26 Jan 2005 19:02:40 +0200. Date: Mon, 07 Mar 2005 14:53:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, hannes.tschofenig@siemens.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: It's a separate question whether the current paths should be equal in stable situations (where NATs are not present). In MOPO-IKE, they are (the responder uses the path selected by the initiator). In SCTP, they're not (each peer makes its selection independently). I'm not sure which is the case for draft-dupont-ikev2-addrmgmt (Francis, could you clarify this?) => I don't remember if I already answered... My proposal is flexible: in the common case the paths are equal but as the selection is in fact independent one can make them not equal. BTW the control is on your address the other peer should use for you, i.e., on the destination address of incoming packets. Of course you can use another address as source of outgoing address. 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 Mon Mar 7 13:30:52 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18247 for ; Mon, 7 Mar 2005 13:30:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2CA6EFB283; Mon, 7 Mar 2005 13:30:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 835C3FB27F; Mon, 7 Mar 2005 13:30:45 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 286BDFB27F; Mon, 7 Mar 2005 13:30:44 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id D6556FB266 for ; Mon, 7 Mar 2005 13:30:42 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j27IUeZ26222 for ; Mon, 7 Mar 2005 20:30:40 +0200 (EET) X-Scanned: Mon, 7 Mar 2005 20:30:04 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j27IU4Xc007465 for ; Mon, 7 Mar 2005 20:30:04 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 002lV4I7; Mon, 07 Mar 2005 20:30:02 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j27IU2U06337 for ; Mon, 7 Mar 2005 20:30:02 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 7 Mar 2005 20:29:29 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 7 Mar 2005 20:29:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... Date: Mon, 7 Mar 2005 20:27:02 +0200 Message-ID: Thread-Topic: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... thread-index: AcUgJt3SFdojU/QjTj+iFp5tC6PVawDG35aA From: To: X-OriginalArrivalTime: 07 Mar 2005 18:29:29.0245 (UTC) FILETIME=[9958ECD0:01C52343] 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: quoted-printable During the meeting today, Francis pointed out another possibly option not really covered by 1-4. Option 5: "Peers decide the source addresses independently" Host A Host B ------ ------- List_A =3D (decided by A) --> <-- List_B =3D (decided by B) dst =3D List_B[1] dst =3D List_A[1] src =3D f_A(List_A, List_B, src =3D f_B(List_B, List_A, local preferences, local preferences, local info about local info about connectivity, connectivity, whatever) whatever) Pros and cons: + Reasonably simple - No guarantee A-to-B and B-to-A traffic choose the same traffic=20 pair (which complicates things with stateful packet filters) - Host A can't move the "upstream" traffic to some other interface without co-operation from B (if we have partial connectivity).=20 For instance, if Host A has one IPv4 interface and one IPv6 interface, = A can't move the traffic to the IPv6 interface unless it somehow=20 convinces B to reorder List_B: how does this happen? (And if the answer is that List_B depends on List_A which depends on List B, how does this work?) - The same thing also applies to failures in the middle: even if both parties' addresses and preferences stay the same, somehow they must reorder either List_A, List_B, or both. (Hmm, I think that any option that is fully symmetric will have=20 these problems.. but there are certainly options that are=20 less asymmetric than option 3.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Mar 7 15:26:33 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00021 for ; Mon, 7 Mar 2005 15:26:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7C6D6FB282; Mon, 7 Mar 2005 15:26:29 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 89B70FB277; Mon, 7 Mar 2005 15:26:27 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5F6D2FB27F; Mon, 7 Mar 2005 15:26:26 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id E4E9CFB266 for ; Mon, 7 Mar 2005 15:26:24 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j27KQFq04510; Mon, 7 Mar 2005 21:26:15 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j27KQFpJ063473; Mon, 7 Mar 2005 21:26:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200503072026.j27KQFpJ063473@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... In-reply-to: Your message of Mon, 07 Mar 2005 20:27:02 +0200. Date: Mon, 07 Mar 2005 21:26:15 +0100 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: During the meeting today, Francis pointed out another possibly option not really covered by 1-4. => thanks Pasi, you caught my idea. Option 5: "Peers decide the source addresses independently" Host A Host B ------ ------- List_A = (decided by A) --> <-- List_B = (decided by B) dst = List_B[1] dst = List_A[1] src = f_A(List_A, List_B, src = f_B(List_B, List_A, local preferences, local preferences, local info about local info about connectivity, connectivity, whatever) whatever) => note that f_A is the application of RFC 3484 so it is usually predictable and always deterministic. Aniother point is this makes IKE behavior "standard" in the common case. Pros and cons: + Reasonably simple - No guarantee A-to-B and B-to-A traffic choose the same traffic pair (which complicates things with stateful packet filters) => no guaranteed but in usual cases easy to enforce. - Host A can't move the "upstream" traffic to some other interface without co-operation from B (if we have partial connectivity). For instance, if Host A has one IPv4 interface and one IPv6 interface, A can't move the traffic to the IPv6 interface unless it somehow convinces B to reorder List_B: how does this happen? (And if the answer is that List_B depends on List_A which depends on List B, how does this work?) => I agree: as the idea is to control downstream traffic only nothing is available directly about upstream traffic. - The same thing also applies to failures in the middle: even if both parties' addresses and preferences stay the same, somehow they must reorder either List_A, List_B, or both. (Hmm, I think that any option that is fully symmetric will have these problems.. but there are certainly options that are less asymmetric than option 3.) => I agree but we should find what is the minimal thing we need. IMHO control on the destination of downstream traffic is mandatory when an address can stop to work (i.e., for mobility)... and I can't see something else. Thanks! Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Mar 7 19:05:57 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26452 for ; Mon, 7 Mar 2005 19:05:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E9A0BFB27F; Mon, 7 Mar 2005 19:05:57 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 12B83FB266; Mon, 7 Mar 2005 19:05:50 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00060FB27F; Mon, 7 Mar 2005 19:05:48 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 129F1FB262 for ; Mon, 7 Mar 2005 19:05:47 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2805js20778 for ; Tue, 8 Mar 2005 02:05:45 +0200 (EET) X-Scanned: Tue, 8 Mar 2005 02:05:12 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j2805CX6025324 for ; Tue, 8 Mar 2005 02:05:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00aPEOsi; Tue, 08 Mar 2005 02:05:11 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2805AM23775 for ; Tue, 8 Mar 2005 02:05:10 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 02:04:56 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 02:04:55 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 02:04:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2005 02:04:10 +0200 Message-ID: Thread-Topic: Slides available thread-index: AcUjclqLWskpsGlSTK+GZvRL+fiq0Q== From: To: X-OriginalArrivalTime: 08 Mar 2005 00:04:55.0230 (UTC) FILETIME=[755E85E0:01C52372] Subject: [Mobike] Slides available 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: quoted-printable Hi, The slides from today's MOBIKE WG meeting are now available here: http://www.vpnc.org/ietf-mobike/ Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 09:51:49 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29853 for ; Tue, 8 Mar 2005 09:51:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2E70FFB27D; Tue, 8 Mar 2005 09:51:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 34281FB266; Tue, 8 Mar 2005 09:51:41 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5E474FB277; Tue, 8 Mar 2005 09:51:39 -0500 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by machshav.com (Postfix) with ESMTP id 0B4E6FB262 for ; Tue, 8 Mar 2005 09:51:38 -0500 (EST) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2005 16:12:14 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j28EpDm8021044 for ; Tue, 8 Mar 2005 15:51:28 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Mar 2005 15:51:27 +0100 Received: from evyncke-w2k02.cisco.com ([10.61.64.212]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 15:51:26 +0100 Message-Id: <5.1.0.14.2.20050308141230.0349fca8@127.0.0.1> X-Sender: evyncke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Mar 2005 14:17:03 +0100 To: mobike@machshav.com From: Eric Vyncke Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 08 Mar 2005 14:51:27.0025 (UTC) FILETIME=[4E265210:01C523EE] Subject: [Mobike] MOPO and the 'ping' probes 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 As Paul asked for new voices during yesterday meeting... ;-) I just wonder using 'ping' to test the reachability of a peer is correct. Pings will give a good indication in 95% of the use cases, but, due to ICMP rate limiting (to prevent DoS), due some security policy (denying ICMP or IPsec over UDP), ... there will be a disconnect in a couple of use cases between a ping exchange and an IKEv2 exchange. In some cases, ping will go back and forth the peers while IKEv2 won't. In some other cases, ping will not go back and forth the peers while IKEv2 will. In short, use out-of-IKE probes only as a very rough estimate. Hope this helps -eric _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 10:00:50 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01619 for ; Tue, 8 Mar 2005 10:00:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E9232FB282; Tue, 8 Mar 2005 10:00:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CAD1AFB277; Tue, 8 Mar 2005 10:00:44 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B5089FB27C; Tue, 8 Mar 2005 10:00:43 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 06C95FB266 for ; Tue, 8 Mar 2005 10:00:43 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9740A89853; Tue, 8 Mar 2005 17:00:40 +0200 (EET) Message-ID: <422DBE26.5050701@piuha.net> Date: Tue, 08 Mar 2005 17:00:54 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Vyncke Subject: Re: [Mobike] MOPO and the 'ping' probes References: <5.1.0.14.2.20050308141230.0349fca8@127.0.0.1> In-Reply-To: <5.1.0.14.2.20050308141230.0349fca8@127.0.0.1> 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 Right, and this would indeed be an issue. But I think Pasi's intent was to use a new IKEv2 message instead of ICMP. He just referred to the message as a 'ping'. His proposed message was indeed outside the normal IKE processing, but only with regards to the window, not in terms of going outside UDP and port 500, or the IKEv2 message structure... --Jari Eric Vyncke wrote: >As Paul asked for new voices during yesterday meeting... ;-) > >I just wonder using 'ping' to test the reachability of a peer is correct. > >Pings will give a good indication in 95% of the use cases, but, due to ICMP rate limiting (to prevent DoS), due some security policy (denying ICMP or IPsec over UDP), ... there will be a disconnect in a couple of use cases between a ping exchange and an IKEv2 exchange. > >In some cases, ping will go back and forth the peers while IKEv2 won't. > >In some other cases, ping will not go back and forth the peers while IKEv2 will. > >In short, use out-of-IKE probes only as a very rough estimate. > >Hope this helps > >-eric >_______________________________________________ >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 Mar 8 10:24:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05348 for ; Tue, 8 Mar 2005 10:24:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8D180FB240; Tue, 8 Mar 2005 10:24:36 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F049BFB266; Tue, 8 Mar 2005 10:24:32 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ADF3EFB277; Tue, 8 Mar 2005 10:24:30 -0500 (EST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id 6E986FB240 for ; Tue, 8 Mar 2005 10:24:29 -0500 (EST) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2005 10:24:29 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j28FOQ1j022543; Tue, 8 Mar 2005 10:24:26 -0500 (EST) Received: from stephanew2k02 (dhcp-kta1-161-44-192-103.cisco.com [161.44.192.103]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABM42906; Tue, 8 Mar 2005 07:24:24 -0800 (PST) Message-Id: <200503081524.ABM42906@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Eric Vyncke'" , Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 10:24:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUj7o+zs1HkqqnMRhiBPzqzeOXdRwAAMCYQ In-Reply-To: <5.1.0.14.2.20050308141230.0349fca8@127.0.0.1> 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 All, Just coming up to speed on Mobike. I am unable to attend the IETF, so I apoligize for having to chime in after the fact. I was just reviewing the slides this morning, when I noticed the possible use of ping for reachabiilty. I don't like this approach for 2 reasons: 1 - From an implementor's standby, ICMP is very detached from IKE, and I'd like to leave it that way. ICMP is often handled by the Network Processor, while IKE is handled at the application layer. While adding hooks between the two is not impossible, it is not desireable. 2 - ICMP may be restricted by different ACLs than Ipsec or IKE packets. So, an ICMP failure or success wouldn't necessarily match an Ipsec or IKE failure or success. I wonder why the simple DPD combined with IKE retransmit mechanism wouldn't suffice. The way I see it, is one of two things is happening where you can decide that perhaps a peer's interface has gone down. 1 - You've sent ESP packets, but you haven't received any ESP packets from the peer in x seconds (triggering DPD) 2 - You sent an IKE packet (PHASE2, rekey, Ack'd notify, whatever), have retransmitted a few times, and you are not getting a reply. Wouldn't these 2 things suffice? Basically, I tried to send the peer an IKE packet (+ a couple of retransmits) and I'm not getting a reply. If this happens, you could then switch to using the next address in the list. Another issue that is bothering me. Instead of just switching to the next address in the list, could we not instead send the peer an NOTIFY-POSSIBLE-INTERFACE-FAILURE to the peer using all the other addresses we know. The peer could then make an intelligent decision, and perhaps even prompt the user. The peer would send us a CHANGE-PATH message. This would make the implementation simpler as an IP address change would always be initiated by the peer who is changing addresses. Also, it would help avoid cases where the two peers are using different IP addresses During a transition. The cost of doing this, of course, is the extra latency of an extra notify message exchange. Thoughts? Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Eric Vyncke > Sent: Tuesday, March 08, 2005 8:17 AM > To: mobike@machshav.com > Subject: [Mobike] MOPO and the 'ping' probes > > As Paul asked for new voices during yesterday meeting... ;-) > > I just wonder using 'ping' to test the reachability of a peer > is correct. > > Pings will give a good indication in 95% of the use cases, > but, due to ICMP rate limiting (to prevent DoS), due some > security policy (denying ICMP or IPsec over UDP), ... there > will be a disconnect in a couple of use cases between a ping > exchange and an IKEv2 exchange. > > In some cases, ping will go back and forth the peers while > IKEv2 won't. > > In some other cases, ping will not go back and forth the > peers while IKEv2 will. > > In short, use out-of-IKE probes only as a very rough estimate. > > Hope this helps > > -eric > _______________________________________________ > 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 Mar 8 10:54:48 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09436 for ; Tue, 8 Mar 2005 10:54:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D4DF7FB27D; Tue, 8 Mar 2005 10:54:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9DC53FB262; Tue, 8 Mar 2005 10:54:42 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AAA48FB266; Tue, 8 Mar 2005 10:54:41 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 96B2FFB246 for ; Tue, 8 Mar 2005 10:54:40 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28FsTZ03077; Tue, 8 Mar 2005 17:54:30 +0200 (EET) X-Scanned: Tue, 8 Mar 2005 17:50:57 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j28FovAc008151; Tue, 8 Mar 2005 17:50:57 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00kt7Kkj; Tue, 08 Mar 2005 17:50:55 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28ForM03523; Tue, 8 Mar 2005 17:50:53 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 17:50:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 17:50:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 17:50:36 +0200 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes thread-index: AcUj7wOJJ9ezwjQ9RuaY8EAKQy6fgQAA/Rug From: To: , X-OriginalArrivalTime: 08 Mar 2005 15:50:35.0192 (UTC) FILETIME=[9105A380:01C523F6] 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: quoted-printable Hi, Perhaps my presentation was a bit unclear on this, but MOPO-IKE does not use ICMP (which would not really work, due to the reasons you mentioned). Instead, it adds a new message type to IKEv2 (somewhat similar to the IKEv1 R-U-THERE/R-U-THERE-ACK messages). Best regards, Pasi > -----Original Message----- > From: Eric Vyncke > Sent: Tuesday, March 08, 2005 3:17 PM > To: mobike@machshav.com > Subject: [Mobike] MOPO and the 'ping' probes >=20 >=20 > As Paul asked for new voices during yesterday meeting... ;-) >=20 > I just wonder using 'ping' to test the reachability of a peer=20 > is correct.=20 >=20 > Pings will give a good indication in 95% of the use cases,=20 > but, due to ICMP rate limiting (to prevent DoS), due some=20 > security policy (denying ICMP or IPsec over UDP), ... there=20 > will be a disconnect in a couple of use cases between a ping=20 > exchange and an IKEv2 exchange. >=20 > In some cases, ping will go back and forth the peers while=20 > IKEv2 won't. >=20 > In some other cases, ping will not go back and forth the=20 > peers while IKEv2 will. >=20 > In short, use out-of-IKE probes only as a very rough estimate. >=20 > Hope this helps >=20 > -eric _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 11:05:17 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11557 for ; Tue, 8 Mar 2005 11:05:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2FF7AFB27D; Tue, 8 Mar 2005 11:05:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BD32CFB262; Tue, 8 Mar 2005 11:05:11 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4565DFB266; Tue, 8 Mar 2005 11:05:10 -0500 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by machshav.com (Postfix) with ESMTP id 58BE5FB246 for ; Tue, 8 Mar 2005 11:05:09 -0500 (EST) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2005 17:25:52 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j28G4fmG019832; Tue, 8 Mar 2005 17:05:06 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Mar 2005 17:05:04 +0100 Received: from evyncke-w2k02.cisco.com ([10.61.64.212]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 17:05:03 +0100 Message-Id: <5.1.0.14.2.20050308170442.04372760@127.0.0.1> X-Sender: evyncke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Mar 2005 17:04:55 +0100 To: From: Eric Vyncke Subject: RE: [Mobike] MOPO and the 'ping' probes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 08 Mar 2005 16:05:04.0203 (UTC) FILETIME=[96FE31B0:01C523F8] 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 At 17:50 8/03/2005 +0200, Pasi.Eronen@nokia.com wrote: >Hi, > >Perhaps my presentation was a bit unclear on this, but MOPO-IKE does >not use ICMP (which would not really work, due to the reasons you >mentioned). Instead, it adds a new message type to IKEv2 (somewhat >similar to the IKEv1 R-U-THERE/R-U-THERE-ACK messages). Thanks for the clarification. -eric _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 11:06:41 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11626 for ; Tue, 8 Mar 2005 11:06:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7FD92FB27C; Tue, 8 Mar 2005 11:06:38 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7FF3BFB262; Tue, 8 Mar 2005 11:06:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6749CFB266; Tue, 8 Mar 2005 11:06:33 -0500 (EST) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by machshav.com (Postfix) with ESMTP id 47982FB246 for ; Tue, 8 Mar 2005 11:06:32 -0500 (EST) Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by kremlin.juniper.net with ESMTP; 08 Mar 2005 08:06:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107763200"; d="scan'208"; a="246551907:sNHT30887220" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 08:06:31 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 08:06:30 -0800 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes Thread-Index: AcUj7o+zs1HkqqnMRhiBPzqzeOXdRwAAMCYQAAHzQcA= From: "Timothy Liu" To: , "Eric Vyncke" , X-OriginalArrivalTime: 08 Mar 2005 16:06:31.0454 (UTC) FILETIME=[CAFFA3E0:01C523F8] 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: quoted-printable The 'ping' was used to test new paths not the liveness of current path. On other points I agree with you that we should not use ICMP packets which can be treated quite differently by firewall devices. There is an approach base on same idea, I am not sure if this has been brought up before. Why not send DPD with the same sequence number (simultaneously?) to all the paths that the peer wants to test? From the other side it can treat is as retransmission and resend the DPD response through the different paths. The retransmission policy on the requester side is only to retry along the primary path. Tim -----Original Message----- From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] On Behalf Of Stephane Beaulieu Sent: Tuesday, March 08, 2005 7:24 AM To: 'Eric Vyncke'; mobike@machshav.com Subject: RE: [Mobike] MOPO and the 'ping' probes Hi All, Just coming up to speed on Mobike. I am unable to attend the IETF, so I apoligize for having to chime in after the fact. I was just reviewing the slides this morning, when I noticed the possible use of ping for reachabiilty. I don't like this approach for 2 reasons: 1 - From an implementor's standby, ICMP is very detached from IKE, and I'd like to leave it that way. ICMP is often handled by the Network Processor, while IKE is handled at the application layer. While adding hooks between the two is not impossible, it is not desireable. 2 - ICMP may be restricted by different ACLs than Ipsec or IKE packets. So, an ICMP failure or success wouldn't necessarily match an Ipsec or IKE failure or success. I wonder why the simple DPD combined with IKE retransmit mechanism wouldn't suffice. The way I see it, is one of two things is happening where you can decide that perhaps a peer's interface has gone down. 1 - You've sent ESP packets, but you haven't received any ESP packets from the peer in x seconds (triggering DPD)=20 2 - You sent an IKE packet (PHASE2, rekey, Ack'd notify, whatever), have retransmitted a few times, and you are not getting a reply. Wouldn't these 2 things suffice? Basically, I tried to send the peer an IKE packet (+ a couple of retransmits) and I'm not getting a reply. If this happens, you could then switch to using the next address in the list. Another issue that is bothering me. Instead of just switching to the next address in the list, could we not instead send the peer an NOTIFY-POSSIBLE-INTERFACE-FAILURE to the peer using all the other addresses we know. The peer could then make an intelligent decision, and perhaps even prompt the user. The peer would send us a CHANGE-PATH message. This would make the implementation simpler as an IP address change would always be initiated by the peer who is changing addresses. Also, it would help avoid cases where the two peers are using different IP addresses During a transition. The cost of doing this, of course, is the extra latency of an extra notify message exchange. Thoughts? Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com] On Behalf Of Eric Vyncke > Sent: Tuesday, March 08, 2005 8:17 AM > To: mobike@machshav.com > Subject: [Mobike] MOPO and the 'ping' probes >=20 > As Paul asked for new voices during yesterday meeting... ;-) >=20 > I just wonder using 'ping' to test the reachability of a peer=20 > is correct.=20 >=20 > Pings will give a good indication in 95% of the use cases,=20 > but, due to ICMP rate limiting (to prevent DoS), due some=20 > security policy (denying ICMP or IPsec over UDP), ... there=20 > will be a disconnect in a couple of use cases between a ping=20 > exchange and an IKEv2 exchange. >=20 > In some cases, ping will go back and forth the peers while=20 > IKEv2 won't. >=20 > In some other cases, ping will not go back and forth the=20 > peers while IKEv2 will. >=20 > In short, use out-of-IKE probes only as a very rough estimate. >=20 > Hope this helps >=20 > -eric > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ 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 Mar 8 11:21:50 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13201 for ; Tue, 8 Mar 2005 11:21:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D9FB5FB281; Tue, 8 Mar 2005 11:21:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C40EDFB262; Tue, 8 Mar 2005 11:21:44 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CCA0EFB266; Tue, 8 Mar 2005 11:21:42 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by machshav.com (Postfix) with ESMTP id BABDEFB240 for ; Tue, 8 Mar 2005 11:21:41 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j28GLdX8007964; Tue, 8 Mar 2005 09:21:40 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j28GLcOp010853; Tue, 8 Mar 2005 11:21:39 -0500 (EST) Subject: RE: [Mobike] MOPO and the 'ping' probes From: Bill Sommerfeld To: Timothy Liu In-Reply-To: References: Content-Type: text/plain Message-Id: <1110298894.590.182.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 08 Mar 2005 10:21:36 -0600 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 On Tue, 2005-03-08 at 10:06, Timothy Liu wrote: > There is an approach base on same idea, I am not sure if this has been > brought up before. Why not send DPD with the same sequence number > (simultaneously?) to all the paths that the peer wants to test? From the > other side it can treat is as retransmission and resend the DPD response > through the different paths. The retransmission policy on the requester > side is only to retry along the primary path. yes, but you also need to handle the case when the sender didn't have enough window for even one request because all window slots were occupied by messages which hadn't gone through because the preferred path was broken.. One solution would be to use a real request instead of a DPD ping when you actually have something real to send. I'd think simultaneous probes would be considered unfriendly to the network; non-simulataneous (delay of a large fraction of the RTT or so between each probe) might be nearly as good at finding a path without generating nearly as much redundant traffic... _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 11:39:46 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15162 for ; Tue, 8 Mar 2005 11:39:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 93080FB283; Tue, 8 Mar 2005 11:39:42 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 842C5FB262; Tue, 8 Mar 2005 11:39:36 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 01D47FB266; Tue, 8 Mar 2005 11:39:35 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id 34A5CFB246 for ; Tue, 8 Mar 2005 11:39:33 -0500 (EST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2005 11:55:40 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107752400"; d="scan'208"; a="39672457:sNHT20320932" 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 j28GdTjI029922; Tue, 8 Mar 2005 11:39:29 -0500 (EST) Received: from stephanew2k02 (dhcp-kta1-161-44-192-103.cisco.com [161.44.192.103]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABM45187; Tue, 8 Mar 2005 08:39:28 -0800 (PST) Message-Id: <200503081639.ABM45187@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Bill Sommerfeld'" , "'Timothy Liu'" Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 11:39:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUj+vIS+eeS7LWgQ7CoTfoda4BsQAAAepnQ In-Reply-To: <1110298894.590.182.camel@unknown.hamachi.org> 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 > On Tue, 2005-03-08 at 10:06, Timothy Liu wrote: > > There is an approach base on same idea, I am not sure if > this has been > > brought up before. Why not send DPD with the same sequence number > > (simultaneously?) to all the paths that the peer wants to > test? From > > the other side it can treat is as retransmission and resend the DPD > > response through the different paths. The retransmission > policy on the > > requester side is only to retry along the primary path. > > yes, but you also need to handle the case when the sender > didn't have enough window for even one request because all > window slots were occupied by messages which hadn't gone > through because the preferred path was broken.. Agreed. > > One solution would be to use a real request instead of a DPD > ping when you actually have something real to send. That depends on what you define as being 'something real'. Is a normal DPD something real? For example, I notice that some TCP sessions are starting to time out because the peer isn't ack'ing my packets. Therefore, I elect to send a DPD message to check for liveliness. I would think this would qualify as a 'real' message, but wanted to double-check that we are on the same page. > > I'd think simultaneous probes would be considered unfriendly > to the network; non-simulataneous (delay of a large fraction > of the RTT or so between each probe) might be nearly as good > at finding a path without generating nearly as much redundant > traffic... > > > > > > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 12:35:11 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22894 for ; Tue, 8 Mar 2005 12:35:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 253EDFB27D; Tue, 8 Mar 2005 12:35:07 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28256FB262; Tue, 8 Mar 2005 12:35:03 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 11221FB266; Tue, 8 Mar 2005 12:35:02 -0500 (EST) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by machshav.com (Postfix) with ESMTP id 4523AFB246 for ; Tue, 8 Mar 2005 12:35:01 -0500 (EST) Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 08 Mar 2005 09:35:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107763200"; d="scan'208"; a="246559849:sNHT21236152" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 09:35:00 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 09:34:59 -0800 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes Thread-Index: AcUj+up1SYGnFI5jT6m4Jnv5fPZb9AAAdJYw From: "Timothy Liu" To: "Bill Sommerfeld" X-OriginalArrivalTime: 08 Mar 2005 17:35:00.0665 (UTC) FILETIME=[2788F290:01C52405] 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: quoted-printable > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Tuesday, March 08, 2005 8:22 AM > To: Timothy Liu > Cc: stephane@cisco.com; Eric Vyncke; mobike@machshav.com > Subject: RE: [Mobike] MOPO and the 'ping' probes >=20 > On Tue, 2005-03-08 at 10:06, Timothy Liu wrote: > > There is an approach base on same idea, I am not sure if this has been > > brought up before. Why not send DPD with the same sequence number > > (simultaneously?) to all the paths that the peer wants to test? From the > > other side it can treat is as retransmission and resend the DPD response > > through the different paths. The retransmission policy on the requester > > side is only to retry along the primary path. >=20 > yes, but you also need to handle the case when the sender didn't have > enough > window for even one request because all window slots were occupied by > messages > which hadn't gone through because the preferred path was broken.. Good point. >=20 > One solution would be to use a real request instead of a DPD ping > when you actually have something real to send. >=20 > I'd think simultaneous probes would be considered unfriendly to the > network; > non-simulataneous (delay of a large fraction of the RTT or so between each > probe) > might be nearly as good at finding a path without generating nearly as > much redundant > traffic... >=20 >=20 How about this for a path test: cycle through the non-primary paths you want to test, use the last request message sent to the peer. (Does not matter whether this request has already got a reply or not). To the peer it is going to look like a new request, which it is going to process and respond anyway, or a retransmission, for which it is going to retransmit the last response. The exception is if the last message is PATH_CHANGE. Here to avoid out of order arrival and change to a wrong path, you just have to wait for it to complete. If PATH_CHANGE fails, we would need to tear down the SA. But to recover from it we may need window size > 1 anyway. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 13:35:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29311 for ; Tue, 8 Mar 2005 13:35:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A0EEFFB27D; Tue, 8 Mar 2005 13:35:01 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F9FBFB262; Tue, 8 Mar 2005 13:34:58 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8496EFB266; Tue, 8 Mar 2005 13:34:56 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id E91AEFB246 for ; Tue, 8 Mar 2005 13:34:53 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28IYhU08453; Tue, 8 Mar 2005 20:34:46 +0200 (EET) X-Scanned: Tue, 8 Mar 2005 20:33:24 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j28IXOSM009445; Tue, 8 Mar 2005 20:33:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00wAI3zm; Tue, 08 Mar 2005 20:33:16 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28IDEU06955; Tue, 8 Mar 2005 20:13:14 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 20:13:10 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 20:13:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 20:12:58 +0200 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes thread-index: AcUj+up1SYGnFI5jT6m4Jnv5fPZb9AAAdJYwAALAyQA= From: To: , X-OriginalArrivalTime: 08 Mar 2005 18:13:10.0015 (UTC) FILETIME=[7C1808F0:01C5240A] 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: quoted-printable Timothy Liu writes: > How about this for a path test: cycle through the non-primary > paths you want to test, use the last request message sent to > the peer. (Does not matter whether this request has already > got a reply or not). To the peer it is going to look like a > new request, which it is going to process and respond anyway, > or a retransmission, for which it is going to retransmit the > last response. Yes. This would work perfectly if the peer never uses the src/dst addresses from the IP header for anything else except transmitting the reply. However, the MOBIKE protocol will use them, in some cases at least (and other IKEv2 extensions defined in the future might, too)....and thus there are some complications (in case the peer actually had not received the last message yet). > The exception is if the last message is PATH_CHANGE. Here to > avoid out of order arrival and change to a wrong path, you > just have to wait for it to complete. If PATH_CHANGE fails, we > would need to tear down the SA. But to recover from it we may > need window size > 1 anyway. I think this situation is actually quite important: usually you change paths because something just went down or something new came up, and this is precisely the time when it's most likely that other things go wrong, too. MOPO-IKE tries to recover from this situation even with window size 1 by adding a new IKEv2 message that is not constrained by the window size (since it's not part of any particular IKE_SA). Thus, we can use the new PATH_TEST message to find a working path even if the window was "full". After that, we of course have to retransmit the last message (if we had not received a reply to it yet), but if it was CHANGE_PATH message, then it will actually cause the traffic to be moved to the right path! (However, since we don't know whether it was the request or the reply that got lost, we have to send another CHANGE_PATH message to be sure.) There's also a second case when a separate PATH_TEST message is useful: when the current path works just fine, but it's not the path we'd actually like to use. We can use the PATH_TEST message to easily check whether the "preferred path" has become operational again without worrying about possibly disrupting anything happening on the current path. For instance, if the preferred path for some=20 strange reason (e.g., asymmetric routing combined with failure=20 somewhere, malfunctioning filtering device) works only in the=20 A-to-B direction, then just sending a DPD might cause B to move=20 the traffic there is NAT Traversal is enabled (which would=20 break things that were working just fine). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 13:52:54 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01160 for ; Tue, 8 Mar 2005 13:52:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3C1A4FB277; Tue, 8 Mar 2005 13:52:52 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D3855FB262; Tue, 8 Mar 2005 13:52:45 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0E59BFB266; Tue, 8 Mar 2005 13:52:44 -0500 (EST) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D46AFFB246 for ; Tue, 8 Mar 2005 13:52:42 -0500 (EST) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j28Ipc39028531 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Mar 2005 20:51:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j28Ipc5Q028528; Tue, 8 Mar 2005 20:51:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16941.62521.914270.460319@fireball.kivinen.iki.fi> Date: Tue, 8 Mar 2005 20:51:37 +0200 From: Tero Kivinen To: Subject: RE: [Mobike] MOPO and the 'ping' probes In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 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 Pasi.Eronen@nokia.com writes: > Yes. This would work perfectly if the peer never uses the > src/dst addresses from the IP header for anything else except > transmitting the reply. I disagree on that. > However, the MOBIKE protocol will use them, in some cases at There is no MOBIKE protocol yet. Your MOPO might be using them, and it must be doing things that way, but do not generalize that to MOBIKE protocol which is not yet even defined. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 14:01:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02248 for ; Tue, 8 Mar 2005 14:01:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9DC62FB282; Tue, 8 Mar 2005 14:01:04 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 19832FB266; Tue, 8 Mar 2005 14:01:01 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B81D5FB27C; Tue, 8 Mar 2005 14:00:59 -0500 (EST) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by machshav.com (Postfix) with ESMTP id C8661FB262 for ; Tue, 8 Mar 2005 14:00:58 -0500 (EST) Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 08 Mar 2005 11:00:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107763200"; d="scan'208"; a="239042439:sNHT21740696" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 11:00:58 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Tue, 8 Mar 2005 11:00:57 -0800 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes Thread-Index: AcUj+up1SYGnFI5jT6m4Jnv5fPZb9AAAdJYwAALAyQAAAjv4AA== From: "Timothy Liu" To: , X-OriginalArrivalTime: 08 Mar 2005 19:00:58.0252 (UTC) FILETIME=[29B244C0:01C52411] 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: quoted-printable The reason you can not transmit PATH_CHANGE message along another path is because there maybe NAT detection payload inside. Tim > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, March 08, 2005 10:13 AM > To: Timothy Liu; mobike@machshav.com > Subject: RE: [Mobike] MOPO and the 'ping' probes >=20 > Timothy Liu writes: >=20 > > How about this for a path test: cycle through the non-primary > > paths you want to test, use the last request message sent to > > the peer. (Does not matter whether this request has already > > got a reply or not). To the peer it is going to look like a > > new request, which it is going to process and respond anyway, > > or a retransmission, for which it is going to retransmit the > > last response. >=20 > Yes. This would work perfectly if the peer never uses the > src/dst addresses from the IP header for anything else except > transmitting the reply. >=20 > However, the MOBIKE protocol will use them, in some cases at > least (and other IKEv2 extensions defined in the future might, > too)....and thus there are some complications (in case the > peer actually had not received the last message yet). >=20 > > The exception is if the last message is PATH_CHANGE. Here to > > avoid out of order arrival and change to a wrong path, you > > just have to wait for it to complete. If PATH_CHANGE fails, we > > would need to tear down the SA. But to recover from it we may > > need window size > 1 anyway. >=20 > I think this situation is actually quite important: usually you > change paths because something just went down or something new > came up, and this is precisely the time when it's most likely > that other things go wrong, too. >=20 > MOPO-IKE tries to recover from this situation even with window > size 1 by adding a new IKEv2 message that is not constrained by > the window size (since it's not part of any particular IKE_SA). >=20 > Thus, we can use the new PATH_TEST message to find a working > path even if the window was "full". After that, we of course > have to retransmit the last message (if we had not received a > reply to it yet), but if it was CHANGE_PATH message, then it > will actually cause the traffic to be moved to the right path! > (However, since we don't know whether it was the request or the > reply that got lost, we have to send another CHANGE_PATH message > to be sure.) >=20 > There's also a second case when a separate PATH_TEST message is > useful: when the current path works just fine, but it's not the > path we'd actually like to use. We can use the PATH_TEST message > to easily check whether the "preferred path" has become operational > again without worrying about possibly disrupting anything happening > on the current path. For instance, if the preferred path for some > strange reason (e.g., asymmetric routing combined with failure > somewhere, malfunctioning filtering device) works only in the > A-to-B direction, then just sending a DPD might cause B to move > the traffic there is NAT Traversal is enabled (which would > break things that were working just fine). >=20 > Best regards, > Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 17:34:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26713 for ; Tue, 8 Mar 2005 17:34:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F0C67FB281; Tue, 8 Mar 2005 17:34:01 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8DDC5FB266; Tue, 8 Mar 2005 17:33:59 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D7D92FB27C; Tue, 8 Mar 2005 17:33:57 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id CA59FFB262 for ; Tue, 8 Mar 2005 17:33:56 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28MXss29382; Wed, 9 Mar 2005 00:33:54 +0200 (EET) X-Scanned: Wed, 9 Mar 2005 00:29:45 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j28MTjvU019409; Wed, 9 Mar 2005 00:29:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00uChaTv; Wed, 09 Mar 2005 00:28:46 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28MSjM12442; Wed, 9 Mar 2005 00:28:45 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 00:28:44 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 00:28:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Wed, 9 Mar 2005 00:28:43 +0200 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes thread-index: AcUkEIietsgJQO31QVOdkOn2Bmba6AAGzDQQ From: To: X-OriginalArrivalTime: 08 Mar 2005 22:28:44.0118 (UTC) FILETIME=[2FEE7760:01C5242E] 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: quoted-printable Tero Kivinen writes: > > Pasi.Eronen@nokia.com writes: >> Yes. This would work perfectly if the peer never uses the >> src/dst addresses from the IP header for anything else except >> transmitting the reply. >=20 > I disagree on that.=20 Perhaps saying "works perfectly" is exaggarating slightly, but using the latest request for path testing would certainly be easier if the src/dst address from IP header was not used for anything else than the reply. >> However, the MOBIKE protocol will use them, in some cases at >=20 > There is no MOBIKE protocol yet. Your MOPO might be using them,=20 > and it must be doing things that way, but do not generalize that=20 > to MOBIKE protocol which is not yet even defined.=20 This is not a feature of just MOPO, but any MOBIKE protocol that=20 works with NATs (and does not do Unilateral Self-Address Fixing). And yes, I know we still have not formally decided whether the MOBIKE protocol will work with NATs. But I don't think we should=20 even consider doing UNSAF, because that would certainly amount to=20 changing how IKEv2/IPsec NAT Traversal works.=20 Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Mar 8 17:41:34 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27343 for ; Tue, 8 Mar 2005 17:41:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 06B38FB262; Tue, 8 Mar 2005 17:41:32 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 02FC5FB266; Tue, 8 Mar 2005 17:41:29 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8B644FB27C; Tue, 8 Mar 2005 17:41:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id A6A51FB262 for ; Tue, 8 Mar 2005 17:41:24 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28MfMs12294; Wed, 9 Mar 2005 00:41:22 +0200 (EET) X-Scanned: Wed, 9 Mar 2005 00:38:31 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j28McVSt013946; Wed, 9 Mar 2005 00:38:31 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00vr3zzn; Wed, 09 Mar 2005 00:38:18 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28McGM19329; Wed, 9 Mar 2005 00:38:16 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 00:37:47 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 00:37:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] MOPO and the 'ping' probes Date: Wed, 9 Mar 2005 00:37:46 +0200 Message-ID: Thread-Topic: [Mobike] MOPO and the 'ping' probes thread-index: AcUj+up1SYGnFI5jT6m4Jnv5fPZb9AAAdJYwAALAyQAAAjv4AAAHY6eA From: To: , X-OriginalArrivalTime: 08 Mar 2005 22:37:46.0922 (UTC) FILETIME=[7377C8A0:01C5242F] 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: quoted-printable Hmm, you're right, retransmitting the PATH_CHANGE message=20 along another path may lead to unnecessarily enabling NAT=20 Traversal for a short period (before the second PATH_CHANGE=20 message disables it again, if in fact it's not needed). I'll mention this in the next version of MOPO-IKE draft. Best regards, Pasi > -----Original Message----- > From: timliu@juniper.net > Sent: Tuesday, March 08, 2005 9:01 PM > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: RE: [Mobike] MOPO and the 'ping' probes >=20 >=20 > The reason you can not transmit PATH_CHANGE message along another=20 > path is because there maybe NAT detection payload inside. >=20 > Tim >=20 > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Tuesday, March 08, 2005 10:13 AM > > To: Timothy Liu; mobike@machshav.com > > Subject: RE: [Mobike] MOPO and the 'ping' probes > >=20 > > Timothy Liu writes: > >=20 > > > How about this for a path test: cycle through the non-primary > > > paths you want to test, use the last request message sent to > > > the peer. (Does not matter whether this request has already > > > got a reply or not). To the peer it is going to look like a > > > new request, which it is going to process and respond anyway, > > > or a retransmission, for which it is going to retransmit the > > > last response. > >=20 > > Yes. This would work perfectly if the peer never uses the > > src/dst addresses from the IP header for anything else except > > transmitting the reply. > >=20 > > However, the MOBIKE protocol will use them, in some cases at > > least (and other IKEv2 extensions defined in the future might, > > too)....and thus there are some complications (in case the > > peer actually had not received the last message yet). > >=20 > > > The exception is if the last message is PATH_CHANGE. Here to > > > avoid out of order arrival and change to a wrong path, you > > > just have to wait for it to complete. If PATH_CHANGE fails, we > > > would need to tear down the SA. But to recover from it we may > > > need window size > 1 anyway. > >=20 > > I think this situation is actually quite important: usually you > > change paths because something just went down or something new > > came up, and this is precisely the time when it's most likely > > that other things go wrong, too. > >=20 > > MOPO-IKE tries to recover from this situation even with window > > size 1 by adding a new IKEv2 message that is not constrained by > > the window size (since it's not part of any particular IKE_SA). > >=20 > > Thus, we can use the new PATH_TEST message to find a working > > path even if the window was "full". After that, we of course > > have to retransmit the last message (if we had not received a > > reply to it yet), but if it was CHANGE_PATH message, then it > > will actually cause the traffic to be moved to the right path! > > (However, since we don't know whether it was the request or the > > reply that got lost, we have to send another CHANGE_PATH message > > to be sure.) > >=20 > > There's also a second case when a separate PATH_TEST message is > > useful: when the current path works just fine, but it's not the > > path we'd actually like to use. We can use the PATH_TEST message > > to easily check whether the "preferred path" has become operational > > again without worrying about possibly disrupting anything happening > > on the current path. For instance, if the preferred path for some > > strange reason (e.g., asymmetric routing combined with failure > > somewhere, malfunctioning filtering device) works only in the > > A-to-B direction, then just sending a DPD might cause B to move > > the traffic there is NAT Traversal is enabled (which would > > break things that were working just fine). > >=20 > > Best regards, > > Pasi >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 10 15:14:56 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00424 for ; Thu, 10 Mar 2005 15:14:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 45106FB28A; Thu, 10 Mar 2005 15:14:53 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DF32DFB27F; Thu, 10 Mar 2005 15:14:49 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 88247FB282; Thu, 10 Mar 2005 15:14:48 -0500 (EST) Received: from smtp815.mail.sc5.yahoo.com (smtp815.mail.sc5.yahoo.com [66.163.170.1]) by machshav.com (Postfix) with SMTP id D516DFB266 for ; Thu, 10 Mar 2005 15:14:47 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.54.166 with login) by smtp815.mail.sc5.yahoo.com with SMTP; 10 Mar 2005 20:14:46 -0000 Message-ID: <00c001c525ad$cd46b420$6601a8c0@adithya> From: "Mohan Parthasarathy" To: "MOBIKE Mailing List" Date: Thu, 10 Mar 2005 12:14:44 -0800 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 Subject: [Mobike] Storing single address in the SA. 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 There seems to be some confusion in the design draft regarding the single address storage in the SA. In section 5.2.1, The single IP address approach will not work if both peers happen to loose their IP address at the same time (due to, say, the failure of one of the links that both nodes are connected to). I can understand this. But In section 5.3, Note that if only a single address is stored in the peer address set (instead of an address list) we might end up in the case where it seems that both peers changed their addresses at the same time. This is something that the protocol must deal with. What does this mean ? Could someone clarify ? -thanks mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 10 17:25:31 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14054 for ; Thu, 10 Mar 2005 17:25:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5D91AFB28A; Thu, 10 Mar 2005 17:25:31 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5EA27FB27F; Thu, 10 Mar 2005 17:25:26 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9E1F0FB282; Thu, 10 Mar 2005 17:25:24 -0500 (EST) Received: from smtp801.mail.sc5.yahoo.com (smtp801.mail.sc5.yahoo.com [66.163.168.180]) by machshav.com (Postfix) with SMTP id 3E738FB266 for ; Thu, 10 Mar 2005 17:25:23 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.54.166 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 10 Mar 2005 22:25:22 -0000 Message-ID: <010501c525c0$0b30c020$6601a8c0@adithya> From: "Mohan Parthasarathy" To: References: <00f501c525bb$09bfbd40$6601a8c0@adithya> Subject: Re: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... Date: Thu, 10 Mar 2005 14:25:19 -0800 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 Pasi, A few questions/comments below.. > > Or in other words, the situation looks something like this: > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = f_A(List_A, List_B, src,dst = f_B(List_B, List_A, > local preferences, local preferences, > local info about local info about > connectivity, connectivity, > whatever) whatever) > > Where f_A() and f_B() can be basically anything. > > Pros and cons: > + Similar to SCTP > + Symmetric behavior may make sense when the situation is > otherwise reasonably symmetric (such as site-to-site VPNs) > By symmetric behavior, you mean both side selecing addresses as opposed to one side selecting the address. By"reasonably symmetric", you mean path between A and B is symmetric. So, symmetric behavior may not be desired always if there is no symmetry in the path. > + Handling partial connectivity and failures is reasonably clear: > if an address (interface) goes down, it is removed from the address > list. If the failure is in the "middle" (no connectivity, dpd fails), > the address lists don't change, but both parties choose address pairs > that work based on their own information. > - Failure detection and recovery has to be done by both parties, > possibly increasing complexity > - No guarantee that f_A() and f_B() choose the same address pair; > this might not be desirable in e.g. "mobile client" case. > In particular, Host A can't move the "downstream" traffic > (from B) to some particular interface (address) without > deleting all the other addresses from List_A (unless we make > restrictions about f_A/f_B). > Also in the case of firewall/NAT you may want the same address pair. > ----- > > Option 2: "Use the preferred/primary address" > > It seems that at least some text in previous versions of the > design draft assumed that the address listed first in > List_A/List_B is the "primary" or "preferred" address that will > get used. We get this alternative by defining a very simple > f_A() and f_B() for option 1. > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = List_A[1],List_B[1] src,dst = List_B[1],List_A[1] > So, what happens after the failure ? > Pros and cons: > + Simple > + Really simple for hosts that have a single static IP address > + Symmetric behavior may make sense when the situation is > otherwise reasonably symmetric (such as site-to-site VPNs) > + Same address pair used in both direction > - Connectivity information can be taken into account only > when determining List_A/List_B: traffic can be on a path > that both ends know to be unworkable > - For instance, if both A and B have one IPv4 address and one > IPv6 address (and there's no v4/v6 translation), it's not clear > how traffic would be moved from one to the another. It seems that > the order of List_B has to depend on order of List_A which depends > on the order of List_B and so on: unless the protocol specifies > some tie-breaking mechanism (limits how the parties can choose > the order of List_A/List_B), we could even get a ping-pong effect. > I don't understand this alternative at all. Could you please eloborate a little bit more ? > ----- > > Option 3: "Initiator decides" > > This is the approach chosen in MOPO-IKE. > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = f_A(List_A, List_B, > local preferences, > local info about > connectivity, > whatever) --> > > src,dst = received from A > > (BTW, in this approach Host B does not use List_A for updating > IPsec SAs at all; it's only used when List_B changes.) > > Pros and cons: > + Simple to handle partial connectivity and IPv4/v6 cases, without > the danger of ping-pong or other unspecified aspects > + Very simple for B (VPN gateway in "mobile client" case) > + In mobile client case, the client probably has a better > information about which addresses should be used. > + Same address pair used in both directions > + Easier to work with NATs and stateful firewalls > - Asymmetric behavior, less elegant perhaps It is possible that the path selected by the initiator does not work for the responder. > - A's preferences win even in symmetric situations (site-to-site) > > ----- > > Option 4: "Use the preferred/primary address if possible" > > We can clearly refine the approach of option 2 by including > slightly more complicated f_A() and f_B(). For instance, > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > src,dst = src,dst= > if (List_A[1],List_B[1] works) if(List_B[1],List_A[1] works) > List_A[1],List_B[1] List_B[1],List_A[1] > else else > f_A2(List_A, List_B, f_B2(List_B, List_A, > local preferences, local preferences, > local info about local info about > connectivity, connectivity, > whatever) whatever) > > Pros and cons: > + Often uses the same address pair in both directions > - Almost as complex as option 1 > - List_B still depends on List_A and vice versa in some > unspecified way, just like option 2 > > ----- > > There are of course many other variations of option 1 that place > more or less restrictions of what f_A/f_B do and/or place > restrictions on how List_A/List_B are chosen. > > But it seems that all the options involve some trade-offs and > none of them is clearly superior in all circumstances. But > according to my understand, options 2 and 4 have important > missing pieces (how A and B choose the order of List_A/List_B > based on the other) that are needed before their merits can be > fully assessed. On the other hand, options 1 and 3 both seem to > be working alternatives, since in them the hosts don't have to > agree on f_A/f_B or choosing the order of List_A/List_B. > I agree that the only meaningful options here are between (1) and (3). I don't know whether it is possible to choose between either of these options (Though (3) looks good, it still has a problem in choosing a potentially unusable path for the responder). One possibility is to include the ability of negotiation. For example, 1) Each of the nodes send their lists. 2) The initiator can propose to be the decision maker in choosing the new path. If the other end does not agree to it, both ends choose their own paths. Potentially, the responder can also choose to be the decision maker. Don't know whether it makes sense given the scenarios in the document. Any reason, why this option is not considered here ? -mohan > (BTW, most of the differences between the approaches occur only > when both parties have several addresses: otherwise, they're > pretty similar.) > > These were just some initial thoughts, and comments are very > welcome (as are variants of options 2 and 4 that fill in the > missing pieces, and other variants). > > Best regards, > Pasi > _______________________________________________ > 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 Mar 10 17:51:40 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16505 for ; Thu, 10 Mar 2005 17:51:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5DD75FB266; Thu, 10 Mar 2005 17:51:37 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A2181FB27F; Thu, 10 Mar 2005 17:51:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 36E28FB282; Thu, 10 Mar 2005 17:51:33 -0500 (EST) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by machshav.com (Postfix) with SMTP id 6CD90FB266 for ; Thu, 10 Mar 2005 17:51:32 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.54.166 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 10 Mar 2005 22:51:31 -0000 Message-ID: <011f01c525c3$b24a2060$6601a8c0@adithya> From: "Mohan Parthasarathy" To: References: <00fd01c525bb$1be9b3e0$6601a8c0@adithya> Subject: Re: [Mobike] Thoughts about issues 10/19: changing address vs. paths, and so on... Date: Thu, 10 Mar 2005 14:51:28 -0800 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 Pasi, A few questions below.. > > During the meeting today, Francis pointed out another possibly > option not really covered by 1-4. > > Option 5: "Peers decide the source addresses independently" > > Host A Host B > ------ ------- > > List_A = (decided by A) --> > > <-- List_B = (decided by B) > > dst = List_B[1] dst = List_A[1] > I am assuming that this changes later on when the current path fails. Right ? > src = f_A(List_A, List_B, src = f_B(List_B, List_A, > local preferences, local preferences, > local info about local info about > connectivity, connectivity, > whatever) whatever) > > Pros and cons: > + Reasonably simple > - No guarantee A-to-B and B-to-A traffic choose the same traffic > pair (which complicates things with stateful packet filters) > - Host A can't move the "upstream" traffic to some other interface > without co-operation from B (if we have partial connectivity). > For instance, if Host A has one IPv4 interface and one IPv6 interface, > A can't move the traffic to the IPv6 interface unless it somehow > convinces B to reorder List_B: how does this happen? (And if the Are you assuming that you always choose the first element (which is preferred) ? If A wants to move the traffic to IPv6 interface, why can't it just send the traffic to the IPv6 address in the B list ? I am confused as to why this is not possible. > answer is that List_B depends on List_A which depends on List B, > how does this work?) > - The same thing also applies to failures in the middle: even > if both parties' addresses and preferences stay the same, > somehow they must reorder either List_A, List_B, or both. > > (Hmm, I think that any option that is fully symmetric will have > these problems.. but there are certainly options that are > less asymmetric than option 3.) > Yes, if we want either end to control how the traffic flows, then we need assymetric behavior. -mohan > Best regards, > Pasi > _______________________________________________ > 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 Mar 10 21:09:53 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03590 for ; Thu, 10 Mar 2005 21:09:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3A632FB286; Thu, 10 Mar 2005 21:09:49 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86428FB27F; Thu, 10 Mar 2005 21:09:46 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1DC5DFB282; Thu, 10 Mar 2005 21:09:45 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id BEB75FB266 for ; Thu, 10 Mar 2005 21:09:43 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j2B29aN18949; Fri, 11 Mar 2005 03:09:36 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j2B29ZF5025785; Fri, 11 Mar 2005 03:09:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200503110209.j2B29ZF5025785@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Date: Fri, 11 Mar 2005 03:09:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: [Mobike] Pekka, HIP and Mobike 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 Jari, it seems your friend Pekka Nikander doesn't know what is Mobike because he doesn't include multi-homing in its scope... Has he read the Mobike charter (:-)? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Mar 11 10:06:03 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00528 for ; Fri, 11 Mar 2005 10:06:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 02B2FFB289; Fri, 11 Mar 2005 10:06:00 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9CEB3FB27F; Fri, 11 Mar 2005 10:05:57 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4F596FB282; Fri, 11 Mar 2005 10:05:55 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id D3A05FB266 for ; Fri, 11 Mar 2005 10:05:54 -0500 (EST) Received: from [70.212.252.211] (211.sub-70-212-252.myvzw.com [70.212.252.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2BF5G626124; Fri, 11 Mar 2005 07:05:17 -0800 (PST) Message-ID: <4231060C.9050705@isi.edu> Date: Thu, 10 Mar 2005 18:44:28 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko References: <4228AE74.8010208@piuha.net> In-Reply-To: <4228AE74.8010208@piuha.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mobike@machshav.com, Tschofenig Hannes Subject: [Mobike] Re: issue 16, recovering from problems that show just a lack of packets 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: , Content-Type: multipart/mixed; boundary="===============0987124545==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0987124545== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2737DE93E649FF6EDB1DAA3B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2737DE93E649FF6EDB1DAA3B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Joe, Hannes, > > We had a lengthy discussion about this in December. Here's what > I think the conclusion was: > > o MOBIKE can be affected by multiple sources of information, > both local (L2 tells it no longer is connected) and path-related > (DPD tells that we have a problem). > > o Retrying with new addresses (src and dst) is OK under such > problem situations. Recommend leaving specific address > selection to lower layers in the stack, e.g., unspecifed source > address when using API to IP. > > o Potential interference with dynamic routing protocols needs > to be noted & documented. > > --Jari That all seems reasonable to me. Joe --------------enig2737DE93E649FF6EDB1DAA3B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMQYME5f5cImnZrsRAtISAJ9hn+41YGebrns4+COesUzFwG2XyQCg7IVH QTtfYyO5D64zgIea22wpr7E= =1dep -----END PGP SIGNATURE----- --------------enig2737DE93E649FF6EDB1DAA3B-- --===============0987124545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============0987124545==-- From mobike-bounces@machshav.com Mon Mar 21 07:10:51 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26331 for ; Mon, 21 Mar 2005 07:10:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5582AFB27D; Mon, 21 Mar 2005 07:10:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B6E25FB24A; Mon, 21 Mar 2005 07:10:42 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 764E5FB266; Mon, 21 Mar 2005 07:10:41 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 7F54DFB246 for ; Mon, 21 Mar 2005 07:10:40 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2LCAbv17563 for ; Mon, 21 Mar 2005 14:10:38 +0200 (EET) X-Scanned: Mon, 21 Mar 2005 14:09:14 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j2LC9Efs020346 for ; Mon, 21 Mar 2005 14:09:14 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00FeSsBy; Mon, 21 Mar 2005 14:09:01 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2LC91U15622 for ; Mon, 21 Mar 2005 14:09:01 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Mar 2005 14:08:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Mar 2005 14:08:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2005 14:08:10 +0200 Message-ID: Thread-Topic: Draft minutes from IETF62 thread-index: AcUuDqZmYZGpcm3kTBiu+5gJr0mtTw== From: To: X-OriginalArrivalTime: 21 Mar 2005 12:08:11.0257 (UTC) FILETIME=[A6C97E90:01C52E0E] Subject: [Mobike] Draft minutes from IETF62 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: quoted-printable Hi, The draft minutes are now available from the MOBIKE page: http://www.vpnc.org/ietf-mobike/Minneapolis-05/ietf62_mobike_minutes.html= (Thanks to Maureen & Kristian for taking notes, and the=20 University of Oregon guys for the MP3 recordings.) I'd appreciate your corrections with a week or so; I'll then=20 submit the minutes to secretariat. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 24 08: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 IAA08980 for ; Thu, 24 Mar 2005 08:11:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 30873FB281; Thu, 24 Mar 2005 08:11:31 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3FF1DFB281; Thu, 24 Mar 2005 08:11:23 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DCEF9FB284; Thu, 24 Mar 2005 08:11:21 -0500 (EST) Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by machshav.com (Postfix) with ESMTP id 62A51FB27D for ; Thu, 24 Mar 2005 08:11:20 -0500 (EST) Received: from PAT4007 (PAT4007.int-evry.fr [157.159.103.77]) by molure.int-evry.fr (Postfix) with SMTP id 1A9E137856; Thu, 24 Mar 2005 14:02:12 +0100 (CET) Message-ID: <06ef01c53074$027ec850$4d679f9d@intevry.fr> From: "Khaled MASMOUDI" To: "MOBIKE Mailing List" References: <00fd01c525bb$1be9b3e0$6601a8c0@adithya> <011f01c525c3$b24a2060$6601a8c0@adithya> Date: Thu, 24 Mar 2005 14:18:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: Hossam Afifi , djamal.zeghlache@int-evry.fr Subject: [Mobike] ASWN 2005 CFP 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 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/ 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 --------------------------------------------------------------------- IMPORTANT DEADLINES Full paper submission: April 4, 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 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 Département Réseaux et Services Multimédia Mobiles (RS2M) 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 09:13:13 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00691 for ; Wed, 30 Mar 2005 09:13:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EDA2DFB294; Wed, 30 Mar 2005 09:13:10 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5F64EFB28B; Wed, 30 Mar 2005 09:13:09 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5716CFB291; Wed, 30 Mar 2005 09:13:07 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id EC500FB28A for ; Wed, 30 Mar 2005 09:13:04 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D4FC089862 for ; Wed, 30 Mar 2005 17:13:02 +0300 (EEST) Message-ID: <424AB3D9.60008@piuha.net> Date: Wed, 30 Mar 2005 17:12:41 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issues 18, 15, 6 -- return routability 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 Hello folks, We had an excellent discussion about most of the open MOBIKE issues in Minneapolis. The chairs would now like to run through the issues on the list, get even those not in the meeting involved, and attempt to come to a conclusion on each issue. Meeting slides are at http://www.vpnc.org/ietf-mobike/Minneapolis-05/ietf62_mobike_design.ppt We are starting with issues 18, 15, 6 in this e-mail. I'll summarize the meeting results on these issues, and state what the current working assumption appears to be. We 'd like determine what the final consensus is in two weeks, on April 13th, so please post your opinions as soon as possible so that we have time to complete the discussion. As usual, we'd like to get positive confirmation of a result rather than interpreting silence as agreement. So even if you don't have a problem with what is being proposed, it would be good to send an e-mail to the list saying that you are OK with the a particular a solution. So, issues 18, 15, and 6 are all related to if, when and how to do return routability tests. These are the primary defense mechanism against so called third party flooding attacks, where (perhaps a legitimate) party in the communication directs a stream of payload packets towards a victim. Note that flooding attacks are always possible, if not otherwise then by sending packets to the victim directly. The only remaining question is whether you can get some amplification out of this, e.g., by redirecting a stream that dies slowly when acks are not coming back. We don't need to do any better than what existing Internet already offers; we just need to ensure that we don't make the problem worse. We have already decided issue 6, which was about what kind of tests to use. The decision was to use a cookie-based approach, where the responding party can not fake the response unless he sees the original request. We are not re-opening that discussion. Issues 18 and 15 remain open. Issue 18 is about whether to include the tests at all, and issue 15 is about when to do them. The proposal that was discussed in IETF-62 was that it would be mandatory for a responding party to respond to an RR test (of course!), and that the initiation of an RR test would be configuration driven with default being "on". We had a discussion of whether to include also some indication of addresses in the certificates in this decision, and there seemed to be opinions on both sides. In any case, the standing proposal seems to be - Do the tests if configuration tells you to - Default is on - If the specific IP address can be found in the peer's certificate, you can skip the test Issue 18 is about when to do the tests, before or after you have moved the payload traffic stream. Again there seemed to be opinions on both sides. Before is more secure, after is faster. OTOH, in situations where you have well-behaving peers, as in most VPNs the efficiency may not be an issue if you turned this feature off to begin with. The proposal on the slides was - Do the tests before moving the payload stream. Let us know if these proposals work for you or if a different approach is needed. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 09:30:55 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02133 for ; Wed, 30 Mar 2005 09:30:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 00CE2FB2A2; Wed, 30 Mar 2005 09:30:52 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 75C92FB291; Wed, 30 Mar 2005 09:30:48 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BCF7FFB29B; Wed, 30 Mar 2005 09:30:46 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 258E7FB28B for ; Wed, 30 Mar 2005 09:30:46 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2DD7789862 for ; Wed, 30 Mar 2005 17:30:45 +0300 (EEST) Message-ID: <424AB7FF.3080408@piuha.net> Date: Wed, 30 Mar 2005 17:30:23 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 11 -- window size 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 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? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 15:19:31 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06374 for ; Wed, 30 Mar 2005 15:19:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0F362FB2A7; Wed, 30 Mar 2005 15:19:28 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 974CCFB29B; Wed, 30 Mar 2005 15:19:22 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 38C76FB2A3; Wed, 30 Mar 2005 15:19:21 -0500 (EST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id CA20AFB294 for ; Wed, 30 Mar 2005 15:19:19 -0500 (EST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2005 15:19:19 -0500 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 j2UKJGjI025156; Wed, 30 Mar 2005 15:19:16 -0500 (EST) Received: from stephanew2k02 ([10.21.106.181]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR68479; Wed, 30 Mar 2005 12:19:14 -0800 (PST) Message-Id: <200503302019.ABR68479@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Jari Arkko'" , Subject: RE: [Mobike] issues 18, 15, 6 -- return routability Date: Wed, 30 Mar 2005 15:19:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <424AB3D9.60008@piuha.net> Thread-Index: AcU1MtBYa/e7gYiORfCCK6+hltnK1AAMs5jA 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 Jari, I think the RR test should be done before the loss of connectivity. Before would quickly accomplish the goal of proving that the peer actually owns the IP address. If you wait until after the loss of connectivity, you'd have to source the RR using every interface you had configured, since you wouldn't be sure if your interface was actually working properly (or if it is the peer's interface that malfunctioned). This would exponentially increase the number of messages per interface. Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Jari Arkko > Sent: Wednesday, March 30, 2005 9:13 AM > To: mobike@machshav.com > Subject: [Mobike] issues 18, 15, 6 -- return routability > > > Hello folks, > > We had an excellent discussion about most of the open MOBIKE > issues in Minneapolis. The chairs would now like to run > through the issues on the list, get even those not in the > meeting involved, and attempt to come to a conclusion on each issue. > > Meeting slides are at > http://www.vpnc.org/ietf-mobike/Minneapolis-05/ietf62_mobike_d > esign.ppt > > We are starting with issues 18, 15, 6 in this e-mail. I'll > summarize the meeting results on these issues, and state what > the current working assumption appears to be. We 'd like > determine what the final consensus is in two weeks, on April > 13th, so please post your opinions as soon as possible so > that we have time to complete the discussion. As usual, we'd > like to get positive confirmation of a result rather than > interpreting silence as agreement. So even if you don't have > a problem with what is being proposed, it would be good to > send an e-mail to the list saying that you are OK with the a > particular a solution. > > So, issues 18, 15, and 6 are all related to if, when and how > to do return routability tests. These are the primary defense > mechanism against so called third party flooding attacks, > where (perhaps a legitimate) party in the communication > directs a stream of payload packets towards a victim. Note > that flooding attacks are always possible, if not otherwise > then by sending packets to the victim directly. > The only remaining question is whether you can get some > amplification out of this, e.g., by redirecting a stream that > dies slowly when acks are not coming back. We don't need to > do any better than what existing Internet already offers; we > just need to ensure that we don't make the problem worse. > > We have already decided issue 6, which > was about what kind of tests to use. The decision was to use > a cookie-based approach, where the responding party can not > fake the response unless he sees the original request. We are > not re-opening that discussion. > > Issues 18 and 15 remain open. Issue 18 is about whether to > include the tests at all, and issue 15 is about when to do them. > The proposal that was discussed in IETF-62 was that it would > be mandatory for a responding party to respond to an RR test > (of course!), and that the initiation of an RR test would be > configuration driven with default being "on". We had a > discussion of whether to include also some indication of > addresses in the certificates in this decision, and there > seemed to be opinions on both sides. In any case, the > standing proposal seems to be > > - Do the tests if configuration tells you to > - Default is on > - If the specific IP address can be found in the peer's > certificate, you can skip the test > > Issue 18 is about when to do the tests, before or after you > have moved the payload traffic stream. Again there seemed to > be opinions on both sides. Before is more secure, after is > faster. OTOH, in situations where you have well-behaving > peers, as in most VPNs the efficiency may not be an issue if > you turned this feature off to begin with. The proposal on > the slides was > > - Do the tests before moving the payload stream. > > Let us know if these proposals work for you or if a different > approach is needed. > > --Jari > > _______________________________________________ > 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 Mar 30 15:41:40 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08393 for ; Wed, 30 Mar 2005 15:41:40 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 721F1FB2A7; Wed, 30 Mar 2005 15:41:40 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C37C6FB29B; Wed, 30 Mar 2005 15:41:38 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 75D4EFB2A3; Wed, 30 Mar 2005 15:41:37 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id 68C3BFB294 for ; Wed, 30 Mar 2005 15:41:36 -0500 (EST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2005 16:01:40 -0500 X-IronPort-AV: i="3.91,135,1110171600"; d="scan'208"; a="42534083:sNHT26918880" 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 j2UKfVjI001207; Wed, 30 Mar 2005 15:41:31 -0500 (EST) Received: from stephanew2k02 ([10.21.106.181]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR69204; Wed, 30 Mar 2005 12:41:29 -0800 (PST) Message-Id: <200503302041.ABR69204@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Jari Arkko'" , Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 15:41:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <424AB7FF.3080408@piuha.net> Thread-Index: AcU1NggUtGn8+3FCTtKxVEbLl077tgAMKGkQ 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 I think we should expect implementations to support a window size > 1. I think eventually people will need to do this for things like DPDs, DELETEs, Notifies, rekey overlaps, etc... to work properly. Remember that the bakeoff implementations haven't been deployed yet. They haven't suffered the consequences of a very small window yet. Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Jari Arkko > Sent: Wednesday, March 30, 2005 9:30 AM > To: mobike@machshav.com > Subject: [Mobike] issue 11 -- window size > > > 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? > > --Jari > > > _______________________________________________ > 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 Mar 30 15:47:10 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09851 for ; Wed, 30 Mar 2005 15:47:10 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4406FFB2A6; Wed, 30 Mar 2005 15:47:08 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6127DFB29B; Wed, 30 Mar 2005 15:47:05 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9E188FB2A3; Wed, 30 Mar 2005 15:47:03 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by machshav.com (Postfix) with ESMTP id B4DC7FB294 for ; Wed, 30 Mar 2005 15:47:02 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2005 12:46:52 -0800 X-IronPort-AV: i="3.91,135,1110182400"; d="scan'208"; a="624451533:sNHT5308049042" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2UKklDr019351; Wed, 30 Mar 2005 12:46:47 -0800 (PST) Received: from ghuangx31 (dhcp-128-107-163-97.cisco.com [128.107.163.97]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDM06153; Wed, 30 Mar 2005 12:46:48 -0800 (PST) Message-Id: <200503302046.BDM06153@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: , "'Jari Arkko'" , Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 12:46:48 -0800 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: <200503302041.ABR69204@mira-kan-a.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU1NggUtGn8+3FCTtKxVEbLl077tgAMKGkQAAC6I3A= 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 I agree. I think it's reasonable to expect a window size > 1. -g > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Stephane Beaulieu > Sent: Wednesday, March 30, 2005 12:41 PM > To: 'Jari Arkko'; mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > I think we should expect implementations to support a window > size > 1. I think eventually people will need to do this for > things like DPDs, DELETEs, Notifies, rekey overlaps, etc... > to work properly. > > Remember that the bakeoff implementations haven't been > deployed yet. They haven't suffered the consequences of a > very small window yet. > > Stephane. > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com] On Behalf Of Jari Arkko > > Sent: Wednesday, March 30, 2005 9:30 AM > > To: mobike@machshav.com > > Subject: [Mobike] issue 11 -- window size > > > > > > 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? > > > > --Jari > > > > > > _______________________________________________ > > 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 Mar 30 16:07:51 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16953 for ; Wed, 30 Mar 2005 16:07:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7170BFB2A3; Wed, 30 Mar 2005 16:07:50 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3E8F9FB294; Wed, 30 Mar 2005 16:07:49 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0B701FB2A3; Wed, 30 Mar 2005 16:07:46 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id 6A9AEFB294 for ; Wed, 30 Mar 2005 16:07:45 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2UL7hRr012377; Wed, 30 Mar 2005 14:07:43 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2UL7hOp018433; Wed, 30 Mar 2005 16:07:43 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2UL7g8E022552; Wed, 30 Mar 2005 16:07:43 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2UL7gqB022551; Wed, 30 Mar 2005 16:07:42 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] issue 11 -- window size From: Bill Sommerfeld To: Geoffrey Huang In-Reply-To: <200503302046.BDM06153@mira-sjc5-b.cisco.com> References: <200503302046.BDM06153@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112216860.20951.390.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 16:07:41 -0500 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 On Wed, 2005-03-30 at 15:46, Geoffrey Huang wrote: > I agree. I think it's reasonable to expect a window size > 1. the issue is a bit more subtle than that: if mobike mobility requests (of whatever form) occupy ike request sequence space, then in order to avoid deadlocking during a move while there are other outstanding requests, mobike implementations will need to reserve at least the "last" request window slot for those requests at all times, effectively reducing the window at all other times by at least one request. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 16:22:01 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22575 for ; Wed, 30 Mar 2005 16:22:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 888E3FB2A6; Wed, 30 Mar 2005 16:21:55 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 53995FB29B; Wed, 30 Mar 2005 16:21:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 29D9CFB2A3; Wed, 30 Mar 2005 16:21:52 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 8A4CCFB294 for ; Wed, 30 Mar 2005 16:21:51 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2005 13:21:51 -0800 X-IronPort-AV: i="3.91,135,1110182400"; d="scan'208"; a="243140180:sNHT28501960" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2ULLggE014110; Wed, 30 Mar 2005 13:21:42 -0800 (PST) Received: from ghuangx31 (dhcp-128-107-163-97.cisco.com [128.107.163.97]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDM09850; Wed, 30 Mar 2005 13:21:47 -0800 (PST) Message-Id: <200503302121.BDM09850@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Bill Sommerfeld'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 13:21:47 -0800 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: <1112216860.20951.390.camel@thunk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU1bJyZ+7FCCfAcQ9OWdLzLPfquhAAAdbKg 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 Hm...interesting. I still think it's reasonable to expect a window size > 1. -g > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Wednesday, March 30, 2005 1:08 PM > To: Geoffrey Huang > Cc: stephane@cisco.com; 'Jari Arkko'; mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > On Wed, 2005-03-30 at 15:46, Geoffrey Huang wrote: > > I agree. I think it's reasonable to expect a window size > 1. > > the issue is a bit more subtle than that: if mobike mobility > requests (of whatever form) occupy ike request sequence > space, then in order to avoid deadlocking during a move while > there are other outstanding requests, mobike implementations > will need to reserve at least the "last" request window slot > for those requests at all times, effectively reducing the > window at all other times by at least one request. > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 16:37:17 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28044 for ; Wed, 30 Mar 2005 16:37:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 87A9FFB2A4; Wed, 30 Mar 2005 16:37:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DAEBDFB29B; Wed, 30 Mar 2005 16:37:12 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D86A1FB2A3; Wed, 30 Mar 2005 16:37:10 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id E8B81FB294 for ; Wed, 30 Mar 2005 16:37:09 -0500 (EST) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2005 16:57:16 -0500 X-IronPort-AV: i="3.91,135,1110171600"; d="scan'208"; a="42544132:sNHT120084404" 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 j2ULb51j011895; Wed, 30 Mar 2005 16:37:06 -0500 (EST) Received: from stephanew2k02 ([10.21.106.181]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR71097; Wed, 30 Mar 2005 13:37:04 -0800 (PST) Message-Id: <200503302137.ABR71097@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Bill Sommerfeld'" , "'Geoffrey Huang'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 16:37:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <1112216860.20951.390.camel@thunk> Thread-Index: AcU1bJyZg9JKeXWuQ6uRezF8DwXfJwAAkd4w Cc: mobike@machshav.com, "'Jari Arkko'" 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 That's a good point. This is only the case though if you assume that a mobility request should have a higher priority than a 'normal' request. That normal request, if deadlocked due to mobility change, I would think would eventually time out, thus clearing up the window for the mobility request to get through. Of course, that would cause loss of connectivity for the length of the time out, but then again, maybe that's the price you pay for having a small window. Perhaps the answer is that you don't timeout. Retransmit forever. But then the question becomes what do you do when a peer doesn't respond to a request. What do you do if the window is full. Can't send a DEL, or a DPD. Are you supposed to just retransmit forever, or silently drop the connection? Stephane. > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Wednesday, March 30, 2005 4:08 PM > To: Geoffrey Huang > Cc: stephane@cisco.com; 'Jari Arkko'; mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > On Wed, 2005-03-30 at 15:46, Geoffrey Huang wrote: > > I agree. I think it's reasonable to expect a window size > 1. > > the issue is a bit more subtle than that: if mobike mobility > requests (of whatever form) occupy ike request sequence > space, then in order to avoid deadlocking during a move while > there are other outstanding requests, mobike implementations > will need to reserve at least the "last" request window slot > for those requests at all times, effectively reducing the > window at all other times by at least one request. > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 16:45:12 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29646 for ; Wed, 30 Mar 2005 16:45:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2E927FB29B; Wed, 30 Mar 2005 16:45:10 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6D8DBFB29B; Wed, 30 Mar 2005 16:45:05 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F2B17FB2A3; Wed, 30 Mar 2005 16:45:03 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id 4E7A8FB294 for ; Wed, 30 Mar 2005 16:45:03 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2ULj2Rr010596; Wed, 30 Mar 2005 14:45:02 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2ULj2Op027187; Wed, 30 Mar 2005 16:45:02 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2ULj2t3022674; Wed, 30 Mar 2005 16:45:02 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2ULj16L022673; Wed, 30 Mar 2005 16:45:01 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] issue 11 -- window size From: Bill Sommerfeld To: stephane@cisco.com In-Reply-To: <200503302137.ABR71097@mira-kan-a.cisco.com> References: <200503302137.ABR71097@mira-kan-a.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112219099.20951.473.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 16:45:01 -0500 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 On Wed, 2005-03-30 at 16:37, Stephane Beaulieu wrote: > This is only the case though if you assume that a mobility request should > have a higher priority than a 'normal' request. That normal request, if > deadlocked due to mobility change, I would think would eventually time out, > thus clearing up the window for the mobility request to get through. it appears that IKEv2 doesn't work that way. quoting from draft-ietf-ipsec-ikev2-17.txt: An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests. In other words, if the responder stated its window size is N, then when the initiator needs to make a request X, it MUST wait until it has received responses to all requests up through request X-N. in other words, if you don't hear back from the peer at all, you can tear down the IKE association but you can't abandon a request in progress and keep going forward through the sequence space. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 16:58:03 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00958 for ; Wed, 30 Mar 2005 16:58:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 20446FB2A6; Wed, 30 Mar 2005 16:58:04 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 649DAFB29B; Wed, 30 Mar 2005 16:58:02 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 43D13FB2A3; Wed, 30 Mar 2005 16:58:01 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 81CB3FB28A for ; Wed, 30 Mar 2005 16:58:00 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2005 13:57:34 -0800 X-IronPort-AV: i="3.91,135,1110182400"; d="scan'208"; a="243163759:sNHT51191067924" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2ULvNgE021776; Wed, 30 Mar 2005 13:57:24 -0800 (PST) Received: from ghuangx31 (dhcp-128-107-163-97.cisco.com [128.107.163.97]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDM14298; Wed, 30 Mar 2005 13:57:26 -0800 (PST) Message-Id: <200503302157.BDM14298@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Bill Sommerfeld'" , Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 13:57:26 -0800 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: <1112219099.20951.473.camel@thunk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU1ceRvvjuPy/AWTVibEHtYyKQ+8QAAWhKQ 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 Tero pointed this out to me at the bakeoff. Suppose your peer's window size is 1; you send him a DPD (which he doesn't respond to). Eventually, you delete your SA, but you can't send him a request to do the same. The peer will eventually figure it out, hopefully. -g > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Wednesday, March 30, 2005 1:45 PM > To: stephane@cisco.com > Cc: 'Geoffrey Huang'; 'Jari Arkko'; mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > On Wed, 2005-03-30 at 16:37, Stephane Beaulieu wrote: > > This is only the case though if you assume that a mobility request > > should have a higher priority than a 'normal' request. That normal > > request, if deadlocked due to mobility change, I would think would > > eventually time out, thus clearing up the window for the > mobility request to get through. > > it appears that IKEv2 doesn't work that way. quoting from > draft-ietf-ipsec-ikev2-17.txt: > > An IKE endpoint MUST NOT exceed the peer's stated window size for > transmitted IKE requests. In other words, if the responder > stated its > window size is N, then when the initiator needs to make a > request X, > it MUST wait until it has received responses to all requests up > through request X-N. > > in other words, if you don't hear back from the peer at all, > you can tear down the IKE association but you can't abandon a > request in progress and keep going forward through the sequence space. > > - Bill > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 17:34:23 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03434 for ; Wed, 30 Mar 2005 17:34:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5840FFB2A7; Wed, 30 Mar 2005 17:34:20 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC7D9FB29B; Wed, 30 Mar 2005 17:34:17 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 161A7FB2A3; Wed, 30 Mar 2005 17:34:16 -0500 (EST) Received: from smtp803.mail.sc5.yahoo.com (smtp803.mail.sc5.yahoo.com [66.163.168.182]) by machshav.com (Postfix) with SMTP id 286ADFB294 for ; Wed, 30 Mar 2005 17:34:15 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.170 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 30 Mar 2005 22:29:50 -0000 Message-ID: <002d01c53577$fd6c22f0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , References: <424AB7FF.3080408@piuha.net> Subject: Re: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 14:29:48 -0800 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 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 > > 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? > When the message is sent outside the window, is it still protected with the IKE SA or not ? Even if the window size is greater than 1, the window may be filled up with previous messages. So, we are back to the same problem, right ? -mohan > --Jari > > > _______________________________________________ > 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 Mar 30 17:41:23 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03988 for ; Wed, 30 Mar 2005 17:41:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F19CFFB2A7; Wed, 30 Mar 2005 17:41:21 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A0821FB29B; Wed, 30 Mar 2005 17:41:19 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C1531FB2A3; Wed, 30 Mar 2005 17:41:17 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by machshav.com (Postfix) with ESMTP id 2FFA7FB294 for ; Wed, 30 Mar 2005 17:41:17 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2UMfGX8026101; Wed, 30 Mar 2005 15:41:16 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2UMfFOp010429; Wed, 30 Mar 2005 17:41:15 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2UMfFN0022817; Wed, 30 Mar 2005 17:41:15 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2UMfFZj022816; Wed, 30 Mar 2005 17:41:15 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Mobike] issue 11 -- window size From: Bill Sommerfeld To: Mohan Parthasarathy In-Reply-To: <002d01c53577$fd6c22f0$6501a8c0@adithya> References: <424AB7FF.3080408@piuha.net> <002d01c53577$fd6c22f0$6501a8c0@adithya> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112222474.20951.599.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 17:41:15 -0500 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 On Wed, 2005-03-30 at 17:29, Mohan Parthasarathy wrote: > When the message is sent outside the window, is it still protected > with the IKE SA or not ? ikev2 says you MUST NOT send a message outside the window. > Even if the window size is greater than 1, the window may be filled > up with previous messages. So, we are back to the same problem, right ? effectively, yes, unless you prereserve some chunk of the window for last-minute mobility. (I suspect that we may be better off adding a distinct sequence space for mobility requests, viewed as a slightly lower layer than the existing phase 2 requests). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 17:56:45 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05813 for ; Wed, 30 Mar 2005 17:56:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 35394FB2A4; Wed, 30 Mar 2005 17:56:45 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5438EFB29B; Wed, 30 Mar 2005 17:56:44 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8842AFB2A3; Wed, 30 Mar 2005 17:56:42 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id EC0E5FB294 for ; Wed, 30 Mar 2005 17:56:41 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2UMufRr001475; Wed, 30 Mar 2005 15:56:41 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2UMueQp027055; Wed, 30 Mar 2005 17:56:40 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2UMueTR022855; Wed, 30 Mar 2005 17:56:40 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2UMueK5022854; Wed, 30 Mar 2005 17:56:40 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Mobike] issue 11 -- window size From: Bill Sommerfeld To: Jari Arkko In-Reply-To: <424AB7FF.3080408@piuha.net> References: <424AB7FF.3080408@piuha.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112223399.20951.615.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 17:56:40 -0500 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 On Wed, 2005-03-30 at 09:30, Jari Arkko wrote: > 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? (I'm reading mail out of order) I don't have a problem with that. One encoding which makes this clear would be to allocate a new IKEv2 Exchange Type and specify that it has a distinct Message ID space distinct from the space used by the existing four types (see section 3.1 of draft-ietf-ipsec-ikev2-17.txt). (An alternative would be to grab one or more of the Flags bits, but they are somewhat more scarce..) - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 18:28:20 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09920 for ; Wed, 30 Mar 2005 18:28:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7E97EFB2A8; Wed, 30 Mar 2005 18:28:19 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DB7F9FB29B; Wed, 30 Mar 2005 18:28:17 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6C11DFB2A3; Wed, 30 Mar 2005 18:28:15 -0500 (EST) Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by machshav.com (Postfix) with SMTP id 879B0FB294 for ; Wed, 30 Mar 2005 18:28:14 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.170 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 30 Mar 2005 23:28:11 -0000 Message-ID: <007201c53580$23592d20$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Bill Sommerfeld" References: <424AB7FF.3080408@piuha.net><002d01c53577$fd6c22f0$6501a8c0@adithya> <1112222474.20951.599.camel@thunk> Subject: Re: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 15:28:10 -0800 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 > On Wed, 2005-03-30 at 17:29, Mohan Parthasarathy wrote: > > When the message is sent outside the window, is it still protected > > with the IKE SA or not ? > ikev2 says you MUST NOT send a message outside the window. > My understanding is that in Pasi's MOPO protocol, the PATH_TEST message is sent outside the window and also outside the IKE SA. (Perhaps someone could clarify that). Once you know the new PATH, retransmit all the messages in the existing window in the new PATH. Then, change an explicit PATH_CHANGE message. In this method, you needed only the *PATH_TEST* message outside the window (and also outside the SA). MOBIKE messages itself was sent within the window. Jari's question was about all MOBIKE messages i guess. If all of them needs to be sent outside the window, then defining its own message-id space makes sense i guess. > > Even if the window size is greater than 1, the window may be filled > > up with previous messages. So, we are back to the same problem, right ? > > effectively, yes, unless you prereserve some chunk of the window for > last-minute mobility. > > (I suspect that we may be better off adding a distinct sequence space > for mobility requests, viewed as a slightly lower layer than the > existing phase 2 requests). > Yes, MOBIKE can define its own space and the message-id can be carried in the payload itself i guess. -mohan > > > _______________________________________________ > 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 Mar 30 18:59:09 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12011 for ; Wed, 30 Mar 2005 18:59:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A000AFB2A4; Wed, 30 Mar 2005 18:59:06 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5F06CFB294; Wed, 30 Mar 2005 18:59:05 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 384EDFB29B; Wed, 30 Mar 2005 18:59:04 -0500 (EST) Received: from smtp815.mail.sc5.yahoo.com (smtp815.mail.sc5.yahoo.com [66.163.170.1]) by machshav.com (Postfix) with SMTP id 6B4D7FB27C for ; Wed, 30 Mar 2005 18:59:03 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.170 with login) by smtp815.mail.sc5.yahoo.com with SMTP; 30 Mar 2005 23:59:02 -0000 Message-ID: <011701c53584$727ce4b0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , References: <424AB3D9.60008@piuha.net> Subject: Re: [Mobike] issues 18, 15, 6 -- return routability Date: Wed, 30 Mar 2005 15:59:01 -0800 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 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 > > - Do the tests if configuration tells you to > - Default is on > - If the specific IP address can be found in the peer's certificate, > you can skip the test > I am okay with the first two. I must have missed the discussion on the address found in the peer's certificate.. What address ? Can you give some more details ? > Issue 18 is about when to do the tests, before or after you > have moved the payload traffic stream. Again there seemed > to be opinions on both sides. Before is more secure, after > is faster. OTOH, in situations where you have well-behaving > peers, as in most VPNs the efficiency may not be an issue > if you turned this feature off to begin with. The proposal on the slides > was > > - Do the tests before moving the payload stream. > Sounds good. -mohan > Let us know if these proposals work for you or if a different > approach is needed. > > --Jari > > _______________________________________________ > 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 Mar 30 21:11:03 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24093 for ; Wed, 30 Mar 2005 21:11:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F145EFB2A8; Wed, 30 Mar 2005 21:11:02 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 23072FB2A4; Wed, 30 Mar 2005 21:10:56 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 95356FB2A6; Wed, 30 Mar 2005 21:10:54 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id 7C8D5FB29B for ; Wed, 30 Mar 2005 21:10:53 -0500 (EST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2005 21:31:01 -0500 X-IronPort-AV: i="3.91,136,1110171600"; d="scan'208"; a="42577027:sNHT28286536" 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 j2V2AnjI016381; Wed, 30 Mar 2005 21:10:50 -0500 (EST) Received: from stephanew2k02 ([10.21.107.166]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR79190; Wed, 30 Mar 2005 18:10:46 -0800 (PST) Message-Id: <200503310210.ABR79190@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Bill Sommerfeld'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 21:10:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <1112219099.20951.473.camel@thunk> Thread-Index: AcU1ceRvIB+N9+q0SYGFGh9690JfpQAIw4og Cc: mobike@machshav.com, "'Jari Arkko'" 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 Thanks for the clarification. Given this, then I'm wondering how the connectivity check would work when we're trying to determine which pair of interfaces to switch to. Presumably it goes like this... Say PeerA, and PeerB, both with a window size = 2. PeerA (A1, A2) <--> PeerB (B1, B2, B3) A1 <--> B1 stops working (more precisely, some network devices near A1 stops working) 1 - PeerA sends a DPD (thus occupying 1 window slot) 2 - PeerA retransmits DPD a few times. 3 - PeerA sends a connectivity check A1->B2 (thus occupying a 2nd window slot) 4 - PeerA wants to send a connectivity check A1->B3, but has no window room left. Question: Would the connectivity check just be a replay of the DPD in 1? (thus re-using the window slot?) or would it occupy a new window slot? Stephane. > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Wednesday, March 30, 2005 4:45 PM > To: stephane@cisco.com > Cc: 'Geoffrey Huang'; 'Jari Arkko'; mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > On Wed, 2005-03-30 at 16:37, Stephane Beaulieu wrote: > > This is only the case though if you assume that a mobility request > > should have a higher priority than a 'normal' request. That normal > > request, if deadlocked due to mobility change, I would think would > > eventually time out, thus clearing up the window for the > mobility request to get through. > > it appears that IKEv2 doesn't work that way. quoting from > draft-ietf-ipsec-ikev2-17.txt: > > An IKE endpoint MUST NOT exceed the peer's stated window size for > transmitted IKE requests. In other words, if the responder > stated its > window size is N, then when the initiator needs to make a > request X, > it MUST wait until it has received responses to all requests up > through request X-N. > > in other words, if you don't hear back from the peer at all, > you can tear down the IKE association but you can't abandon a > request in progress and keep going forward through the sequence space. > > - Bill > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 21:32:22 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25772 for ; Wed, 30 Mar 2005 21:32:21 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 507CAFB2A6; Wed, 30 Mar 2005 21:32:20 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DD28BFB29B; Wed, 30 Mar 2005 21:32:17 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4FA4CFB2A4; Wed, 30 Mar 2005 21:32:16 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 4FFB7FB277 for ; Wed, 30 Mar 2005 21:32:15 -0500 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2V31r121054; Wed, 30 Mar 2005 19:01:53 -0800 X-mProtect: <200503310301> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpde5KFWa; Wed, 30 Mar 2005 19:01:51 PST Message-ID: <424B611E.8010505@iprg.nokia.com> Date: Wed, 30 Mar 2005 18:31:58 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <424AB3D9.60008@piuha.net> In-Reply-To: <424AB3D9.60008@piuha.net> 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 Jari Arkko wrote: > > > Issues 18 and 15 remain open. Issue 18 is about whether to > include the tests at all, and issue 15 is about when to do them. > The proposal that was discussed in IETF-62 was that it would > be mandatory for a responding party to respond to an RR > test (of course!), and that the initiation of an RR test would be > configuration driven with default being "on". We had a discussion > of whether to include also some indication of addresses in the > certificates in this decision, and there seemed to be opinions on > both sides. In any case, the standing proposal seems to be > > - Do the tests if configuration tells you to the configuration could be in many different ways, right? for example, even if the configuration on a VPN gateway is to perform the test, the configuration could further say, perform the text only when the traffic to a particular address exceeds a certain volume? basically I see the configuration as internal to the node. It could say - just perform the test for everyone, everytime - exclude this list of nodes for return routability tests - perform the test if the traffic exceeds a certain volume - and so on.... do we want all of the above to be allowed, or just a simple perform the test/don't perform the test? > - Default is on okay. > - If the specific IP address can be found in the peer's certificate, > you can skip the test how do dynamic addresses get into the certificate? I think I missed the discussion. maybe, I should look in the archives. > Issue 18 is about when to do the tests, before or after you > have moved the payload traffic stream. Again there seemed > to be opinions on both sides. Before is more secure, after > is faster. OTOH, in situations where you have well-behaving > peers, as in most VPNs the efficiency may not be an issue > if you turned this feature off to begin with. The proposal on the slides > was > > - Do the tests before moving the payload stream. sounds good. Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 23:48:50 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07316 for ; Wed, 30 Mar 2005 23:48:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3F0DDFB2A9; Wed, 30 Mar 2005 23:48:50 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0819BFB2A6; Wed, 30 Mar 2005 23:48:49 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F04DBFB2A7; Wed, 30 Mar 2005 23:48:46 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id EA33AFB29B for ; Wed, 30 Mar 2005 23:48:45 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 46B4389862; Thu, 31 Mar 2005 07:48:44 +0300 (EEST) Message-ID: <424B8117.3080206@piuha.net> Date: Thu, 31 Mar 2005 07:48:23 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <424AB3D9.60008@piuha.net> <424B611E.8010505@iprg.nokia.com> In-Reply-To: <424B611E.8010505@iprg.nokia.com> 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 Vijay Devarapalli wrote: >> >> - Do the tests if configuration tells you to > > > the configuration could be in many different ways, right? for > example, even if the configuration on a VPN gateway is to > perform the test, the configuration could further say, perform > the text only when the traffic to a particular address exceeds > a certain volume? basically I see the configuration as internal > to the node. It could say > - just perform the test for everyone, everytime > - exclude this list of nodes for return routability tests > - perform the test if the traffic exceeds a certain volume > - and so on.... > > do we want all of the above to be allowed, or just a simple > perform the test/don't perform the test? Yes. I guess what we are saying that you must at least have an on/off config knob... but a particular implementation could have a fancier scheme. I agree that its largely internal, and hard to standarize what the "fancier" stuff is. >> - If the specific IP address can be found in the peer's certificate, >> you can skip the test > > > how do dynamic addresses get into the certificate? I think > I missed the discussion. maybe, I should look in the archives. > They don't. You could only do this between stationary gateways. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 23:54:19 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07560 for ; Wed, 30 Mar 2005 23:54:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E8379FB2AA; Wed, 30 Mar 2005 23:54:17 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 895C6FB2A6; Wed, 30 Mar 2005 23:54:15 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 46199FB2A7; Wed, 30 Mar 2005 23:54:14 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2B4F5FB29B for ; Wed, 30 Mar 2005 23:54:13 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 492CD89862; Thu, 31 Mar 2005 07:54:12 +0300 (EEST) Message-ID: <424B825F.40409@piuha.net> Date: Thu, 31 Mar 2005 07:53:51 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stephane@cisco.com Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <200503302019.ABR68479@mira-kan-a.cisco.com> In-Reply-To: <200503302019.ABR68479@mira-kan-a.cisco.com> 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 Stephane, >I think the RR test should be done before the loss of connectivity. > >Before would quickly accomplish the goal of proving that the peer actually >owns the IP address. If you wait until after the loss of connectivity, >you'd have to source the RR using every interface you had configured, since >you wouldn't be sure if your interface was actually working properly (or if >it is the peer's interface that malfunctioned). This would exponentially >increase the number of messages per interface. > > I think you interpreted the "before/after" distinction slightly differently that what had originally thought. I was asking whether we do the test before the traffic stream is moved, you are asking whether to do the test before the nodes move. Both are valid questions, but I was assuming that nodes just happen to move, and that we don't necessarily always know that this happens before its already done. Of course, a MOBIKE node that knows its address is going to go bad soon can and should start using a new address. But I don't think we can guarantee this is known in all cases. (But if we know we are going to move, we don't need to RR every address, just the one that we are going to use. RR isn't need to test reachability, my understanding is that some kind of probing would take place prior to that. For instance, when a client moves, it should probably probe connectivity to the SGW in order to make sure its new address works and in order to punch a hole to the NAT mappings. Then it can tell SGW that this is the new address, and the SGW can perform an RR test to verify that the new address was indeed what was claimed.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 23:56:58 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07744 for ; Wed, 30 Mar 2005 23:56:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 80A2EFB2A9; Wed, 30 Mar 2005 23:56:58 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7ED15FB2A6; Wed, 30 Mar 2005 23:56:57 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B7C92FB2A7; Wed, 30 Mar 2005 23:56:55 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1D789FB29B for ; Wed, 30 Mar 2005 23:56:55 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6860A89862; Thu, 31 Mar 2005 07:56:54 +0300 (EEST) Message-ID: <424B8301.3060509@piuha.net> Date: Thu, 31 Mar 2005 07:56:33 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] issues 18, 15, 6 -- return routability References: <424AB3D9.60008@piuha.net> <011701c53584$727ce4b0$6501a8c0@adithya> In-Reply-To: <011701c53584$727ce4b0$6501a8c0@adithya> 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 Mohan Parthasarathy wrote: > > > > >> - Do the tests if configuration tells you to >> - Default is on >> - If the specific IP address can be found in the peer's certificate, >>you can skip the test >> >> >> >I am okay with the first two. I must have missed the discussion on the >address found in the peer's certificate.. What address ? Can you give >some more details ? > > This is what the design draft said: o The addresses a peer is using are part of a certificate. [RFC3554] introduced this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses in the certificate. (But the use of certificates in this manner seemed to be a bit controversial in the meeting, and this list discussion seems to ask questions about it too. We might also consider the certificate stuff as part of Vijay's "advanced configuration", i.e., possible but implementation dependent behaviour.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Mar 30 23:59:27 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07956 for ; Wed, 30 Mar 2005 23:59:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4EED9FB2AE; Wed, 30 Mar 2005 23:59:27 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CC504FB2A7; Wed, 30 Mar 2005 23:59:24 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E351BFB2A8; Wed, 30 Mar 2005 23:59:22 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 62D0CFB277 for ; Wed, 30 Mar 2005 23:59:22 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 82C4089862; Thu, 31 Mar 2005 07:59:21 +0300 (EEST) Message-ID: <424B8394.20504@piuha.net> Date: Thu, 31 Mar 2005 07:59:00 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Mobike] issue 11 -- window size References: <424AB7FF.3080408@piuha.net> <002d01c53577$fd6c22f0$6501a8c0@adithya> In-Reply-To: <002d01c53577$fd6c22f0$6501a8c0@adithya> 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 Mohan, >When the message is sent outside the window, is it still protected >with the IKE SA or not ? > > Yes, it should be. >Even if the window size is greater than 1, the window may be filled >up with previous messages. So, we are back to the same problem, right ? > > Potentially yes, see my next post. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 00:03:44 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08277 for ; Thu, 31 Mar 2005 00:03:43 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DD549FB291; Thu, 31 Mar 2005 00:03:43 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 21994FB2A6; Thu, 31 Mar 2005 00:03:39 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EBEECFB2A7; Thu, 31 Mar 2005 00:03:37 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 5B27BFB291 for ; Thu, 31 Mar 2005 00:03:37 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A213F89862; Thu, 31 Mar 2005 08:03:36 +0300 (EEST) Message-ID: <424B8493.2050009@piuha.net> Date: Thu, 31 Mar 2005 08:03:15 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stephane@cisco.com Subject: Re: [Mobike] issue 11 -- window size References: <200503310210.ABR79190@mira-kan-a.cisco.com> In-Reply-To: <200503310210.ABR79190@mira-kan-a.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Bill Sommerfeld'" , 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 Stephane Beaulieu wrote: >Question: >Would the connectivity check just be a replay of the DPD in 1? (thus >re-using the window slot?) or would it occupy a new window slot? > > That's a good question. We have to prepare also for the possibility that more than a single change of connectivity happens very fast. So if we have filled the window up with, say, N-2 requests already, does that mean that we are limited to at most 2 MOBIKE related requests at this time, whether those are due to trying multiple addresses or due to yet another change in connectivity? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 00:05:25 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08513 for ; Thu, 31 Mar 2005 00:05:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AF31DFB2AA; Thu, 31 Mar 2005 00:05:24 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3E64DFB2A7; Thu, 31 Mar 2005 00:05:23 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 972E1FB2A6; Thu, 31 Mar 2005 00:05:21 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id F17BBFB27C for ; Thu, 31 Mar 2005 00:05:20 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 28DCA89862; Thu, 31 Mar 2005 08:05:20 +0300 (EEST) Message-ID: <424B84FB.1030309@piuha.net> Date: Thu, 31 Mar 2005 08:04:59 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Mobike] issue 11 -- window size References: <424AB7FF.3080408@piuha.net> <1112223399.20951.615.camel@thunk> In-Reply-To: <1112223399.20951.615.camel@thunk> 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 Bill Sommerfeld wrote: >On Wed, 2005-03-30 at 09:30, Jari Arkko wrote: > > >>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? >> >> > >(I'm reading mail out of order) > >I don't have a problem with that. > >One encoding which makes this clear would be to allocate a new IKEv2 >Exchange Type and specify that it has a distinct Message ID space >distinct from the space used by the existing four types (see section 3.1 >of draft-ietf-ipsec-ikev2-17.txt). > > This would work for me. But I'd still like to understand what happens when we have to do several MOBIKE requests in this new space before we get an answer from the peer, are we bounded by some upper limit, or can we do any number of operations? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 00:51:59 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12387 for ; Thu, 31 Mar 2005 00:51:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0E528FB2A9; Thu, 31 Mar 2005 00:52:00 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A9BCFFB2A6; Thu, 31 Mar 2005 00:51:58 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C9C57FB2A7; Thu, 31 Mar 2005 00:51:57 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 0134CFB29B for ; Thu, 31 Mar 2005 00:51:57 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2005 21:51:56 -0800 X-IronPort-AV: i="3.91,136,1110182400"; d="scan'208"; a="243350203:sNHT27123584" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2V5psDr014946; Wed, 30 Mar 2005 21:51:54 -0800 (PST) Received: from ghuangx31 ([10.32.227.25]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDM55970; Wed, 30 Mar 2005 21:51:53 -0800 (PST) Message-Id: <200503310551.BDM55970@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Bill Sommerfeld'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Wed, 30 Mar 2005 21:51:51 -0800 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: <1112223399.20951.615.camel@thunk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU1e+UMwgNDn4SATaWHmQIdG0DQRQAOONQw 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 > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Bill Sommerfeld > Sent: Wednesday, March 30, 2005 2:57 PM > To: Jari Arkko > Cc: mobike@machshav.com > Subject: Re: [Mobike] issue 11 -- window size > > On Wed, 2005-03-30 at 09:30, Jari Arkko wrote: > > 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? > > (I'm reading mail out of order) > > I don't have a problem with that. > > One encoding which makes this clear would be to allocate a > new IKEv2 Exchange Type and specify that it has a distinct > Message ID space distinct from the space used by the existing > four types (see section 3.1 of draft-ietf-ipsec-ikev2-17.txt). I'm still considering this, but at the moment, I don't like this. Granted, it's unlikely two IKE peers would ever exhaust the message ID space, so reserving a portion of this space shouldn't cause us to run out of "regular" IKEv2 message IDs. However, an implementation might set its window size to 5 because it really does only want to handle 5 messages at a time. So now what if we have this distinct message ID space, and the implementation needs to consider the fact that it can only handle 5 messages. So it needs to split this between "regular" IKE messages and MOBIKE messages? I prefer your earlier suggestion of reserving one or two message IDs from the window for mobility purposes. Consider a roaming client that gets a notify from a security gateway (SGW) saying the SGW's window size is 5. The client should know that it's capable of mobility and consequently reserve a message ID for MOBIKE messages. Just because a peer sends a notification about a window size doesn't mean that an implementation needs to fill up the window. -g > (An alternative would be to grab one or more of the Flags > bits, but they are somewhat more scarce..) > > - Bill > > > _______________________________________________ > 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 Mar 31 10:44:07 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05010 for ; Thu, 31 Mar 2005 10:44:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B8C0CFB2AA; Thu, 31 Mar 2005 10:44:01 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8D076FB294; Thu, 31 Mar 2005 10:44:00 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AF27CFB2A8; Thu, 31 Mar 2005 10:43:59 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 31653FB282 for ; Thu, 31 Mar 2005 10:43:59 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VFhugv049312; Thu, 31 Mar 2005 07:43:57 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503310551.BDM55970@mira-sjc5-b.cisco.com> References: <200503310551.BDM55970@mira-sjc5-b.cisco.com> Date: Thu, 31 Mar 2005 07:43:54 -0800 To: "Geoffrey Huang" , "'Bill Sommerfeld'" , "'Jari Arkko'" From: Paul Hoffman Subject: RE: [Mobike] issue 11 -- window size Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote: >So it needs to >split this between "regular" IKE messages and MOBIKE messages? Not "split", but "allow enough extra for MOBIKE". >I prefer your earlier suggestion of reserving one or two message IDs from >the window for mobility purposes. Consider a roaming client that gets a >notify from a security gateway (SGW) saying the SGW's window size is 5. The >client should know that it's capable of mobility and consequently reserve a >message ID for MOBIKE messages. Just because a peer sends a notification >about a window size doesn't mean that an implementation needs to fill up the >window. That sounds good. The question is: how many should we suggest to reserve? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 10:57:54 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06135 for ; Thu, 31 Mar 2005 10:57:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CF2AFFB2AA; Thu, 31 Mar 2005 10:57:52 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 59E9FFB2A8; Thu, 31 Mar 2005 10:57:50 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 54768FB2A9; Thu, 31 Mar 2005 10:57:48 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 8C584FB2A6 for ; Thu, 31 Mar 2005 10:57:47 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2005 07:57:26 -0800 X-IronPort-AV: i="3.91,138,1110182400"; d="scan'208"; a="243572377:sNHT2498890296" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VFvLgE003159; Thu, 31 Mar 2005 07:57:21 -0800 (PST) Received: from ghuangx31 ([10.32.227.25]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDM85750; Thu, 31 Mar 2005 07:57:22 -0800 (PST) Message-Id: <200503311557.BDM85750@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Paul Hoffman'" , "'Bill Sommerfeld'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 07:57:22 -0800 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU2CI4BazBvSIqbTMqAFRQ0cDRUZQAAbTMA 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 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, March 31, 2005 7:44 AM > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko' > Cc: mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote: > >So it needs to > >split this between "regular" IKE messages and MOBIKE messages? > > Not "split", but "allow enough extra for MOBIKE". > > >I prefer your earlier suggestion of reserving one or two message IDs > >from the window for mobility purposes. Consider a roaming > client that > >gets a notify from a security gateway (SGW) saying the SGW's window > >size is 5. The client should know that it's capable of mobility and > >consequently reserve a message ID for MOBIKE messages. Just > because a > >peer sends a notification about a window size doesn't mean that an > >implementation needs to fill up the window. > > That sounds good. The question is: how many should we suggest > to reserve? Wouldn't one be sufficient for the address update notification? -g > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 11:02:29 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06515 for ; Thu, 31 Mar 2005 11:02:28 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1A4F5FB2AB; Thu, 31 Mar 2005 11:02:29 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4B81DFB2A8; Thu, 31 Mar 2005 11:02:28 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3A480FB2A9; Thu, 31 Mar 2005 11:02:26 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by machshav.com (Postfix) with ESMTP id D9470FB282 for ; Thu, 31 Mar 2005 11:02:24 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2VG2NX8029090; Thu, 31 Mar 2005 09:02:23 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2VG2NQp012147; Thu, 31 Mar 2005 11:02:23 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2VG2NdV027335; Thu, 31 Mar 2005 11:02:23 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2VG2MUW027334; Thu, 31 Mar 2005 11:02:22 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] issue 11 -- window size From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: <200503310551.BDM55970@mira-sjc5-b.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112284941.27244.0.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 31 Mar 2005 11:02:21 -0500 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 On Thu, 2005-03-31 at 10:43, Paul Hoffman wrote: > The question is: how many should we suggest to reserve? we have no idea how many will be needed until we design the rest of the protocol. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 12:22:50 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13672 for ; Thu, 31 Mar 2005 12:22:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C1164FB2AD; Thu, 31 Mar 2005 12:22:48 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 84218FB2A8; Thu, 31 Mar 2005 12:22:45 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D308DFB2A9; Thu, 31 Mar 2005 12:22:43 -0500 (EST) Received: from smtp801.mail.sc5.yahoo.com (smtp801.mail.sc5.yahoo.com [66.163.168.180]) by machshav.com (Postfix) with SMTP id 138E9FB2A6 for ; Thu, 31 Mar 2005 12:22:43 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.234 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 31 Mar 2005 17:22:41 -0000 Message-ID: <005a01c53616$3eab20b0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Bill Sommerfeld" , "Paul Hoffman" References: <200503310551.BDM55970@mira-sjc5-b.cisco.com> <1112284941.27244.0.camel@thunk> Subject: Re: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 09:22:40 -0800 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 Why are we reserving from the existing space ? Why not have its own space ? -mohan ----- Original Message ----- From: "Bill Sommerfeld" To: "Paul Hoffman" Cc: ; "'Jari Arkko'" Sent: Thursday, March 31, 2005 8:02 AM Subject: RE: [Mobike] issue 11 -- window size > On Thu, 2005-03-31 at 10:43, Paul Hoffman wrote: > > The question is: how many should we suggest to reserve? > > we have no idea how many will be needed until we design the rest of the > protocol. > _______________________________________________ > 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 Mar 31 12:35:21 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14737 for ; Thu, 31 Mar 2005 12:35:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A6B3FFB2AC; Thu, 31 Mar 2005 12:35:18 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5B67BFB282; Thu, 31 Mar 2005 12:35:16 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4EFF9FB2A9; Thu, 31 Mar 2005 12:35:14 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by machshav.com (Postfix) with ESMTP id 8BF7FFB27C for ; Thu, 31 Mar 2005 12:35:13 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2005 09:35:13 -0800 X-IronPort-AV: i="3.91,138,1110182400"; d="scan'208"; a="624747436:sNHT32299422" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VHZAgE012763; Thu, 31 Mar 2005 09:35:11 -0800 (PST) Received: from ghuangx31 ([10.32.227.25]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDM96181; Thu, 31 Mar 2005 09:35:06 -0800 (PST) Message-Id: <200503311735.BDM96181@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Mohan Parthasarathy'" , "'Bill Sommerfeld'" , "'Paul Hoffman'" Subject: RE: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 09:35:06 -0800 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: <005a01c53616$3eab20b0$6501a8c0@adithya> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU2FmrdNDzYHe8dRz2nY2cnyjqJuwAAVfsQ 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 Because then you would need to keep track of too many lists of messages. Currently, we already need to keep track of the window of messages I send to the peer, as well as a window of messages the peer sends to us. If we use a separate message ID space, we would need to keep those two windows, and on top of that, we'd need to keep another 2 just for the MOBIKE exchange. -g > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Mohan Parthasarathy > Sent: Thursday, March 31, 2005 9:23 AM > To: Bill Sommerfeld; Paul Hoffman > Cc: 'Jari Arkko'; mobike@machshav.com > Subject: Re: [Mobike] issue 11 -- window size > > Why are we reserving from the existing space ? Why not have > its own space ? > > -mohan > > ----- Original Message ----- > From: "Bill Sommerfeld" > To: "Paul Hoffman" > Cc: ; "'Jari Arkko'" > Sent: Thursday, March 31, 2005 8:02 AM > Subject: RE: [Mobike] issue 11 -- window size > > > > On Thu, 2005-03-31 at 10:43, Paul Hoffman wrote: > > > The question is: how many should we suggest to reserve? > > > > we have no idea how many will be needed until we design the > rest of the > > protocol. > > _______________________________________________ > > 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 Mar 31 12:37:43 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14990 for ; Thu, 31 Mar 2005 12:37:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AC489FB2B3; Thu, 31 Mar 2005 12:37:38 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B6DEFFB2AB; Thu, 31 Mar 2005 12:37:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ADC27FB2AD; Thu, 31 Mar 2005 12:37:32 -0500 (EST) Received: from smtp804.mail.sc5.yahoo.com (smtp804.mail.sc5.yahoo.com [66.163.168.183]) by machshav.com (Postfix) with SMTP id F0EF5FB2A9 for ; Thu, 31 Mar 2005 12:37:31 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.234 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 31 Mar 2005 17:37:30 -0000 Message-ID: <007601c53618$5086e560$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Bill Sommerfeld" References: <424AB7FF.3080408@piuha.net> <1112223399.20951.615.camel@thunk> <424B84FB.1030309@piuha.net> Subject: Re: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 09:37:30 -0800 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 > > >On Wed, 2005-03-30 at 09:30, Jari Arkko wrote: > > > > > >>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? > >> > >> > > > >(I'm reading mail out of order) > > > >I don't have a problem with that. > > > >One encoding which makes this clear would be to allocate a new IKEv2 > >Exchange Type and specify that it has a distinct Message ID space > >distinct from the space used by the existing four types (see section 3.1 > >of draft-ietf-ipsec-ikev2-17.txt). > > > > > This would work for me. But I'd still like to understand > what happens when we have to do several MOBIKE > requests in this new space before we get an answer from > the peer, are we bounded by some upper limit, or can we > do any number of operations? > Good question. If the other end has 10 addresses and currently now reachable at only one address, we might have to try at least 9 addresses i.e 9 or more messages to find out the working path. I don't know how it will work if it is based on the current window scheme of IKEv2. If i don't get a response for a request, i need to retransmit a different message (using different address) with the same message-id or a new message with a new message-id (which means any number of operations) till a working pair is obtained. Am i missing something..Perhaps that's why the path-test message should not be constrained by the window ? -mohan > --Jari > > _______________________________________________ > 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 Mar 31 12:50:17 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16031 for ; Thu, 31 Mar 2005 12:50:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 836ABFB29B; Thu, 31 Mar 2005 12:50:16 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F188FB29B; Thu, 31 Mar 2005 12:50:13 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2EDA7FB2A6; Thu, 31 Mar 2005 12:50:12 -0500 (EST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id CA8D2FB294 for ; Thu, 31 Mar 2005 12:48:48 -0500 (EST) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 Mar 2005 12:48:49 -0500 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 j2VHmi1j015156; Thu, 31 Mar 2005 12:48:45 -0500 (EST) Received: from stephanew2k02 ([10.21.107.132]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR94295; Thu, 31 Mar 2005 09:48:42 -0800 (PST) Message-Id: <200503311748.ABR94295@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Paul Hoffman'" , "'Geoffrey Huang'" , "'Bill Sommerfeld'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 12:48:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcU2CK2YRorT/xBbSQyEVfv6/Ah+zAAAU5hg In-Reply-To: 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 Is there really a point of reserving. I mean, what's the peer going to do if you exceed the window? (other than complain you're violating the RFC :). The peer will silently drop it until it's finished with another one, right. So what ! I can just keep transmitting my mobike message(s) until the peer has a chance to process it and respond, right? Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of Paul Hoffman > Sent: Thursday, March 31, 2005 10:44 AM > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko' > Cc: mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote: > >So it needs to > >split this between "regular" IKE messages and MOBIKE messages? > > Not "split", but "allow enough extra for MOBIKE". > > >I prefer your earlier suggestion of reserving one or two message IDs > >from the window for mobility purposes. Consider a roaming > client that > >gets a notify from a security gateway (SGW) saying the SGW's window > >size is 5. The client should know that it's capable of mobility and > >consequently reserve a message ID for MOBIKE messages. Just > because a > >peer sends a notification about a window size doesn't mean that an > >implementation needs to fill up the window. > > That sounds good. The question is: how many should we suggest > to reserve? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > 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 Mar 31 13:26:14 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19680 for ; Thu, 31 Mar 2005 13:26:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 58566FB2AF; Thu, 31 Mar 2005 13:26:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E67B3FB2AB; Thu, 31 Mar 2005 13:26:12 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A0F7CFB2AD; Thu, 31 Mar 2005 13:26:11 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id AA290FB2A6 for ; Thu, 31 Mar 2005 13:26:10 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2005 10:24:46 -0800 X-IronPort-AV: i="3.91,138,1110182400"; d="scan'208"; a="243663872:sNHT1365436692" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VIOZgG006054; Thu, 31 Mar 2005 10:24:39 -0800 (PST) Received: from ghuangx31 (dhcp-128-107-163-97.cisco.com [128.107.163.97]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDN02178; Thu, 31 Mar 2005 10:24:38 -0800 (PST) Message-Id: <200503311824.BDN02178@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: , "'Paul Hoffman'" , "'Bill Sommerfeld'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 10:24:38 -0800 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: <200503311748.ABR94295@mira-kan-a.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU2CK2YRorT/xBbSQyEVfv6/Ah+zAAAU5hgAAUs5iA= 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 Yes, I suppose you could just keep retransmitting your messages. However, I would assume that most implementations would view a failure to respond as a sign that the peer might be dead. Either the implementation would just delete the SA or (window permitting), kick off DPD. Since the window size is already reached (and breached), you won't be getting any response from the peer for the DPD messages. Essentially, this would still result in the deletion of the IKE SA. -g > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Thursday, March 31, 2005 9:49 AM > To: 'Paul Hoffman'; 'Geoffrey Huang'; 'Bill Sommerfeld'; 'Jari Arkko' > Cc: mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > Is there really a point of reserving. I mean, what's the > peer going to do > if you exceed the window? (other than complain you're > violating the RFC :). > The peer will silently drop it until it's finished with > another one, right. > So what ! I can just keep transmitting my mobike message(s) > until the peer > has a chance to process it and respond, right? > > Stephane. > > > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com] On Behalf Of Paul Hoffman > > Sent: Thursday, March 31, 2005 10:44 AM > > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko' > > Cc: mobike@machshav.com > > Subject: RE: [Mobike] issue 11 -- window size > > > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote: > > >So it needs to > > >split this between "regular" IKE messages and MOBIKE messages? > > > > Not "split", but "allow enough extra for MOBIKE". > > > > >I prefer your earlier suggestion of reserving one or two > message IDs > > >from the window for mobility purposes. Consider a roaming > > client that > > >gets a notify from a security gateway (SGW) saying the > SGW's window > > >size is 5. The client should know that it's capable of > mobility and > > >consequently reserve a message ID for MOBIKE messages. Just > > because a > > >peer sends a notification about a window size doesn't mean that an > > >implementation needs to fill up the window. > > > > That sounds good. The question is: how many should we suggest > > to reserve? > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > 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 Mar 31 13:49:30 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22477 for ; Thu, 31 Mar 2005 13:49:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 33846FB2AD; Thu, 31 Mar 2005 13:49:26 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0810EFB2AA; Thu, 31 Mar 2005 13:49:24 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F10BAFB2AB; Thu, 31 Mar 2005 13:49:22 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by machshav.com (Postfix) with ESMTP id BC926FB2A9 for ; Thu, 31 Mar 2005 13:49:21 -0500 (EST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2005 14:09:37 -0500 X-IronPort-AV: i="3.91,138,1110171600"; d="scan'208"; a="42686851:sNHT30336824" 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 j2VInDjK007708; Thu, 31 Mar 2005 13:49:16 -0500 (EST) Received: from stephanew2k02 ([10.21.107.132]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR96493; Thu, 31 Mar 2005 10:47:58 -0800 (PST) Message-Id: <200503311847.ABR96493@mira-kan-a.cisco.com> From: "Stephane Beaulieu" To: "'Geoffrey Huang'" , "'Paul Hoffman'" , "'Bill Sommerfeld'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 13:47:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcU2CK2YRorT/xBbSQyEVfv6/Ah+zAAAU5hgAAUs5iAAAGxeMA== In-Reply-To: <200503311824.BDN02178@mira-sjc5-b.cisco.com> 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 Right, but we write the code for the implementation don't we? :) So, a mobike capable IKEv2 implementation *could* exceed the peer's window ONLY for mobike msgs, and choose NOT to view a lack of response as a failure on these messages. The way I see it, mobike is kind of a special case, since when an interface change happens, we'll never know for sure if the peer did respond to a previous message, but we didn't get it, or if the previous request is still sitting on the peer's queue. We do know that we can't retransmit our request (since we haven't picked a new interface yet). Stephane. > -----Original Message----- > From: Geoffrey Huang [mailto:ghuang@cisco.com] > Sent: Thursday, March 31, 2005 1:25 PM > To: stephane@cisco.com; 'Paul Hoffman'; 'Bill Sommerfeld'; > 'Jari Arkko' > Cc: mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > Yes, I suppose you could just keep retransmitting your > messages. However, I would assume that most implementations > would view a failure to respond as a sign that the peer might > be dead. Either the implementation would just delete the SA > or (window permitting), kick off DPD. Since the window size > is already reached (and breached), you won't be getting any > response from the peer for the DPD messages. Essentially, > this would still result in the deletion of the IKE SA. > > -g > > > -----Original Message----- > > From: Stephane Beaulieu [mailto:stephane@cisco.com] > > Sent: Thursday, March 31, 2005 9:49 AM > > To: 'Paul Hoffman'; 'Geoffrey Huang'; 'Bill Sommerfeld'; > 'Jari Arkko' > > Cc: mobike@machshav.com > > Subject: RE: [Mobike] issue 11 -- window size > > > > Is there really a point of reserving. I mean, what's the > peer going > > to do if you exceed the window? (other than complain you're > violating > > the RFC :). > > The peer will silently drop it until it's finished with > another one, > > right. > > So what ! I can just keep transmitting my mobike > message(s) until the > > peer has a chance to process it and respond, right? > > > > Stephane. > > > > > > > > > -----Original Message----- > > > From: mobike-bounces@machshav.com > > > [mailto:mobike-bounces@machshav.com] On Behalf Of Paul Hoffman > > > Sent: Thursday, March 31, 2005 10:44 AM > > > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko' > > > Cc: mobike@machshav.com > > > Subject: RE: [Mobike] issue 11 -- window size > > > > > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote: > > > >So it needs to > > > >split this between "regular" IKE messages and MOBIKE messages? > > > > > > Not "split", but "allow enough extra for MOBIKE". > > > > > > >I prefer your earlier suggestion of reserving one or two > > message IDs > > > >from the window for mobility purposes. Consider a roaming > > > client that > > > >gets a notify from a security gateway (SGW) saying the > > SGW's window > > > >size is 5. The client should know that it's capable of > > mobility and > > > >consequently reserve a message ID for MOBIKE messages. Just > > > because a > > > >peer sends a notification about a window size doesn't > mean that an > > > >implementation needs to fill up the window. > > > > > > That sounds good. The question is: how many should we suggest to > > > reserve? > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > _______________________________________________ > > > 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 Mar 31 13:50:01 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22524 for ; Thu, 31 Mar 2005 13:50:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 53125FB2AA; Thu, 31 Mar 2005 13:50:02 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 15F00FB283; Thu, 31 Mar 2005 13:50:01 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 29A64FB285; Thu, 31 Mar 2005 13:49:59 -0500 (EST) Received: from smtp815.mail.sc5.yahoo.com (smtp815.mail.sc5.yahoo.com [66.163.170.1]) by machshav.com (Postfix) with SMTP id 5DBE6FB277 for ; Thu, 31 Mar 2005 13:49:58 -0500 (EST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.234 with login) by smtp815.mail.sc5.yahoo.com with SMTP; 31 Mar 2005 18:49:53 -0000 Message-ID: <008c01c53622$6ca24910$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Geoffrey Huang" , "'Bill Sommerfeld'" , "'Paul Hoffman'" References: <200503311735.BDM96181@mira-sjc5-b.cisco.com> Subject: Re: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 10:49:52 -0800 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 > Because then you would need to keep track of too many lists of messages. The number of messages you have to maintain is equal to the window size. If you decide that you don't want to buffer more than 10 messages, then split the window between normal IKE messages and mobike messages. Whether you allocate all of the window for IKE or split between IKE and MOBIKE, it does not alter the complexity. So, i don't know why maintaining two windows complicate. -mohan > Currently, we already need to keep track of the window of messages I send to > the peer, as well as a window of messages the peer sends to us. If we use a > separate message ID space, we would need to keep those two windows, and on > top of that, we'd need to keep another 2 just for the MOBIKE exchange. > > -g > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com] On Behalf Of Mohan Parthasarathy > > Sent: Thursday, March 31, 2005 9:23 AM > > To: Bill Sommerfeld; Paul Hoffman > > Cc: 'Jari Arkko'; mobike@machshav.com > > Subject: Re: [Mobike] issue 11 -- window size > > > > Why are we reserving from the existing space ? Why not have > > its own space ? > > > > -mohan > > > > ----- Original Message ----- > > From: "Bill Sommerfeld" > > To: "Paul Hoffman" > > Cc: ; "'Jari Arkko'" > > Sent: Thursday, March 31, 2005 8:02 AM > > Subject: RE: [Mobike] issue 11 -- window size > > > > > > > On Thu, 2005-03-31 at 10:43, Paul Hoffman wrote: > > > > The question is: how many should we suggest to reserve? > > > > > > we have no idea how many will be needed until we design the > > rest of the > > > protocol. > > > _______________________________________________ > > > 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 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Mar 31 14:17:21 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24926 for ; Thu, 31 Mar 2005 14:17:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9E5B0FB2B1; Thu, 31 Mar 2005 14:17:20 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D1E3EFB2AE; Thu, 31 Mar 2005 14:17:18 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 08BEDFB2AF; Thu, 31 Mar 2005 14:17:17 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by machshav.com (Postfix) with ESMTP id E7AFAFB2AC for ; Thu, 31 Mar 2005 14:17:15 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2005 11:17:16 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VJH8gE012015; Thu, 31 Mar 2005 11:17:09 -0800 (PST) Received: from ghuangx31 (dhcp-128-107-163-97.cisco.com [128.107.163.97]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDN09133; Thu, 31 Mar 2005 11:17:12 -0800 (PST) Message-Id: <200503311917.BDN09133@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: , "'Paul Hoffman'" , "'Bill Sommerfeld'" , "'Jari Arkko'" Subject: RE: [Mobike] issue 11 -- window size Date: Thu, 31 Mar 2005 11:17:12 -0800 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: <200503311847.ABR96493@mira-kan-a.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcU2CK2YRorT/xBbSQyEVfv6/Ah+zAAAU5hgAAUs5iAAAGxeMAABZd+A 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 > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Thursday, March 31, 2005 10:48 AM > To: 'Geoffrey Huang'; 'Paul Hoffman'; 'Bill Sommerfeld'; 'Jari Arkko' > Cc: mobike@machshav.com > Subject: RE: [Mobike] issue 11 -- window size > > Right, but we write the code for the implementation don't we? :) > > So, a mobike capable IKEv2 implementation *could* exceed the > peer's window ONLY for mobike msgs, and choose NOT to view a > lack of response as a failure on these messages. Then the DPD mechanism wouldn't ever work with MOBIKE. Suppose the peer's window size is N, and we decide to go ahead and exceed it. We send a delete out for message N+1. We don't get a response; how long do we continue to retransmit this delete message? -g > The way I see it, mobike is kind of a special case, since > when an interface change happens, we'll never know for sure > if the peer did respond to a previous message, but we didn't > get it, or if the previous request is still sitting on the > peer's queue. We do know that we can't retransmit our > request (since we haven't picked a new interface yet). > > Stephane. > > > -----Original Message----- > > From: Geoffrey Huang [mailto:ghuang@cisco.com] > > Sent: Thursday, March 31, 2005 1:25 PM > > To: stephane@cisco.com; 'Paul Hoffman'; 'Bill Sommerfeld'; 'Jari > > Arkko' > > Cc: mobike@machshav.com > > Subject: RE: [Mobike] issue 11 -- window size > > > > Yes, I suppose you could just keep retransmitting your messages. > > However, I would assume that most implementations would > view a failure > > to respond as a sign that the peer might be dead. Either the > > implementation would just delete the SA or (window > permitting), kick > > off DPD. Since the window size is already reached (and > breached), you > > won't be getting any response from the peer for the DPD messages. > > Essentially, this would still result in the deletion of the IKE SA. > > > > -g > > > > > -----Original Message----- > > > From: Stephane Beaulieu [mailto:stephane@cisco.com] > > > Sent: Thursday, March 31, 2005 9:49 AM > > > To: 'Paul Hoffman'; 'Geoffrey Huang'; 'Bill Sommerfeld'; > > 'Jari Arkko' > > > Cc: mobike@machshav.com > > > Subject: RE: [Mobike] issue 11 -- window size > > > > > > Is there really a point of reserving. I mean, what's the > > peer going > > > to do if you exceed the window? (other than complain you're > > violating > > > the RFC :). > > > The peer will silently drop it until it's finished with > > another one, > > > right. > > > So what ! I can just keep transmitting my mobike > > message(s) until the > > > peer has a chance to process it and respond, right? > > > > > > Stephane. > > > > > > > > > > > > > -----Original Message----- > > > > From: mobike-bounces@machshav.com > > > > [mailto:mobike-bounces@machshav.com] On Behalf Of Paul Hoffman > > > > Sent: Thursday, March 31, 2005 10:44 AM > > > > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko' > > > > Cc: mobike@machshav.com > > > > Subject: RE: [Mobike] issue 11 -- window size > > > > > > > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote: > > > > >So it needs to > > > > >split this between "regular" IKE messages and MOBIKE messages? > > > > > > > > Not "split", but "allow enough extra for MOBIKE". > > > > > > > > >I prefer your earlier suggestion of reserving one or two > > > message IDs > > > > >from the window for mobility purposes. Consider a roaming > > > > client that > > > > >gets a notify from a security gateway (SGW) saying the > > > SGW's window > > > > >size is 5. The client should know that it's capable of > > > mobility and > > > > >consequently reserve a message ID for MOBIKE messages. Just > > > > because a > > > > >peer sends a notification about a window size doesn't > > mean that an > > > > >implementation needs to fill up the window. > > > > > > > > That sounds good. The question is: how many should we > suggest to > > > > reserve? > > > > > > > > --Paul Hoffman, Director > > > > --VPN Consortium > > > > _______________________________________________ > > > > 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