From mobike-bounces@machshav.com Mon Jan 3 05:16:37 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12234 for ; Mon, 3 Jan 2005 05:16:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 986E4FB27F; Mon, 3 Jan 2005 10:16:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E0AAFB262; Mon, 3 Jan 2005 10:16:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DF16CFB27C; Mon, 3 Jan 2005 10:16:29 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id DAB49FB24A for ; Mon, 3 Jan 2005 10:16:28 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j03AGQYq017793 for ; Mon, 3 Jan 2005 11:16:27 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j03AGQUt011469 for ; Mon, 3 Jan 2005 11:16:26 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Jan 2005 11:16:26 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B903@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: MOBIKE Mailing List Date: Mon, 3 Jan 2005 11:16:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] mobike design draft update 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 hi all, based on the mailing list discussions i have updated the mobike design draft. please find a cached copy here: http://www.tschofenig.com/drafts/draft-ietf-mobike-design-01.txt the html version can be found here: http://www.tschofenig.com/drafts/draft-ietf-mobike-design-01.html a diff between version -01 and -00 can be found here: http://www.tschofenig.com/drafts/draft-ietf-mobike-design-01-from-0.diff.htm l the previous draft version can be found here: http://www.tschofenig.com/cache/draft-ietf-mobike-design-00.txt ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 3 09:52:00 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03053 for ; Mon, 3 Jan 2005 09:51:59 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 340A3FB280; Mon, 3 Jan 2005 14:51:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88DE2FB262; Mon, 3 Jan 2005 14:51:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D9D6FFB27C; Mon, 3 Jan 2005 14:51:55 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C170FFB246 for ; Mon, 3 Jan 2005 14:51:54 +0000 (UTC) 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 j03Epml26782; Mon, 3 Jan 2005 15:51:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j03EplSj038373; Mon, 3 Jan 2005 15:51:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501031451.j03EplSj038373@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks In-reply-to: Your message of Mon, 20 Dec 2004 09:25:05 +0100. <2A8DB02E3018D411901B009027FD3A3F0550B514@mchp905a.mch.sbs.de> Date: Mon, 03 Jan 2005 15:51:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, jari.arkko@piuha.net 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 In your previous mail you wrote: this is issue is interesting. in a previous mail i had the impression that you argued that only an authorized address can be used for communication (non-return-routability-test messages). => not exactly because IMHO return-routability-test messages can be a way to authorize an address, so there can be a case, likely limited to return-routability-test messages, where a not yet authorized address may be used for communications. if you have an unauthorized address you need to perform some authorization check (which might require a return routability check) to turn this address into an authorized address which can subsequently be used. => exactly. Note the authorization is required only for IPsec packets, for IKE messages connectivity is more important. if my observation is correct then you also suggest to have a window larger than one in order for the protocol to work. => IMHO this is not necessary but highly recommended (i.e., SHOULD). 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 Jan 3 10:16:54 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05386 for ; Mon, 3 Jan 2005 10:16:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7F71AFB280; Mon, 3 Jan 2005 15:16:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B5A14FB262; Mon, 3 Jan 2005 15:16:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AEA57FB27C; Mon, 3 Jan 2005 15:16:50 +0000 (UTC) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id 63AACFB246 for ; Mon, 3 Jan 2005 15:16:49 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j03FGkGn022229; Mon, 3 Jan 2005 16:16:46 +0100 Received: from coliposte.enst-bretagne.fr ([127.0.0.1]) by localhost (coliposte.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21966-09; Mon, 3 Jan 2005 16:16:45 +0100 (CET) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j03FGiDf022212; Mon, 3 Jan 2005 16:16:44 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j03FGjSj038475; Mon, 3 Jan 2005 16:16:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501031516.j03FGjSj038475@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks In-reply-to: Your message of Mon, 20 Dec 2004 09:25:04 +0100. <2A8DB02E3018D411901B009027FD3A3F0550B513@mchp905a.mch.sbs.de> Date: Mon, 03 Jan 2005 16:16:45 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: mobike@machshav.com 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 In your previous mail you wrote: > So another tentative: > - the peer address set is known, each peer address has been > authorized i would phrase it a bit different. let us assume that the addresses available to a peer is called peer address set. i guess we also assume that these addresses are exchanged somehow i.e., each peer (initiator and responder of the mobike exchange) communicates its peer address set to the other peer. the peer address set might change over time and might therfore involve further communication between the peers. => by default the context I use is the address management draft one. > - there are many ways to authorize an address, RR check can be one of > these ways i can agree with this statement. > - an update can be done only to an authorized peer address > (if the peer > address is not yet authorized, it must be authorized before the > application of the update) i am not sure that this statement is correct. to explain what i have in mind i need to introduce another term: the preferred address the preferred address is used by mobike to send messages to the other peer. => I use also this term but here this is not the right one because the update can be limited to some IPsec SAs (i.e., you suppose the IKE SA is always updated). each peer needs to select a preferred address for communication. before an address is used as a preferred address it needs to be authorized. a peer might only have one address: the preferred address however, if it has more than one address (which is, for example, the case if it is multi-homed) then the other addresses might not be authorized (for example because they are in the queue to be experience the return-routability check). if i want to delete one of these addresses (for whatever reason) then why shouldn't i am allowed todo it? it is not used anyway. => I proposed the delete operation in my draft. tbd: we need proper names for these individual addresses. jari provided some input on these addresses. i suggest to reuse whatever he suggested (i might have misused some terms already). => I use/propose: - primary address for the IKE SA address (you propose preferred) - alternate addresses for other members of the sets - candidate addresses for not yet authenticated addresses the peer'd like to add to its peer address set. > - an unknown peer address is an address which is not (was > never) in the > peer address test => "never seen" is likely a better description > - usually the peer registers (i.e., add in its announced > peer address set) > the address it uses for IKE messages but we can extend the previous > statement with "or was never used as the source of an IKE message" > So you get an update for an authorized/to-be-authorized peer > address in a message from an unknown source address: I argue > that both addresses (the one in the header and the one in the > message) must be RR checked because the initiator can have > just moved behind a NAT. let me rephrase this paragraph: a mobike peer receives a message which says: 'add ip abc to the peer address set.' additionally the mobike message was sent with a source address that the other peer has never seen before. => right this might, for example, the case in a break-before-make scenario. the ip address (abc in our example) might be the same as in the ip header (in some cases). => right now, it depends whether we would like to use the address 'abc' as the new preferred address. if so, then we should authorize it. => here not only the peer'd like to add in the peer address set but update all SAs too. which address should we test? - 'abc' (as indicated in the mobike message) or - source ip address => abc must be tested but if this doesn't work and a NAT is suspected a test on the source ip address can show the connectivity is not simply broken. the answer is: it depends whether we support nat traversal or not. if we use a nat prevention mechanism then the address 'abc' needs to be authorized. => we are in mobike so nat traversal is not supported. if we use nat-t then we should authorize the source ip address (in this case the address in the payload and 'abc' does not match). => to authorize the source ip address is not useful for mobike because this is not the address to update to. the answer which address we would like to test => in fact IMHO is the case should be made impossible in the protocol (with a SHOULD NOT) so false NAT detections would come only from incorrect configuration or operation... Has someone a better idea. Thanks Francis.Dupont@enst-bretagne.fr PS: so the requirement for the initiator of an update is "SHOULD NOT" use an address which is not member or candidate member of its peer address set as the source address of an update message. And the requirement for the responder of an "whole" update from a never seen before (including the update message itself) address is to suspect a NAT in the path: a return-routability checks on the new primary address SHOULD be performed, if it fails another one on the source address SHOULD be performed too. If it succeeds then a NAT is likely on the path (the action depends on the NAT traversal discussion :-). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 3 10:28:04 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06774 for ; Mon, 3 Jan 2005 10:28:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 18C4AFB27F; Mon, 3 Jan 2005 15:28:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CA770FB262; Mon, 3 Jan 2005 15:27:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9F2E5FB27C; Mon, 3 Jan 2005 15:27:58 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 73889FB246 for ; Mon, 3 Jan 2005 15:27:57 +0000 (UTC) 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 j03FRil29812; Mon, 3 Jan 2005 16:27:44 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j03FRiSj038564; Mon, 3 Jan 2005 16:27:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501031527.j03FRiSj038564@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bill Sommerfeld Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Tue, 21 Dec 2004 18:50:54 EST. <1103673053.7998.58.camel@thunk> Date: Mon, 03 Jan 2005 16:27:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, Mohan Parthasarathy , MOBIKE Mailing List , Tschofenig Hannes 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 In your previous mail you wrote: In the meantime, I wonder if we could get any leverage out of a "NAT expected" bit -- carried in a secured part of the protocol. This would need to be administratively configured. It would probably have to default to "on". => in fact I share your opinion with only a small difference: I'd like to get a "NAT forbidden" bit. If both peers have that bit cleared you would do NAT prevention; otherwise, you would do NAT traversal if a NAT is detected. => NAT prevention and NAT detection are the same until there is a NAT in the path. One is needed in mobike because as a side effect the peer addresses are protected (because they are duplicated from the header to the content of IKE message). Note the choice really exists only for the initiator, the responder always knows when there is a NAT in the path (i.e., it is not really symmetrical). 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 Jan 3 10:49:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08715 for ; Mon, 3 Jan 2005 10:49:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 30293FB280; Mon, 3 Jan 2005 15:49:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 90178FB262; Mon, 3 Jan 2005 15:49:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 235E2FB27C; Mon, 3 Jan 2005 15:49:03 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D0351FB24A for ; Mon, 3 Jan 2005 15:49:01 +0000 (UTC) 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 j03FmuO31653; Mon, 3 Jan 2005 16:48:56 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j03FmuSj038640; Mon, 3 Jan 2005 16:48:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501031548.j03FmuSj038640@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Mon, 20 Dec 2004 09:25:04 +0100. <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> Date: Mon, 03 Jan 2005 16:48:56 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net 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 In your previous mail you wrote: my impression so far was that we cannot assume that there are some protocols which allow to securely obtain a nat binding. if we manage it to update existing nats to provide this type of protocol support then i would be very happy. however, we would liket to have a protocol which can be deployed today (even if there are some limitations). => I can't understand what you want: basic NAT traversal is already in IKEv2 and advanced NAT traversal is unfeasible in a simple way. So what do you want to change in NAT traversal? > we should give people the possibility to > (a) allow the responder to use the ip address contained in > the ike message > AND > (b) allow the responder to use ip address information in > the header > to derive some decisions. > > => my opinion is than (b) is restricted to detect spurious > NATs in the path: > either we use NAT prevention and MOBIKE or we use NAT traversal. > I don't believe the MOBIKE WG should invent a new NAT > traversal mechanism (note that I am not against the idea of a > new and more secure NAT traversal, just that this is not in > the scope of the MOBIKE WG). that's the place where a number of folks disagree with you. the mobike working group is not inventing a new nat traversal mechanism. we just use what we have in ikev2. => this is exactly what I tried to explain??? > detecting only that you are behind a nat is insufficient > to address all > scenarios people are looking at. > > => we have to decide one day if NAT traversal is in the scope: > 1- just make NAT traversal and MOBIKE two separate solutions > 2- include a new NAT traversal in the charter > 3- try to merge current NAT traversal with MOBIKE My opinion > is 1- is fine and NAT prevention makes the choice clear, > 2- is currently out of the charter and 3- can't work without > 2-, so the best solution is 1-. Note that if NAT traversal is > not very secure it is reasonably secure when implicit SA > update is supported and it was already accepted... i don't see why nat traversal is outside the scope of the mobike charter. => because it is explicitely written in the charter: "In particular, MOBIKE shall not replace or modify IKEv2 NAT traversal function." could you elaborate a little bit more about (1) to make sure whether we have a disagreement here. => simple: I propose a configuration "NAT forbidden" bit: - if it is on NAT prevention is used and on the detection of a NAT IKE/MOBIKE is aborted with an error status. - if it is off NAT detection is used and on the detection of a NAT the NAT traversal feature of IKE is activated. If a NAT is suspected during an active IKE/MOBIKE session (cf previous discussion) then the session is aborted and IKE is restarted with NAT detection... Note it is possible to enforce the detection of a NAT at the price of a bidding down attack issue, and the IPsec WG decided to not support NAT traversal detection/activation in the middle of IKE sessions. 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 Jan 3 10:56:55 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09304 for ; Mon, 3 Jan 2005 10:56:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9F83AFB283; Mon, 3 Jan 2005 15:56:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 70B3DFB262; Mon, 3 Jan 2005 15:56:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 66BA0FB27C; Mon, 3 Jan 2005 15:56:48 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 45314FB24A for ; Mon, 3 Jan 2005 15:56:47 +0000 (UTC) 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 j03FucO32368; Mon, 3 Jan 2005 16:56:38 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j03FucSj038688; Mon, 3 Jan 2005 16:56:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501031556.j03FucSj038688@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Mon, 20 Dec 2004 09:25:04 +0100. <2A8DB02E3018D411901B009027FD3A3F0550B511@mchp905a.mch.sbs.de> Date: Mon, 03 Jan 2005 16:56:38 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net 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 In your previous mail you wrote: luckily this issue is orthogonal to the problems addressed in mobike. mobike should allow you to communicate (via some message that has to be defined) the addresses that are available at a peer. you might obtain these addresses by querying your interface cards, based on pre-configuration => I agree only until here. or even based on the usage of a signaling protocol (such as nsis, midcom or stun). => but there is a big difference between this and the previous: with a NAT the peer has no control at all on its addresses, and you implicitely ask the other peer to trust the NATs! > 1) How does the end node discover the public address securely ? > 2) If the public address is known, how does the node communicate this > to the other end securely ? i agree with your observation. => note this is explicitly outside the charter of MOBIKE. > I am wondering whether these two things can be seen separately. i think they are. if they are we can treat them as a separate problem and try to move forward within mobike working group. i think that this is good news. => please don't forget to change the charter before. 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 Jan 3 15:40:11 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07738 for ; Mon, 3 Jan 2005 15:40:10 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 393D2FB282; Mon, 3 Jan 2005 20:40:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8442BFB27C; Mon, 3 Jan 2005 20:40:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C821AFB27F; Mon, 3 Jan 2005 20:40:03 +0000 (UTC) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by machshav.com (Postfix) with ESMTP id CC496FB266 for ; Mon, 3 Jan 2005 20:40:02 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07691; Mon, 3 Jan 2005 15:39:57 -0500 (EST) Message-Id: <200501032039.PAA07691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 03 Jan 2005 15:39:57 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-01.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : Design of the MOBIKE protocol Author(s) : T. Kivinen, H. Tschofenig Filename : draft-ietf-mobike-design-01.txt Pages : 32 Date : 2005-1-3 The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing protocol extensions to the Internet Key Exchange Protocol version 2 (IKEv2) to enable its use in the context where there are multiple IP addresses per host or where IP addresses of an IPsec host change over time (for example due to mobility). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-design-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-design-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-3151130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-3151130.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Mon Jan 3 17:50:55 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01435 for ; Mon, 3 Jan 2005 17:50:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D4AC8FB282; Mon, 3 Jan 2005 22:50:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BE758FB27C; Mon, 3 Jan 2005 22:50:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 32944FB27F; Mon, 3 Jan 2005 22:50:52 +0000 (UTC) Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by machshav.com (Postfix) with SMTP id 82236FB262 for ; Mon, 3 Jan 2005 22:50:51 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 3 Jan 2005 22:50:50 -0000 Message-ID: <011d01c4f1e6$ac9933b0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , "Tschofenig Hannes" References: <200501031556.j03FucSj038688@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] issue 3: nat traversal Date: Mon, 3 Jan 2005 14:50:50 -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 , jari.arkko@piuha.net 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 > > 1) How does the end node discover the public address securely ? > > 2) If the public address is known, how does the node communicate this > > to the other end securely ? > > i agree with your observation. > > => note this is explicitly outside the charter of MOBIKE. > I am not sure which part you are referring to. MOBIKE is about exchanging addresses. And i don't know why doing (2) would put it outside the charter. -mohan > > I am wondering whether these two things can be seen separately. > i think they are. if they are we can treat them as a separate problem and > try to move forward within mobike working group. i think that this is good > news. > > => please don't forget to change the charter before. > > Regards > > Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 4 05:26:25 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29932 for ; Tue, 4 Jan 2005 05:26:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8A760FB284; Tue, 4 Jan 2005 10:26:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 03A69FB27C; Tue, 4 Jan 2005 10:26:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0F48EFB27F; Tue, 4 Jan 2005 10:26:20 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id E42A3FB266 for ; Tue, 4 Jan 2005 10:26:18 +0000 (UTC) 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 j04AQB101189; Tue, 4 Jan 2005 11:26:11 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j04AQ8Sj042386; Tue, 4 Jan 2005 11:26:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501041026.j04AQ8Sj042386@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Mon, 03 Jan 2005 14:50:50 PST. <011d01c4f1e6$ac9933b0$861167c0@adithya> Date: Tue, 04 Jan 2005 11:26:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Tschofenig Hannes 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 In your previous mail you wrote: > > 1) How does the end node discover the public address securely ? > > 2) If the public address is known, how does the node communicate this > > to the other end securely ? > > i agree with your observation. > > => note this is explicitly outside the charter of MOBIKE. > I am not sure which part you are referring to. MOBIKE is about exchanging addresses. And i don't know why doing (2) would put it outside the charter. => perhaps I have not the same reading of the charter? Quoting it: "An explicit non-goal is the construction of a fully fledged mobility protocol. In particular, the WG shall NOT develop mechanisms for the following functions: ... o IP address changes done by third parties (NATs, firewalls etc). In particular, MOBIKE shall not replace or modify IKEv2 NAT traversal function. MOBIKE handles IP address changes initiated by one of the endpoints of the security associations. NAT traversal handles other address changes. MOBIKE should not be tightly coupled with the NAT traversal function, but it is necessary to specify in which cases (if any) they can be used together, and how they interact." Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 4 12:41:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01048 for ; Tue, 4 Jan 2005 12:41:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 16DA9FB285; Tue, 4 Jan 2005 17:41:38 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5624FFB281; Tue, 4 Jan 2005 17:41:37 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2E844FB282; Tue, 4 Jan 2005 17:41:35 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 6E04CFB27C for ; Tue, 4 Jan 2005 17:41:34 +0000 (UTC) Message-ID: <028601c4f284$c5ce1a00$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Francis Dupont" , "Tschofenig Hannes" References: <200501031548.j03FmuSj038640@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] issue 3: nat traversal Date: Tue, 4 Jan 2005 09:42:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, Mohan Parthasarathy , MOBIKE Mailing List 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 Francis, > => simple: I propose a configuration "NAT forbidden" bit: > - if it is on NAT prevention is used and on the detection of a NAT > IKE/MOBIKE is aborted with an error status. > - if it is off NAT detection is used and on the detection of a NAT > the NAT traversal feature of IKE is activated. If a NAT is suspected > during an active IKE/MOBIKE session (cf previous discussion) then the > session is aborted and IKE is restarted with NAT detection... Note it is > possible to enforce the detection of a NAT at the price of a bidding > down attack issue, and the IPsec WG decided to not support NAT traversal > detection/activation in the middle of IKE sessions. > This sounds pretty reasonable to me. I think it should handle the case of movement from outside a NAT to inside. Though it would require IPsec to be rerun, I think this is a feature, since, as you mention, it avoids bidding down. What about moving from inside to outside? jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jan 5 09:52:24 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09069 for ; Wed, 5 Jan 2005 09:52:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6CFE6FB283; Wed, 5 Jan 2005 14:52:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2DF90FB27C; Wed, 5 Jan 2005 14:52:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AF280FB281; Wed, 5 Jan 2005 14:52:16 +0000 (UTC) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id D037AFB24A for ; Wed, 5 Jan 2005 14:52:15 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j05Eq8Gn029384; Wed, 5 Jan 2005 15:52:09 +0100 Received: from coliposte.enst-bretagne.fr ([127.0.0.1]) by localhost (coliposte.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29148-10; Wed, 5 Jan 2005 15:52:07 +0100 (CET) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j05EpHDf029216; Wed, 5 Jan 2005 15:51:17 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j05EpGSj048652; Wed, 5 Jan 2005 15:51:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501051451.j05EpGSj048652@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Tue, 04 Jan 2005 09:42:28 PST. <028601c4f284$c5ce1a00$016115ac@dcml.docomolabsusa.com> Date: Wed, 05 Jan 2005 15:51:16 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: jari.arkko@piuha.net, Mohan Parthasarathy , MOBIKE Mailing List , Tschofenig Hannes 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 In your previous mail you wrote: What about moving from inside to outside? => clearly a problem for the NAT traversal so a bit outside the scope of the WG... 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 Wed Jan 5 15:49:42 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10225 for ; Wed, 5 Jan 2005 15:49:41 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AEC1AFB246; Wed, 5 Jan 2005 20:49:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D9ACCFB24A; Wed, 5 Jan 2005 20:49:37 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B31D7FB262; Wed, 5 Jan 2005 20:49:36 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id C7863FB246 for ; Wed, 5 Jan 2005 20:49:35 +0000 (UTC) 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 j05KnVi14930 for ; Wed, 5 Jan 2005 22:49:33 +0200 (EET) X-Scanned: Wed, 5 Jan 2005 22:46:39 +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 j05KkdPG013580 for ; Wed, 5 Jan 2005 22:46:39 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00HRrs7q; Wed, 05 Jan 2005 22:46:21 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j05KkJU09719 for ; Wed, 5 Jan 2005 22:46:19 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 Jan 2005 14:46:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2005 14:46:04 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110493E506@daebe007.americas.nokia.com> Thread-Topic: Issue #15 How to do RR (empty informational exchange is not enough) Thread-Index: AcTzZ5DoaRnmENlTQnOrE0Bc0o+ZBQ== From: To: X-OriginalArrivalTime: 05 Jan 2005 20:46:05.0064 (UTC) FILETIME=[933CE880:01C4F367] Subject: [Mobike] Issue #15 How to do RR (empty informational exchange is not enough) 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: quoted-printable 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? =20 -- Maureen _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 11 12:03:57 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09224 for ; Tue, 11 Jan 2005 12:03:56 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 22C7CFB286; Tue, 11 Jan 2005 17:03:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED4D8FB282; Tue, 11 Jan 2005 17:03:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 81835FB283; Tue, 11 Jan 2005 17:03:53 +0000 (UTC) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 386A3FB277 for ; Tue, 11 Jan 2005 17:03:52 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BH3lg27921 for ; Tue, 11 Jan 2005 19:03:48 +0200 (EET) X-Scanned: Tue, 11 Jan 2005 19:06:34 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0BH6YqS028724 for ; Tue, 11 Jan 2005 19:06:34 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 001qmnCV; Tue, 11 Jan 2005 19:06:16 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BGvux00923 for ; Tue, 11 Jan 2005 18:57:56 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 Jan 2005 10:49:15 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2005 10:49:15 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110493E85A@daebe007.americas.nokia.com> Thread-Topic: Comments on draft-ietf-mobike-design-01.txt Thread-Index: AcT3/XqSvqueL4qlRJqeSzw1bihZ2w== From: To: X-OriginalArrivalTime: 11 Jan 2005 16:49:15.0390 (UTC) FILETIME=[7C1739E0:01C4F7FD] Subject: [Mobike] Comments on draft-ietf-mobike-design-01.txt 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: quoted-printable Most of my comments are nits, although some are more substantial. Take what you think is helpful. I didn't have time to review the whole document in one sitting so more comments will come later. Available address: This definition is reused from [I-D.arkko-multi6dt-failure-detection] and refers to addresses which are available by an peer. A few conditions must hold before an address in such a state. 1) I don't understand this. I read the i-d referenced above and I did understand that. I think you need to replace this with more of that i-d text. I'm not sure how much of it to cut and paste. What is here is just too brief IMHO. Peer Address Set: A subset of locally operational addresses that will sent communicated to another peer. A policy available at the peer indicates which addresses to include in the peer address set. Such a policy might be impacted by manual configuration or by interaction with other protocols which indicate newly available addresses. Note that the addresses in the peer address set might change over time. 2) Confusing. The problem is that the word peer is ambiguous. I fixed it by actually labeling the two peers as peer A and peer B. Here is a suggestion: =20 We denote the two peers in this Mobike session by peer A and peer B. A peer address set is a subset of locally operational addresses of peer A that are sent to peer B. A policy available at peer A indicates which addresses to include in the peer address set. Such a policy might be impacted by manual configuration or by interaction with other protocols which indicate new (note: newly is not a word) available addresses. =20 =20 3.1 Mobility Scenario Figure 1 shows a break-before-make mobility scenario where a mobile node attaches to, for example a wireless LAN, to obtain connectivity to some security gateway. This security gateway might connect the mobile node to a corporate network, to a UTMS network or to some other network. 3) You mean UMTS, not UTMS, but wouldn't it be better to say 3G network? Since only MOBIKE is relevant for this discussion the end-to-end communication between the MN and some destination server is not shown in Figure 1. 4) ... Since only MOBIKE communication from the MN to the gateway is relevant for this discussion the end-to-end communication between the MN and some destination is not shown in Figure 1. (Two changes: a) add from the MN to the gateway and b) delete server in destination server, doesn't have to be a server) As a result, some form of protocol exchange, denoted as 'MOBIKE Address Update', 5) As a result, a protocol exchange, denoted by 'MOBIKE Address Update', (OK, very picky) The protocol messages will travel along a new path whereby the old path and the new path will meet at the cross-over router. 6) There is really no technical significance of "meeting" at some router labeled CR and calling it a cross over router (and we don't really know what a cross over router is). I would just label it as R instead of CR and say: The protocol messages will travel along a new path. Potential future path through the network (if Peer A and Peer B chance their preferred address) Figure 2: Multihoming Scenario 7) ... if Peer A and Peer B change (chance should be change) Note, that the load-balancing inside one IKE SA is not provided by the MOBIKE protocol. Each client uses only one of the available IP addresses at a given point in time. 8) Note that Mobike does not support load balancing between multiple IP addresses. That is, each peer uses only one of the available IP addresses at a given point in time. (this is clearer to me, also you switch from using the word peer to using the word client) Let me know if you have questions. -- Maureen _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 13 05:31:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23800 for ; Thu, 13 Jan 2005 05:31:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6AB68FB285; Thu, 13 Jan 2005 10:31:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CC127FB277; Thu, 13 Jan 2005 10:31:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6BD68FB283; Thu, 13 Jan 2005 10:31:05 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 3E6CAFB266 for ; Thu, 13 Jan 2005 10:31:04 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j0DAV2Yq015606; Thu, 13 Jan 2005 11:31:02 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0DAV13r010570; Thu, 13 Jan 2005 11:31:01 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Jan 2005 11:31:01 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F056499DF@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Maureen.Stillman@nokia.com, mobike@machshav.com Subject: RE: [Mobike] Comments on draft-ietf-mobike-design-01.txt Date: Thu, 13 Jan 2005 11:30:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi maureen, thanks for the review. please find some comments inline: > Most of my comments are nits, although some are more > substantial. Take what you think is helpful. I didn't have > time to review the whole document in one sitting so more > comments will come later. > > Available address: > > This definition is reused from > [I-D.arkko-multi6dt-failure-detection] and refers to addresses > which are available by an peer. A few conditions must > hold before > an address in such a state. > > 1) I don't understand this. I read the i-d referenced above > and I did understand that. I think you need to replace this > with more of that i-d text. I'm not sure how much of it to > cut and paste. What is here is just too brief IMHO. > i see. i tried to avoid to perform a copy-and-paste but sometimes it is necessary for editorial reasons. > Peer Address Set: > > A subset of locally operational addresses that will sent > communicated to another peer. A policy available at the peer > indicates which addresses to include in the peer address set. > Such a policy might be impacted by manual configuration or by > interaction with other protocols which indicate newly available > addresses. Note that the addresses in the peer address > set might > change over time. > > 2) Confusing. The problem is that the word peer is > ambiguous. I fixed it by actually labeling the two peers as > peer A and peer B. Here is a > suggestion: > > We denote the two peers in this Mobike session by peer A and > peer B. A peer address set is a subset of locally > operational addresses of peer A that are sent to peer B. A > policy available at peer A indicates which addresses to > include in the peer address set. Such a policy might be > impacted by manual configuration or by interaction with other > protocols which indicate new (note: newly is not a word) > available addresses. i wanted to include an example to make it clearer. however, your suggestions also seems to be fine for me. thanks./ > > > 3.1 Mobility Scenario > > Figure 1 shows a break-before-make mobility scenario where a mobile > node attaches to, for example a wireless LAN, to obtain > connectivity > to some security gateway. This security gateway might connect the > mobile node to a corporate network, to a UTMS network or to some > other network. > > 3) You mean UMTS, not UTMS, but wouldn't it be better to say > 3G network? true. > > Since only MOBIKE is relevant > for this discussion the end-to-end communication between the MN and > some destination server is not shown in Figure 1. > > 4) ... Since only MOBIKE communication from the MN to the > gateway is relevant for this discussion the end-to-end > communication between the MN and some destination is not > shown in Figure 1. (Two changes: a) add from the MN to the > gateway and b) delete server in destination server, doesn't > have to be a server) sounds good as well./ > > As a result, some form > of protocol exchange, denoted as 'MOBIKE Address Update', > 5) As a result, a > protocol exchange, denoted by 'MOBIKE Address Update', > (OK, very picky) also fine with me./ > > The protocol messages will > travel along a new path whereby the old path and the new path will > meet at the cross-over router. > 6) There is really no technical significance of "meeting" at > some router labeled CR and calling it a cross over router > (and we don't really know what a cross over router is). I > would just label it as R instead of CR and say: > The protocol messages will travel along a new path. you are certainly right. i have reused one of my nsis figure where the cr is a special node. i will fix it./ > > Potential future path through the network > (if Peer A and Peer B chance their preferred > address) > > Figure 2: Multihoming Scenario > 7) ... if Peer A and Peer B change (chance should be change) > > Note, that the load-balancing inside one IKE SA is not provided by > the MOBIKE protocol. Each client uses only one of the available IP > addresses at a given point in time. > 8) Note that Mobike does not support load balancing between > multiple IP addresses. That is, each peer uses only one of > the available IP addresses at a given point in time. (this is > clearer to me, also you switch from using the word peer to > using the word client) ok. > > Let me know if you have questions. > thanks for your suggestions. i will incorporate them into the next version of the draft. ciao hannes > -- Maureen > _______________________________________________ > 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 Jan 14 16:46:16 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26437 for ; Fri, 14 Jan 2005 16:46:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6EC07FB283; Fri, 14 Jan 2005 21:46:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 80548FB277; Fri, 14 Jan 2005 21:46:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 691C2FB27D; Fri, 14 Jan 2005 21:46:11 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id F2B48FB262 for ; Fri, 14 Jan 2005 21:46:09 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ELk3T09139 for ; Fri, 14 Jan 2005 23:46:06 +0200 (EET) X-Scanned: Fri, 14 Jan 2005 23:45:10 +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 j0ELjATG007050 for ; Fri, 14 Jan 2005 23:45:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00uXpD0h; Fri, 14 Jan 2005 23:45:04 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ELj3x18398 for ; Fri, 14 Jan 2005 23:45:03 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 Jan 2005 15:44:32 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2005 15:44:32 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110493EB89@daebe007.americas.nokia.com> Thread-Topic: More Comments on draft-ietf-mobike-design-01.txt Thread-Index: AcT6gjo74jEiuQ9lSky8EPpVDVNG5g== From: To: X-OriginalArrivalTime: 14 Jan 2005 21:44:32.0290 (UTC) FILETIME=[3B6CE020:01C4FA82] Subject: [Mobike] More Comments on draft-ietf-mobike-design-01.txt 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: quoted-printable Thanks for your prompt response to my comments. Again, most of my comments are nits, although some are more substantial. Take what you think is helpful. I didn't have time to review the whole document in one sitting so more comments will come later. 3.3 Multihomed laptop scenario ... in order to sent IP packets... 1) Should be ...in order to send IP packets... Some of these interfaces might connected to a network over the time depending on a number of reasons (e.g., cost, availability of certain link layer technologies, user convenience). =20 2) A number of different interfaces can be activated over the time depending on policies, e.g., cost, availability of certain link layer technologies and user convenience. Note that a policy for selecting a network interface based on cost, etc. is out of scope for Mobike. I'm concerned that some people might think that Mobike does some of this policy management and network selection if we don't point out explicitly that it does not. Thus I have included the extra sentence above. For example, the user can disconnect himself from the fixed Ethernet, and then use the office WLAN, and then later leave the office and start using GPRS during the trip to home. At home he might again use again WLAN. 3) Just fixing nits here. For example, the user can disconnect himself from the fixed Ethernet, use the office WLAN, and then later leave the office and start using GPRS during the trip home. At home he might again use WLAN.=20 4. Framework 4) I suggest that you put the last part of the section up front. It does a nice job of setting up the framework. Then the framework is explained. Here is the last paragraphs in the framework with nits fixed. I took the last bullet that I thought was too long and split it up and fixed nits. 4) 4. Framework Although the interaction with other protocols to determine the preferred address and preferred address set is important for MOBIKE to operate correctly the working group is chartered to consider this aspect out of scope. The working group will develop a MOBIKE protocol with the following functionality: o Ability to inform a peer about the peer address set o Ability to inform a peer about the preferred address o Ability to test connectivity along a path and thereby to detect an outage in order to fall back to another address, thereby making it the new preferred address o Ability to change the peer address set o Ability to deal with Network Address Translation devices The technical details of these functions are discussed below. 5) Now comes the text that was the start of the framework section and I have fixed some nits. Here is the original text (2 paragraphs) followed by my changes: Initially, when a MOBIKE peer starts and executes the initial protocol exchange with its MOBIKE peer it needs to setup a peer address set based on the available addresses. It might want to make this peer address set available to the other peer. The Initiator does not need to explicitly indicate its preferred address since already using its preferred address. The outgoing IKEv2 and MOBIKE messages use this preferred address as the source IP address and expects incoming signaling messages to be addressed to this address. Interaction with other protocols at the MOBIKE host is required to build the peer address set and the preferred address. In some cases the peer address set is available before the initial protocol run and does not change during the lifetime of the IKE-SA. The preferred address might change due to policy reasons. In many other cases, as motivated in Section 3 the peer address set is modified (by adding or deleting addresses) and the preferred address needs to be changed as well. ------------- my suggested edits -------------------------------- When a MOBIKE peer initiates a=20 protocol exchange with its MOBIKE peer it needs to define a peer address set based on the available addresses. Optionally, it can make a peer address set available to the other peer. The Initiator does not need to explicitly indicate its preferred address since it is already using its preferred address. The outgoing IKEv2 and MOBIKE messages use this preferred address as the source IP address and expects incoming signaling messages to be sent to this address. Interaction with other protocols at the MOBIKE host is required to build the peer address set and the preferred address. In some cases the peer address set is available before the initial protocol exchange and does not change during the lifetime of the IKE-SA. The preferred address might change due to policy reasons. Section 3 describes three scenarios in which the peer address set is modified (by adding or deleting addresses). In these scenarios the preferred address needs to be changed as well. 6) Another nit just above the picture Testing other paths might also be useful to notice when a disconnected path is operational again. How about: Optionally, periodic testing of other paths might be useful to determine when a disconnected path becomes operational. 7) This paragraph below needs to be moved to the security considerations section. It needs to be worded differently and solutions need to be discussed, but I'll get to that when I send comments later on security considerations. Here is the paragraph to move: In addition to the above-listed functionality security is important to the working group. For example, the ability to prevent flooding attacks based on announcing someone else's address needs to be dealt with. 8) I would delete the paragraph below. Comparing MOBIKE to other protocols is a complex topic and this one sentence is neither technically informative nor complete. It will just raise a lot of questions and cause a lot of confusion and argument. I don't think it belongs in a framework document. If you are just trying to say that In Mobike both the IKE-SA and IPsec SAs addresses are affected by the change in address, then just say that only. Here is the paragraph to delete. Note that MOBIKE is somewhat different compared to, for example, SCTP mobility since both the IKE-SA and the IPsec SA is affected by the change of addresses. More later. Thanks for your prompt response to my first set of comments. -- Maureen _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 17 11:36:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21488 for ; Mon, 17 Jan 2005 11:36:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 15643FB282; Mon, 17 Jan 2005 16:36:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 03F53FB27F; Mon, 17 Jan 2005 16:36:38 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3E163FB280; Mon, 17 Jan 2005 16:36:36 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 42AAAFB277 for ; Mon, 17 Jan 2005 16:36:35 +0000 (UTC) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HGaUc08872 for ; Mon, 17 Jan 2005 18:36:30 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 18:34: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 j0HGYjuO016167 for ; Mon, 17 Jan 2005 18:34:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00969bHa; Mon, 17 Jan 2005 18:34:44 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HGXNU25444 for ; Mon, 17 Jan 2005 18:33:24 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 10:26:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] More Comments on draft-ietf-mobike-design-01.txt Date: Mon, 17 Jan 2005 11:26:49 -0500 Message-ID: Thread-Topic: More Comments on draft-ietf-mobike-design-01.txt Thread-Index: AcT6gjo74jEiuQ9lSky8EPpVDVNG5gCLku9w From: To: , X-OriginalArrivalTime: 17 Jan 2005 16:26:50.0858 (UTC) FILETIME=[592A6CA0:01C4FCB1] 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: quoted-printable > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext=20 > Sent: Friday, January 14, 2005 4:45 PM > To: mobike@machshav.com > Subject: [Mobike] More Comments on draft-ietf-mobike-design-01.txt > =20 > 4) 4. Framework > Although the interaction with other protocols to determine=20 > the preferred > address and preferred address set is important for MOBIKE > to operate correctly the working group is chartered to=20 > consider this > aspect out of scope. The working group will develop a MOBIKE > protocol with the following functionality: > o Ability to inform a peer about the peer address set > o Ability to inform a peer about the preferred address > o Ability to test connectivity along a path and thereby=20 > to detect an > outage in order to fall back to another address,=20 > thereby making it > the new preferred address > o Ability to change the peer address set > o Ability to deal with Network Address Translation devices How about the 4th bullet be: o Ability to change the peer address set and the preferred address=20 For the Mobility scenario, the preferred address shall need to be = changed. Or is it subsumed in the bullets 1 and 2? Atul _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 17 11:38:33 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21692 for ; Mon, 17 Jan 2005 11:38:31 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 866A7FB282; Mon, 17 Jan 2005 16:38:33 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F117FB27F; Mon, 17 Jan 2005 16:38:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D35FFB280; Mon, 17 Jan 2005 16:38:31 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id B4422FB277 for ; Mon, 17 Jan 2005 16:38:30 +0000 (UTC) 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 j0HGcRl26831 for ; Mon, 17 Jan 2005 18:38:27 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 18:36:15 +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 j0HGaFHG002466 for ; Mon, 17 Jan 2005 18:36:15 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00tgOonE; Mon, 17 Jan 2005 18:36:13 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HGaDx02862 for ; Mon, 17 Jan 2005 18:36:13 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 10:33:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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, 17 Jan 2005 11:33:35 -0500 Message-ID: Thread-Topic: question on draft-ietf-mobike-design-01.txt Thread-Index: AcT8skqKIJEZsTDiQzeRFLoR/XgeJw== From: To: X-OriginalArrivalTime: 17 Jan 2005 16:33:37.0582 (UTC) FILETIME=[4B9794E0:01C4FCB2] Subject: [Mobike] question on draft-ietf-mobike-design-01.txt 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: quoted-printable In section 3.2 Multihoming scenario, do we allow simultaneous change of = preferred addresses at both the peers? The figure there kind of implies it.=20 Could we explicitly say there whether we support such a simultaneous = change?=20 Atul _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 20 15:11:20 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01045 for ; Thu, 20 Jan 2005 15:11:19 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BFF88FB283; Thu, 20 Jan 2005 20:11:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4C477FB266; Thu, 20 Jan 2005 20:11:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5B9FEFB277; Thu, 20 Jan 2005 20:11:14 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 5E192FB246 for ; Thu, 20 Jan 2005 20:11:13 +0000 (UTC) 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 j0KKAsp05024 for ; Thu, 20 Jan 2005 22:11:08 +0200 (EET) X-Scanned: Thu, 20 Jan 2005 22:08:21 +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 j0KK8LRf019189 for ; Thu, 20 Jan 2005 22:08:21 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00MJoExJ; Thu, 20 Jan 2005 22:07:39 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0KK7KU20121 for ; Thu, 20 Jan 2005 22:07:20 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 Jan 2005 13:59:00 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2005 13:59:00 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110493EEB6@daebe007.americas.nokia.com> Thread-Topic: Comment on section 5.7 in draft-ietf-mobike-design-01.txt (should we delete it?) Thread-Index: AcT/KlfqhpM0GZhTRMaeEyM1v11XPg== From: To: X-OriginalArrivalTime: 20 Jan 2005 19:59:00.0778 (UTC) FILETIME=[7C0750A0:01C4FF2A] Subject: [Mobike] Comment on section 5.7 in draft-ietf-mobike-design-01.txt (should we delete it?) 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: quoted-printable Original text: 5.7 Employing MOBIKE results in other protocols If MOBIKE has learned about new locations or verified the validity of an address through a return routability test, can this information be useful for other protocols? (*** text omitted ***) However, it is conceivable that future uses or extensions of the MOBIKE protocol make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would likely be useful for SCTP to learn about the new addresses at the same time as MOBIKE learns them. Similarly, various IP layer mechanisms might make use of the fact that a return routability test of a specific type has already been performed. My comment: I'm concerned about this subsection 5.7 and I think it should be deleted entirely. Speculation on relationships with other protocols when MOBIKE has not been baked is not useful at this time. I can't evaluate this section because there is not enough real technical information. The next part is even more speculation about multihoming and possible multi6 outcomes which are neither determined nor baked. Your last sentence says it best: Nevertheless, all of this is outside the scope of current MOBIKE base protocol design and may be addressed in future work. My conclusion: So let's not say it at all. =20 -- Maureen =20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jan 22 09:58:46 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07962 for ; Sat, 22 Jan 2005 09:58:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3CBBBFB28A; Sat, 22 Jan 2005 14:58:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 09FC4FB284; Sat, 22 Jan 2005 14:58:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E676CFB285; Sat, 22 Jan 2005 14:58:38 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 50E1DFB280 for ; Sat, 22 Jan 2005 14:58:37 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j0MEwZ07002387; Sat, 22 Jan 2005 15:58:35 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0MEwZiQ001406; Sat, 22 Jan 2005 15:58:35 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 22 Jan 2005 15:58:35 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046869B4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Maureen.Stillman@nokia.com'" , mobike@machshav.com Subject: AW: [Mobike] More Comments on draft-ietf-mobike-design-01.txt Date: Sat, 22 Jan 2005 15:58:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi maureen,=20 thanks for the review and sorry for my late response. please find my comments inline: > -----Urspr=FCngliche Nachricht----- > Von: Maureen.Stillman@nokia.com [mailto:Maureen.Stillman@nokia.com]=20 > Gesendet: Freitag, 14. Januar 2005 22:45 > An: mobike@machshav.com > Betreff: [Mobike] More Comments on draft-ietf-mobike-design-01.txt >=20 >=20 > Thanks for your prompt response to my comments. Again, most of my > comments are nits, although some are more substantial. Take what you > think is helpful. I didn't have time to review the whole document in > one sitting so more comments will come later. >=20 > 3.3 Multihomed laptop scenario >=20 > ... in order to sent IP packets... > 1) Should be ...in order to send IP packets... ok.=20 >=20 > Some of these > interfaces might connected to a network over the time=20 > depending on a > number of reasons (e.g., cost, availability of certain link layer > technologies, user convenience). =20 > 2) A number of different > interfaces can be activated over the time depending on > policies, e.g., cost, availability of certain link layer > technologies and user convenience. Note that a policy for=20 > selecting > a network interface based on cost, etc. is out of scope for Mobike. >=20 > I'm concerned that some people might think that Mobike does=20 > some of this > policy management and network selection if we don't point out=20 > explicitly > that it does not. Thus I have included the extra sentence above. >=20 you are certainly right. thanks for clarification.=20 > For example, the user can > disconnect himself from the fixed Ethernet, and then use the = office > WLAN, and then later leave the office and start using GPRS=20 > during the > trip to home. At home he might again use again WLAN. >=20 > 3) Just fixing nits here. > For example, the user can > disconnect himself from the fixed Ethernet, use the office > WLAN, and then later leave the office and start using GPRS=20 > during the > trip home. At home he might again use WLAN.=20 >=20 ok.=20 > 4. Framework > 4) I suggest that you put the last part of the section up front. It > does a nice job of setting up the framework. Then the framework is > explained. Here is the last paragraphs in the framework with nits > fixed. I took the last bullet that I thought was too long=20 > and split it > up and fixed nits. >=20 > 4) 4. Framework > Although the interaction with other protocols to determine=20 > the preferred > address and preferred address set is important for MOBIKE > to operate correctly the working group is chartered to=20 > consider this > aspect out of scope. The working group will develop a MOBIKE > protocol with the following functionality: > o Ability to inform a peer about the peer address set > o Ability to inform a peer about the preferred address > o Ability to test connectivity along a path and thereby=20 > to detect an > outage in order to fall back to another address,=20 > thereby making it > the new preferred address > o Ability to change the peer address set > o Ability to deal with Network Address Translation devices >=20 > The technical details of these functions are discussed below. sounds good for me.=20 >=20 > 5) Now comes the text that was the start of the framework=20 > section and I > have fixed some nits. Here is the original text (2=20 > paragraphs) followed > by my changes: >=20 > Initially, when a MOBIKE peer starts and executes the initial > protocol exchange with its MOBIKE peer it needs to setup a peer > address set based on the available addresses. It might=20 > want to make > this peer address set available to the other peer. The Initiator > does not need to explicitly indicate its preferred address since > already using its preferred address. The outgoing IKEv2 and MOBIKE > messages use this preferred address as the source IP address and > expects incoming signaling messages to be addressed to=20 > this address. >=20 > Interaction with other protocols at the MOBIKE host is required to > build the peer address set and the preferred address. In=20 > some cases > the peer address set is available before the initial=20 > protocol run and > does not change during the lifetime of the IKE-SA. The preferred > address might change due to policy reasons. In many other=20 > cases, as > motivated in Section 3 the peer address set is modified=20 > (by adding or > deleting addresses) and the preferred address needs to be=20 > changed as > well. >=20 > ------------- my suggested edits -------------------------------- >=20 > When a MOBIKE peer initiates a=20 > protocol exchange with its MOBIKE peer it needs to define a peer > address set based on the available addresses. Optionally, it can > make > a peer address set available to the other peer. The Initiator > does not need to explicitly indicate its preferred address since = it > is > already using its preferred address. The outgoing IKEv2 and = MOBIKE > messages use this preferred address as the source IP address and > expects incoming signaling messages to be sent to this address. >=20 > Interaction with other protocols at the MOBIKE host is required to > build the peer address set and the preferred address. In=20 > some cases > the peer address set is available before the initial protocol > exchange and > does not change during the lifetime of the IKE-SA. The preferred > address might change due to policy reasons. Section 3 describes > three scenarios in which the peer address set is modified (by=20 > adding or > deleting addresses). In these scenarios the preferred=20 > address needs > to be changed as well. with minor modifications i have incorporated your suggestions.=20 >=20 > 6) Another nit just above the picture >=20 > Testing other paths might also be useful to notice when a = disconnected > path is operational again. >=20 > How about: > Optionally, periodic testing of other paths might be useful=20 > to determine > when a disconnected path becomes operational. sounds good.=20 >=20 > 7) This paragraph below needs to be moved to the security=20 > considerations > section. It needs to be worded differently and solutions need to be > discussed, but I'll get to that when I send comments later on = security > considerations. Here is the paragraph to move: >=20 fine with me.=20 btw, the security consideration section is one of the sections that = need more meat.=20 > In addition to the above-listed functionality security is important > to the working group. For example, the ability to prevent = flooding > attacks based on announcing someone else's address needs=20 > to be dealt > with. >=20 > 8) I would delete the paragraph below. Comparing MOBIKE to other > protocols is a complex topic and this one sentence is neither > technically informative nor complete. It will just raise a lot of > questions and cause a lot of confusion and argument. I don't think = it > belongs in a framework document. If you are just trying to=20 > say that In > Mobike both the IKE-SA and IPsec SAs addresses are affected by the > change in address, then just say that only. Here is the paragraph to > delete. >=20 > Note that MOBIKE is somewhat different compared to, for example, SCTP > mobility since both the IKE-SA and the IPsec SA is affected by the > change of addresses. >=20 i think you are right. we stay on safe ground if we do not provide a comparision with other proposals.=20 however, in discussions with sctp folks i noticed that they this = particular issue causes some confusion. how should we reflect this aspect in the document?=20 > More later. Thanks for your prompt response to my first set of > comments. this time it took a bit longer... =20 ciao hannes >=20 > -- Maureen > _______________________________________________ > 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 From mobike-bounces@machshav.com Sat Jan 22 10:01:18 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08070 for ; Sat, 22 Jan 2005 10:01:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8BEF1FB28F; Sat, 22 Jan 2005 15:01:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 64874FB284; Sat, 22 Jan 2005 15:01:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 223E0FB285; Sat, 22 Jan 2005 15:01:12 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 29409FB280 for ; Sat, 22 Jan 2005 15:01:11 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j0MF1A07003077; Sat, 22 Jan 2005 16:01:10 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0MF1AiQ002425; Sat, 22 Jan 2005 16:01:10 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 22 Jan 2005 16:01:10 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046869B5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Atul.Sharma@nokia.com'" , Maureen.Stillman@nokia.com, mobike@machshav.com Subject: AW: [Mobike] More Comments on draft-ietf-mobike-design-01.txt Date: Sat, 22 Jan 2005 16:01:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi atul, please find a short comment below: > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext > > Sent: Friday, January 14, 2005 4:45 PM > > To: mobike@machshav.com > > Subject: [Mobike] More Comments on draft-ietf-mobike-design-01.txt > > > > 4) 4. Framework > > Although the interaction with other protocols to determine > > the preferred > > address and preferred address set is important for MOBIKE > > to operate correctly the working group is chartered to > > consider this > > aspect out of scope. The working group will develop a MOBIKE > > protocol with the following functionality: > > o Ability to inform a peer about the peer address set > > o Ability to inform a peer about the preferred address > > o Ability to test connectivity along a path and thereby > > to detect an > > outage in order to fall back to another address, > > thereby making it > > the new preferred address > > o Ability to change the peer address set > > o Ability to deal with Network Address Translation devices > > How about the 4th bullet be: > o Ability to change the peer address set and the > preferred address fixed. > > For the Mobility scenario, the preferred address shall need > to be changed. > > Or is it subsumed in the bullets 1 and 2? added an additional bullet. the new list is now: Ability to inform the other peer about the peer address set Ability to inform the other peer about the preferred address Ability to test connectivity along a path and thereby to detect an outage situation Ability to change the preferred address Ability to change the peer address set Ability to deal with Network Address Translation devices ciao hannes > > Atul > _______________________________________________ > 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 Sat Jan 22 10:10:40 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09037 for ; Sat, 22 Jan 2005 10:10:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 742E5FB28A; Sat, 22 Jan 2005 15:10:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C9536FB284; Sat, 22 Jan 2005 15:10:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 68D0AFB285; Sat, 22 Jan 2005 15:10:38 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 74EEDFB280 for ; Sat, 22 Jan 2005 15:10:37 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j0MFAaaA014167; Sat, 22 Jan 2005 16:10:36 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0MFAaiQ008638; Sat, 22 Jan 2005 16:10:36 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 22 Jan 2005 16:10:36 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046869B6@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Atul.Sharma@nokia.com'" , mobike@machshav.com Subject: AW: [Mobike] question on draft-ietf-mobike-design-01.txt Date: Sat, 22 Jan 2005 16:10:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi atul, > In section 3.2 Multihoming scenario, do we allow simultaneous > change of preferred addresses > at both the peers? The figure there kind of implies it. we say that each peer change its preferred address at any time and that there needs to be a mechanism to communicate this change to the other peer. if the peer address set contains more than one address then both peers can still communicate with each other even if they happen to change their preferred address at the same time. (btw, i don't think that the figure is good enough to show this situation.) what is outside the scope is the case where a third entity would be required. > > Could we explicitly say there whether we support such a > simultaneous change? we can add something explicitly, if you think it is necessary. ciao hannes > > Atul > > _______________________________________________ > 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 Sat Jan 22 10:27:31 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10373 for ; Sat, 22 Jan 2005 10:27:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 12553FB28B; Sat, 22 Jan 2005 15:27:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B9760FB284; Sat, 22 Jan 2005 15:27:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BE948FB285; Sat, 22 Jan 2005 15:27:28 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id C0D46FB280 for ; Sat, 22 Jan 2005 15:27:27 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j0MFRQFF009952 for ; Sat, 22 Jan 2005 16:27:26 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0MFRQiQ019707 for ; Sat, 22 Jan 2005 16:27:26 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 22 Jan 2005 16:27:26 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046869B7@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: mobike@machshav.com Date: Sat, 22 Jan 2005 16:27:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] intermediate mobike design draft update 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 hi all, based on the review comments i have compiled an intermediate draft version. you can find the draft at: http://www.tschofenig.com/TEMP/TEMP-draft-ietf-mobike-design-02_22Jan2005.tx t http://www.tschofenig.com/TEMP/TEMP-draft-ietf-mobike-design-02_22Jan2005.ht ml ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 24 11:08:18 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25179 for ; Mon, 24 Jan 2005 11:08:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E5935FB28E; Mon, 24 Jan 2005 16:08:15 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B4D15FB28B; Mon, 24 Jan 2005 16:08:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 64C8EFB28D; Mon, 24 Jan 2005 16:08:13 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 554CEFB24A for ; Mon, 24 Jan 2005 16:08:12 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0OG7on09133; Mon, 24 Jan 2005 18:07:50 +0200 (EET) X-Scanned: Mon, 24 Jan 2005 18:12:40 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0OGCeOT000897; Mon, 24 Jan 2005 18:12:40 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00sTX3xv; Mon, 24 Jan 2005 18:12:38 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0OG2ox07344; Mon, 24 Jan 2005 18:02:50 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 10:02:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] question on draft-ietf-mobike-design-01.txt Date: Mon, 24 Jan 2005 11:01:33 -0500 Message-ID: Thread-Topic: [Mobike] question on draft-ietf-mobike-design-01.txt Thread-Index: AcUAlMaZ+X3QR+h/Rhq04gJvrLzvxgBlrOxQ From: To: , X-OriginalArrivalTime: 24 Jan 2005 16:02:37.0134 (UTC) FILETIME=[1F91FEE0:01C5022E] 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: quoted-printable Hi Hannes, I will give a particular scenario, which will make explicit the question I was trying to raise. The scenario is inline. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Tschofenig Hannes > Sent: Saturday, January 22, 2005 10:11 AM > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > Subject: AW: [Mobike] question on draft-ietf-mobike-design-01.txt >=20 >=20 > hi atul,=20 >=20 > > In section 3.2 Multihoming scenario, do we allow simultaneous=20 > > change of preferred addresses > > at both the peers? The figure there kind of implies it.=20 >=20 > we say that each peer change its preferred address at any=20 > time and that > there needs to be a mechanism to communicate this change to=20 > the other peer.=20 >=20 > if the peer address set contains more than one address then=20 > both peers can > still communicate with each other even if they happen to change their > preferred address at the same time.=20 Let us say Peer 1 has addresses A and B; Peer 2 has addresses C and D. = Say A and C are the advertised preferred addresses. Imagine both = interfaces/paths corresponding to A and C go down simultaneously. Peer 1 shall send to = Peer 2 on address C telling the new preferred address is B. Peer 2 shall send = to Peer 1 on address A telling the new preferred address is D. But none of = these MOBIKE address change messages shall reach the other end. Do we in the MOBIKE protocol incorporate the assumption that Peer 1 = shall always know of addresses C and D of Peer 2; and on not getting the ack = from Peer 2 on address change shall try sending the address change = notification to address D? I had this kind of simultaneous change of preferred address in mind for = the=20 original question. > (btw, i don't think that the figure is good enough to show=20 > this situation.) The figure does not explicitly describe this situatiopn, it just implies = it by saying: "If Peer A and Peer B change their preferred address". =20 > what is outside the scope is the case where a third entity would be > required.=20 I understand that, we are not taking the MobileIP path. > >=20 > > Could we explicitly say there whether we support such a=20 > > simultaneous change?=20 >=20 > we can add something explicitly, if you think it is necessary.=20 I think, it will definitely help. >=20 > ciao > hannes >=20 > >=20 > > Atul > >=20 > > _______________________________________________ > > 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 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jan 26 12:05:08 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16537 for ; Wed, 26 Jan 2005 12:05:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 22D22FB28D; Wed, 26 Jan 2005 17:05:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4951FFB280; Wed, 26 Jan 2005 17:05:00 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2813DFB282; Wed, 26 Jan 2005 17:04:59 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id E4E3BFB27C for ; Wed, 26 Jan 2005 17:04:57 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QH4oJ19203; Wed, 26 Jan 2005 19:04:51 +0200 (EET) X-Scanned: Wed, 26 Jan 2005 19:02:59 +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 j0QH2xwm008992; Wed, 26 Jan 2005 19:02:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 006eywJE; Wed, 26 Jan 2005 19:02:57 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 j0QH2fU10924; Wed, 26 Jan 2005 19:02:41 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 Jan 2005 19:02:41 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 Jan 2005 19:02:40 +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] intermediate mobike design draft update Date: Wed, 26 Jan 2005 19:02:40 +0200 Message-ID: Thread-Topic: [Mobike] intermediate mobike design draft update Thread-Index: AcUAlu3sOurdElx9SNOWaijRBXXmZwDLJk/w From: To: , X-OriginalArrivalTime: 26 Jan 2005 17:02:40.0927 (UTC) FILETIME=[D86CAAF0:01C503C8] 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: quoted-printable Hi, I have some comments and suggestions about the terminology about addresses/pairs/paths in mobike-design-02. 1) Currently the definition of "preferred address pair" is quite imprecise, since it unnecessarily mixes what is preferred with what is actually happening. Also, it's not quite clear what's the difference between "preferred address pair" and "primary path". I'd suggest we replace both of them with a new term, say "current path" (or "current address pair"), that means the addresses that are currently used by the peer as the tunnel header addresses of IPsec packets (of IPsec SAs associated with this IKE SA). I think we had rough consensus on issue 8 (scope of SA changes); thus, each peer has only a single "current path", and in stable situations (when nothing MOBIKE-related has been happening recently), the "current path" is equal to the path used for sending IKEv2 requests (for e.g. rekeying). Both peers A and B have their own current path, and they're not always equal (they are never equal if NATs are involved, and even if no NATs are involved, they are different for at least short periods of time when something MOBIKE-related is happening). 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?) 2) Most of the time, RFC2960 uses the word "path" to mean a=20 combination of source and destination address (and mostly avoids the term "address pair"). I much prefer the word "path", and I'd suggest we use that one (but whichever we use, it should be consistent throughout the whole document). 3)=20 The definition of "Available address" says that "Where IPv4 is considered, it is not an RFC 1918 [RFC1918] address." Why? For instance, if the peers are connected to some private network that happens to use RFC 1918 addresses, and there are no NATs involved, why they're not allowed to use MOBIKE? (I'd suggest removing this bullet.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 28 11:42:07 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16906 for ; Fri, 28 Jan 2005 11:42:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 27A1EFB27C; Fri, 28 Jan 2005 16:42:08 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BFBEEFB246; Fri, 28 Jan 2005 16:42:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9292BFB24A; Fri, 28 Jan 2005 16:42:04 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 56882FB240 for ; Fri, 28 Jan 2005 16:42:03 +0000 (UTC) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0SGg0c11080 for ; Fri, 28 Jan 2005 18:42:01 +0200 (EET) X-Scanned: Fri, 28 Jan 2005 18:41:10 +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 j0SGfAoG016571 for ; Fri, 28 Jan 2005 18:41:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00FsLRAp; Fri, 28 Jan 2005 18:41:09 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0SGf7x29501 for ; Fri, 28 Jan 2005 18:41:07 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 10:34:42 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2005 10:34:41 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110493EF15@daebe007.americas.nokia.com> Thread-Topic: More Comments on draft-ietf-mobike-design-02.txt (section 5) Thread-Index: AcUFV0I1J41s7HGKSc6AM83r3aEufw== From: To: X-OriginalArrivalTime: 28 Jan 2005 16:34:42.0253 (UTC) FILETIME=[44AED7D0:01C50557] Subject: [Mobike] More Comments on draft-ietf-mobike-design-02.txt (section 5) 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: quoted-printable I just saw Pasi's message where he suggests some terminology changes. Some of my nits below have to do with inconsistent terminology. So you need to settle on the new terms and just be consistent with then as Pasi says. Some of my nits will be relevant and others won't as a result. Nit:=20 1. Introduction No effort is to be made to make protocols for IKEv1 [RFC2409] or old RFC2401 architecture [RFC2401]. How about: Mobike does not support IKEv1 [RFC2409] or old RFC2401 architecture [RFC2401]. 5.1 Indicating support for MOBIKE I would introduce this section with the following (which I assume is correct): In order for MOBIKE to function correctly, both peers must support it. We propose extensions to IKEv2 described below for MOBIKE support. If only one peer supports MOBIKE, then the peers will just run IKEv2. Specifically, a node needs to be able to.... Nits to change below highlighted with *xxx*. What is not a nit is the use of the word movement. Just because a node moves, doesn't mean that it changes IP address. We need another word.: Note that the node could also attempt MOBIKE optimistically with the critical bit set to one when a movement has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message round is introduced on the first movement. How about: Note that the node could also attempt MOBIKE optimistically with the critical bit set (*text deleted*) when an address change has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message *exchange* is introduced (* text deleted* ). 5.2 Changing a Preferred Address and Multihoming Support From MOBIKE's point of view multihoming support is integrated by supporting a peer address set rather than a single address and protocol mechanisms to change to use a new preferred IP address. From a protocol point of view each peer needs to learn the preferred address and the peer address set somehow, implicitly or explicitly. Another nit in the last sentence: remove somehow: Changing a Preferred Address and Multihoming Support From MOBIKE's point of view multihoming support is integrated by supporting a peer address set rather than a single address and protocol mechanisms to change to use a new preferred IP address. From a protocol point of view each peer needs to learn the preferred address and the peer address set *either* implicitly or explicitly. Section 5.2.1 There is a shift in notation from calling something the preferred address to calling it the primary address. I will point out all the places where this is the case, but you can just do a global edit. It is confusing and I'm not sure why you switched. Did you mean for something called a primary address to be different from the preferred address? I'll assume they are the same in the nits below and change all the primary addresses to preferred address.=20 Original text: MOBIKE does not include load balancing, i.e., only one IP address is set to a preferred address at a time and changing the preferred address typically requires some MOBIKE signaling. Another option is to only communicate one address towards the other peer and both peers only use that address when communicating. If this preferred address cannot be used anymore then an address update is sent to the other peer changing the primary address. Change to: MOBIKE does not *support* load balancing, i.e., only one IP address is set to the preferred address at a time and changing the preferred address typically requires some MOBIKE signaling. Another option is to only communicate one address *to* the other peer and both peers only use that address when communicating. If this preferred address cannot be used anymore then an address update is sent to the other peer changing the *preferred* address. Original text: the recover procedure. The peer, whose IP address changed, must start recovery process and send the new IP address to the other peer. Change to: the *recovery* procedure. The peer, whose IP address changed, must start *the* recovery process and send the new IP address to the other peer. Original text: I thought that the last sentence here is confusing and should be reworked. I have suggestions below. I also thought the one sentence should go with the next paragraph. The problems with IP address list are mostly in its complexity. Notification and recovery processes are more complex, as both end can recover from the IP address changes. There is also possibilities that both ends tries to recover at the same time and this must be taken care in the protocol. Change to: The problems with IP address list are mostly in its complexity. Notification and recovery processes are more complex. *Both ends* can recover from the IP address changes. *However, both peers should not attempt to recover at the same time or nearly the same time as it could cause them to lose connectivity. The Mobike protocol is required to prevent this.* Original Text:=20 Please note that the discussed aspect is partially different from the question how many addresses to sent in a single MOBIKE message.=20 Change to: *The previous discussion is independent of the question of how many addresses to send in a single MOBIKE message.* More later. -- Maureen _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jan 29 08:00:29 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07363 for ; Sat, 29 Jan 2005 08:00:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A0B8CFB27C; Sat, 29 Jan 2005 13:00:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 097D6FB24A; Sat, 29 Jan 2005 13:00:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AACD4FB262; Sat, 29 Jan 2005 13:00:24 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 8252BFB246 for ; Sat, 29 Jan 2005 13:00:23 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j0TD0M07014641; Sat, 29 Jan 2005 14:00:22 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0TD0LiQ019958; Sat, 29 Jan 2005 14:00:21 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jan 2005 14:00:21 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686A31@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Atul.Sharma@nokia.com'" , mobike@machshav.com Subject: AW: [Mobike] question on draft-ietf-mobike-design-01.txt Date: Sat, 29 Jan 2005 14:00:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi atul,=20 thanks for your attempt to clarify this issue. please see my comment = inline: > -----Urspr=FCngliche Nachricht----- > Von: Atul.Sharma@nokia.com [mailto:Atul.Sharma@nokia.com]=20 > Gesendet: Montag, 24. Januar 2005 17:02 > An: Tschofenig Hannes; mobike@machshav.com > Betreff: RE: [Mobike] question on draft-ietf-mobike-design-01.txt >=20 >=20 > Hi Hannes, >=20 > I will give a particular scenario, which will make explicit > the question I was trying to raise. The scenario is inline. >=20 > Atul >=20 > > -----Original Message----- > > From: mobike-bounces@machshav.com=20 > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext Tschofenig Hannes > > Sent: Saturday, January 22, 2005 10:11 AM > > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > > Subject: AW: [Mobike] question on draft-ietf-mobike-design-01.txt > >=20 > >=20 > > hi atul,=20 > >=20 > > > In section 3.2 Multihoming scenario, do we allow simultaneous=20 > > > change of preferred addresses > > > at both the peers? The figure there kind of implies it.=20 > >=20 > > we say that each peer change its preferred address at any=20 > > time and that > > there needs to be a mechanism to communicate this change to=20 > > the other peer.=20 > >=20 > > if the peer address set contains more than one address then=20 > > both peers can > > still communicate with each other even if they happen to=20 > change their > > preferred address at the same time.=20 >=20 > Let us say Peer 1 has addresses A and B; Peer 2 has addresses=20 > C and D. Say > A and C are the advertised preferred addresses. Imagine both=20 > interfaces/paths > corresponding to A and C go down simultaneously. Peer 1 shall=20 > send to Peer 2 > on address C telling the new preferred address is B. Peer 2=20 > shall send to > Peer 1 on address A telling the new preferred address is D.=20 > But none of these > MOBIKE address change messages shall reach the other end. the path a <-> c does not work anymore because the respective interface = at each peer is down.=20 now, what happens depends on the previously communicated peer address = set. if peer 1 and peer 2 decided that they communicate the peer address set {a,b} and {c,d} for peer1 and peer2 respectively then both nodes can recover.=20 >=20 > Do we in the MOBIKE protocol incorporate the assumption that=20 > Peer 1 shall > always know of addresses C and D of Peer 2; and on not=20 > getting the ack from > Peer 2 on address change shall try sending the address change=20 > notification > to address D? we don't need to make the assumption that each peer communicates all = its addresses. i would rather see this as a local decision of each peer = which address to advertise. however, as we can see in the previous example it would certainly help. peer 1 might not want to send all its addresses = to the other peer.=20 >=20 > I had this kind of simultaneous change of preferred address=20 > in mind for the=20 > original question. >=20 >=20 > > (btw, i don't think that the figure is good enough to show=20 > > this situation.) >=20 > The figure does not explicitly describe this situatiopn, it=20 > just implies it > by saying: "If Peer A and Peer B change their preferred address". > =20 > > what is outside the scope is the case where a third entity would be > > required.=20 >=20 > I understand that, we are not taking the MobileIP path. > > >=20 > > > Could we explicitly say there whether we support such a=20 > > > simultaneous change?=20 > >=20 > > we can add something explicitly, if you think it is necessary.=20 >=20 > I think, it will definitely help. >=20 i think that an example, similar to the one above would certainly help. = ciao hannes > >=20 > > ciao > > hannes > >=20 > > >=20 > > > Atul > > >=20 > > > _______________________________________________ > > > 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 > >=20 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jan 29 08:43:46 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10409 for ; Sat, 29 Jan 2005 08:43:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8C73EFB27F; Sat, 29 Jan 2005 13:43:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 429D4FB262; Sat, 29 Jan 2005 13:43:44 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 23729FB266; Sat, 29 Jan 2005 13:43:43 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id DEBFAFB24A for ; Sat, 29 Jan 2005 13:43:41 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j0TDhcaA017361; Sat, 29 Jan 2005 14:43:40 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0TDhciQ005133; Sat, 29 Jan 2005 14:43:38 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jan 2005 14:43:38 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686A32@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Pasi.Eronen@nokia.com'" , mobike@machshav.com Subject: AW: [Mobike] intermediate mobike design draft update Date: Sat, 29 Jan 2005 14:43:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi pasi, thanks for your feedback. let me give you some comments below: > Hi, > > I have some comments and suggestions about the terminology about > addresses/pairs/paths in mobike-design-02. > > 1) > > Currently the definition of "preferred address pair" is quite > imprecise, since it unnecessarily mixes what is preferred with > what is actually happening. Also, it's not quite clear what's > the difference between "preferred address pair" and "primary > path". > > I'd suggest we replace both of them with a new term, say > "current path" (or "current address pair"), that means the > addresses that are currently used by the peer as the tunnel > header addresses of IPsec packets (of IPsec SAs associated > with this IKE SA). i tried to prevent reinventing new terms here and used the term 'preferred address' from it is true that the definition of preferred address pair and primary path point to the same concept. i have replaced the term "preferred address pair" with "primary path". > > I think we had rough consensus on issue 8 (scope of SA changes); > thus, each peer has only a single "current path", and in stable > situations (when nothing MOBIKE-related has been happening > recently), the "current path" is equal to the path used for > sending IKEv2 requests (for e.g. rekeying). true. > > Both peers A and B have their own current path, and they're not > always equal (they are never equal if NATs are involved, and > even if no NATs are involved, they are different for at least > short periods of time when something MOBIKE-related is > happening). it is true that each peer has it's own view of the world and there might be an inconsistency of the established state information. ideally, the state of the two peers should be synchronized. based on i would, however, argue that we both peers try to have the same primary path. this means, for example, if peer 1 has a preferred address ip_a and peer 2 has a preferred address ip_b then the path is between ip_a <-> ip_b for both peers. we could also utilize something like an undirectionally operational address pair (definition from ). this would mean (with the above example) that peer 1 would send messages to ip_b at peer 2 and peer 2 would return messages to an address ip_a2 (although the source address of the mesgs hitting peer 2 use ip_a1). this approach would, however, cause problems with nat handling. > > 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?) > regarding sctp there is very little text on how addresses are selected (at least i haven't found the text paragraphs). it is just a policy issue. since we are concerned about nat handling we should talk about bidirectionally operational address pairs. > 2) > > Most of the time, RFC2960 uses the word "path" to mean a > combination of source and destination address (and mostly > avoids the term "address pair"). I much prefer the word "path", > and I'd suggest we use that one (but whichever we use, it > should be consistent throughout the whole document). > i agree with you. > 3) > > The definition of "Available address" says that "Where IPv4 is > considered, it is not an RFC 1918 [RFC1918] address." Why? For > instance, if the peers are connected to some private network > that happens to use RFC 1918 addresses, and there are no NATs > involved, why they're not allowed to use MOBIKE? (I'd suggest > removing this bullet.) i fully agree with you. i asked myself the same question when i read but then i forgot it again when i copied the text from jari's draft to this draft. > thanks for your feedback. ciao hannes > > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jan 29 10:50:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18868 for ; Sat, 29 Jan 2005 10:50:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 87C69FB27F; Sat, 29 Jan 2005 15:50:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 154CDFB266; Sat, 29 Jan 2005 15:50:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 211C5FB277; Sat, 29 Jan 2005 15:50:05 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 14D42FB262 for ; Sat, 29 Jan 2005 15:50:04 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j0TFo207007595 for ; Sat, 29 Jan 2005 16:50:03 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0TFo2iQ000255 for ; Sat, 29 Jan 2005 16:50:02 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jan 2005 16:50:02 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686A35@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: mobike@machshav.com Date: Sat, 29 Jan 2005 16:49:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] latest draft snapshot 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 hi all, based on the comments by atul, pasi, tom henderson and maureen i have updated the draft. thanks a lot for the good feedback! please find the latest draft snapshot at the following link: http://www.tschofenig.com/TEMP/TEMP-draft-ietf-mobike-design-02_29Jan2005.tx t http://www.tschofenig.com/TEMP/TEMP-draft-ietf-mobike-design-02_29Jan2005.ht ml i haven't added a detailed example to the document yet. (that's something for next week.) ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jan 29 10:51:18 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18961 for ; Sat, 29 Jan 2005 10:51:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 06B67FB282; Sat, 29 Jan 2005 15:51:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 642B4FB277; Sat, 29 Jan 2005 15:51:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 20110FB277; Sat, 29 Jan 2005 15:51:15 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 9BF14FB262 for ; Sat, 29 Jan 2005 15:51:13 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j0TFpCFF028201; Sat, 29 Jan 2005 16:51:12 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0TFpCiQ000562; Sat, 29 Jan 2005 16:51:12 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jan 2005 16:51:12 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686A36@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Maureen.Stillman@nokia.com'" , "'mobike@machshav.com'" Subject: AW: [Mobike] More Comments on draft-ietf-mobike-design-02.txt (se ction 5) Date: Sat, 29 Jan 2005 16:51:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi maureen,=20 thanks for the suggestions. i have incorporated them into the latest = draft version.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Maureen.Stillman@nokia.com [mailto:Maureen.Stillman@nokia.com]=20 > Gesendet: Freitag, 28. Januar 2005 17:35 > An: mobike@machshav.com > Betreff: [Mobike] More Comments on=20 > draft-ietf-mobike-design-02.txt (section 5) >=20 >=20 > I just saw Pasi's message where he suggests some terminology changes. > Some of my nits below have to do with inconsistent=20 > terminology. So you > need to settle on the new terms and just be consistent with=20 > then as Pasi > says. Some of my nits will be relevant and others won't as a result. >=20 > Nit:=20 > 1. Introduction >=20 > No effort is to be > made to make protocols for IKEv1 [RFC2409] or old RFC2401 > architecture [RFC2401]. >=20 > How about: >=20 > Mobike does not support IKEv1 [RFC2409] or old RFC2401 > architecture [RFC2401]. >=20 > 5.1 Indicating support for MOBIKE >=20 > I would introduce this section with the following (which I assume is > correct): >=20 > In order for MOBIKE to function correctly, both peers must support = it. > We propose extensions to IKEv2 described below for MOBIKE support. = If > only one peer supports MOBIKE, then the peers will just run IKEv2. > Specifically, a node needs to be able to.... >=20 >=20 > Nits to change below highlighted with *xxx*. What is not a nit is = the > use of the word movement. Just because a node moves, doesn't=20 > mean that > it changes IP address. We need another word.: >=20 > Note that the node could also attempt MOBIKE optimistically with the > critical bit set to one when a movement has occurred. The = drawback > of this approach is, however, that the an unnecessary=20 > MOBIKE message > round is introduced on the first movement. >=20 > How about: >=20 > Note that the node could also attempt MOBIKE optimistically with the > critical bit set (*text deleted*) when an address change has > occurred. The drawback > of this approach is, however, that the an unnecessary=20 > MOBIKE message > *exchange* is introduced (* text deleted* ). >=20 > 5.2 Changing a Preferred Address and Multihoming Support >=20 > From MOBIKE's point of view multihoming support is integrated by > supporting a peer address set rather than a single address and > protocol mechanisms to change to use a new preferred IP address. > From a protocol point of view each peer needs to learn the=20 > preferred > address and the peer address set somehow, implicitly or = explicitly. >=20 > Another nit in the last sentence: remove somehow: >=20 > Changing a Preferred Address and Multihoming Support >=20 > From MOBIKE's point of view multihoming support is integrated by > supporting a peer address set rather than a single address and > protocol mechanisms to change to use a new preferred IP address. > From a protocol point of view each peer needs to learn the=20 > preferred > address and the peer address set *either* implicitly or = explicitly. >=20 > Section 5.2.1 >=20 > There is a shift in notation from calling something the preferred > address to calling it the primary address. I will point out all the > places where this is the case, but you can just do a global=20 > edit. It is > confusing and I'm not sure why you switched. Did you mean=20 > for something > called a primary address to be different from the preferred address? > I'll assume they are the same in the nits below and change all the > primary addresses to preferred address.=20 >=20 > Original text: >=20 > MOBIKE does not include > load balancing, i.e., only one IP address is set to a preferred > address at a time and changing the preferred address typically > requires some MOBIKE signaling. >=20 > Another option is to only communicate one address towards the other > peer and both peers only use that address when communicating. If > this preferred address cannot be used anymore then an=20 > address update > is sent to the other peer changing the primary address. >=20 > Change to: > MOBIKE does not *support* > load balancing, i.e., only one IP address is set to the preferred > address at a time and changing the preferred address typically > requires some MOBIKE signaling. >=20 > Another option is to only communicate one address *to* the other > peer and both peers only use that address when communicating. If > this preferred address cannot be used anymore then an=20 > address update > is sent to the other peer changing the *preferred* address. >=20 > Original text: >=20 > the recover > procedure. The peer, whose IP address changed, must start = recovery > process and send the new IP address to the other peer. >=20 > Change to: > the *recovery* > procedure. The peer, whose IP address changed, must start *the* > recovery > process and send the new IP address to the other peer. >=20 > Original text: >=20 > I thought that the last sentence here is confusing and should be > reworked. I have suggestions below. I also thought the one sentence > should go with the next paragraph. >=20 > The problems with IP address list are mostly in its complexity. >=20 >=20 > Notification and recovery processes are more complex, as=20 > both end can > recover from the IP address changes. There is also possibilities > that both ends tries to recover at the same time and this must be > taken care in the protocol. >=20 > Change to: >=20 > The problems with IP address list are mostly in its complexity. > Notification and recovery processes are more complex. *Both ends* can > recover from the IP address changes. *However, both peers=20 > should not > attempt to recover at the same time or nearly the same time=20 > as it could > cause them to lose connectivity. The Mobike protocol is required to > prevent this.* >=20 > Original Text:=20 >=20 > Please note that the discussed aspect is partially different from the > question how many addresses to sent in a single MOBIKE message.=20 >=20 >=20 > Change to: >=20 > *The previous discussion is independent of the question of how many > addresses to send in a single MOBIKE message.* >=20 > More later. >=20 >=20 > -- Maureen >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 From mobike-bounces@machshav.com Mon Jan 31 11:14:06 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17864 for ; Mon, 31 Jan 2005 11:14:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9AD0FFB280; Mon, 31 Jan 2005 16:14:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6FF3AFB27C; Mon, 31 Jan 2005 16:14:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CC61AFB27D; Mon, 31 Jan 2005 16:14:03 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id A9B5AFB24A for ; Mon, 31 Jan 2005 16:14:02 +0000 (UTC) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VGDsc01111; Mon, 31 Jan 2005 18:13:55 +0200 (EET) X-Scanned: Mon, 31 Jan 2005 18:12:27 +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 j0VGCR65018986; Mon, 31 Jan 2005 18:12:27 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00JdUx2B; Mon, 31 Jan 2005 18:09:12 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VG9Cx24966; Mon, 31 Jan 2005 18:09:12 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 18:08:54 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 18:08:54 +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] intermediate mobike design draft update Date: Mon, 31 Jan 2005 18:08:54 +0200 Message-ID: Thread-Topic: [Mobike] intermediate mobike design draft update Thread-Index: AcUGCJXQM/jiLOBASoWrU4y4nykqvgBpfdQA From: To: , X-OriginalArrivalTime: 31 Jan 2005 16:08:54.0996 (UTC) FILETIME=[29AF6940:01C507AF] 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: quoted-printable hannes.tschofenig@siemens.com writes: >=20 > hi pasi,=20 >=20 > thanks for your feedback. let me give you some comments below:=20 >=20 >> Hi, >>=20 >> I have some comments and suggestions about the terminology about >> addresses/pairs/paths in mobike-design-02. >>=20 >> 1) >>=20 >> Currently the definition of "preferred address pair" is quite >> imprecise, since it unnecessarily mixes what is preferred with >> what is actually happening. Also, it's not quite clear what's >> the difference between "preferred address pair" and "primary >> path". >>=20 >> I'd suggest we replace both of them with a new term, say >> "current path" (or "current address pair"), that means the >> addresses that are currently used by the peer as the tunnel >> header addresses of IPsec packets (of IPsec SAs associated >> with this IKE SA). >=20 > i tried to prevent reinventing new terms here and used the > term 'preferred address' from >=20 > it is true that the definition of preferred address pair and > primary path point to the same concept. >=20 > i have replaced the term "preferred address pair" with > "primary path". Hmm... I think they _don't_ actually point to the same concept... "Preferred address" is about preferences, and "preferred address pair" is just the combination of A's and B's preferred address. But this is not necessarily always the src/dst address that is=20 actually put to outbound packets. To give a concrete example, suppose that A and B have addresses A1,A2,B1,B2; A prefers A1 and B prefers B1, and both parties have "current path" A1,B1. Now, suppose that A does dead peer detection and does not get a response (even after retransmissions). But if A notices that A2,B2 works, it sounds very reasonable to change the current path to that (and then do whatever MOBIKE signaling is necessary). So, if the "preferred address pair" and "current path" are the same concept, that seems to imply that one party can change the other one's preferred address? (But this is not in line with the current definition of "preferred address"... so I think we have two different concepts here) >> Both peers A and B have their own current path, and they're not >> always equal (they are never equal if NATs are involved, and >> even if no NATs are involved, they are different for at least >> short periods of time when something MOBIKE-related is >> happening). >=20 > it is true that each peer has it's own view of the world and > there might be an inconsistency of the established state > information. ideally, the state of the two peers should be > synchronized. I'm not so sure... This is not really a synchronization problem, but a preference combination problem. Both A and B have their own preferences, and some information about the other's preferences. But this does not guarantee that they end up=20 with the same "current path". For instance, if A prefers A1 to A2, and B prefers B1 to B2; A1,B1 doesn't work, but both A1,B2 and A2,B1 do, which one should be the single synchronized "current path"? It seems that if we want both parties to have the same "current path" (in stable situations), either one party has to make the decision (like in MOPO-IKE), or the we have to severely restrict the kinds of preferences that can be used, and give the decision algorithm in the spec (so that both parties always end up with the same path). (It's of course a good question whether having the same "current path" in stable situations is necessary or not. I think it simplifies things, and that's why in MOPO-IKE the initiator's choice is used in stable situations.) > > 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?) >=20 > regarding sctp there is very little text on how addresses are > selected (at least i haven't found the text paragraphs). it > is just a policy issue. since we are concerned about nat > handling we should talk about bidirectionally operational > address pairs. Yes, I think SCTP leaves address selection as a policy issue. And since both ends have their own policy, they can end up using different addresses (even if all address pairs work in both directions). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 31 19:47:54 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00927 for ; Mon, 31 Jan 2005 19:47:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AE629FB27F; Tue, 1 Feb 2005 00:47:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BA39FFB27C; Tue, 1 Feb 2005 00:47:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B9923FB27D; Tue, 1 Feb 2005 00:47:52 +0000 (UTC) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 1B99FFB240 for ; Tue, 1 Feb 2005 00:47:52 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2005 17:57:50 +0000 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 sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j110lgNt012871; Mon, 31 Jan 2005 16:47:46 -0800 (PST) Received: from boraw2k05 (dhcp-128-107-178-162.cisco.com [128.107.178.162]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWA96049; Mon, 31 Jan 2005 16:47:37 -0800 (PST) Message-Id: <200502010047.AWA96049@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Tschofenig Hannes'" , Subject: RE: [Mobike] latest draft snapshot Date: Mon, 31 Jan 2005 16:47:36 -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: <2A8DB02E3018D411901B009027FD3A3F04686A35@mchp905a.mch.sbs.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUHvTXw6FmDbuHUTjazWGJWzhhJFwANt75A 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 Hi I also have a few comments on this draft (sorry I am behind by a few weeks), and I will classify them into two categories (by the way, the Jan 29 version is much better than 01): (SG : security gateway) 1) Editorial: I think in section (3) scenarios, if we had previously reached consensus that at a given time only one address pair will be used, then I recommend trimming this section down to: -- Break-before-make address transition -- Make-before-break address transition: (the bottom two are really examples of MBB address transition) Figure 3: Framework (while being really a nice figure) does not capture many implementations and scenarios that are deployed in various devices today. So I would consider this figure as an example of a UNIX-centric host implementation as opposed to what may end up being deployed in a security gateway. I suggest (and I can help with this), replacing this figure with something considerably simpler that has basic building blocks. PF_KEY API while being used in the text does not seem to have a direct reference (quite possibly I missed this). In general, I think rename this draft to be "Framework for MOBIKE." Then do a requirements draft that has as little text as possible. 2) Substantive: I disagree strongly with the need to be able to "test connectivity along a path and thereby detect an outage situation" other than what we do in IKEv2 DPD today. With mobile users expected to be in the 1,000,000 range per security gateway, the amount of state and processing that needs to be performed is significant when the SG tries to detect path changes other than what we do with DPD. If the client decides to do this, then it is fine. However, even with DPD, then the SG needs to try several IP addresses to see which ones work is a significant burden on the SG. Therefore, I would suggest that we clarify what functionality is required on a client vs security gateway (yes, this focuses mostly on the VPN scenario, but that is the main push for MOBIKE as far as I understand). Fundamentally, I think we have three problems that we need to solve: 1) Identify a peer regardless of the IP address it chooses to use. (Not-mutable Peer Identity) 2) Change the IP address pairs associated with IPSEC and IKE SAs while not impacting the data path significantly. 3) Clean up resources on both ends of the connection(s) so that neither end (but especially the SG is not susceptible to resource outages) I think the framework does a good job of identifying these problems. Regards, Bora _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike