From mobike-bounces@machshav.com Tue Jan 03 09:19:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etn0g-0000UN-On for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 09:19:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28674 for ; Tue, 3 Jan 2006 09:18:19 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CD2C5FB284; Tue, 3 Jan 2006 09:19:28 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 70D3CFB27C; Tue, 3 Jan 2006 09:19:27 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0C7DFFB27D; Tue, 3 Jan 2006 09:19:26 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 9D2D2FB24F for ; Tue, 3 Jan 2006 09:19:24 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03EJLmw008784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jan 2006 16:19:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03EJKwr022195; Tue, 3 Jan 2006 16:19:20 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.34792.795549.382078@fireball.acr.fi> Date: Tue, 3 Jan 2006 16:19:20 +0200 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Subject: [Mobike] Design draft comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I now have put all the comments received during the working group last call to separate issue page. I have not yet checked them out properly, I simply just put them all there first, and next I will start processing them. The list of issues for the design draft can be found from the http://www.kivinen.iki.fi/ietf/mobike-design-issues.html. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 10:19:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etnwq-0006Xa-FA for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 10:19:41 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04949 for ; Tue, 3 Jan 2006 10:18:25 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F1716FB28B; Tue, 3 Jan 2006 10:19:37 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 15B59FB27C; Tue, 3 Jan 2006 10:19:31 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DFEE6FB282; Tue, 3 Jan 2006 10:17:05 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 5B86DFB27C for ; Tue, 3 Jan 2006 10:16:59 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03FGrIi029692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 17:16:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03FGrOY013675; Tue, 3 Jan 2006 17:16:53 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.38245.21488.69655@fireball.acr.fi> Date: Tue, 3 Jan 2006 17:16:53 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A93351.7090105@piuha.net> References: <43A93351.7090105@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 46 min X-Total-Time: 56 min X-Mailman-Approved-At: Tue, 03 Jan 2006 10:19:27 -0500 Cc: MOBIKE Mailing List Subject: [Mobike] #D101: design draft issue: editorial X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > Abstract: > ====== > > > The MOBIKE (IKEv2 Mobility and Multihoming) working group is > > developing extensions for the Internet Key Exchange Protocol version > > 2 (IKEv2). > > For someone that reads this later the references to WG may not make a > lot of sense. Rewrite as "MOBIKE (...) is an extension of the ...". Done. > Section 1: > ========== > > > However, this can be problematic, as the device > > might be too slow for this task. > > Maybe "However, this is a relatively expensive operation, > and can be problematic when such changes are frequent." Done. > > The work of the MOBIKE working group and therefore this document is > > based on the assumption that the mobility and multi-homing extensions > > are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on > > Another unnecessary reference to the WG. Just say "The MOBIKE protocol > is assumed to work on top of ..." or something to that effect. Changed to: The MOBIKE protocol is assumed to work on top of IKEv2 . > > This document neither discusses mobility and multi- > > homing support for IKEv1 [RFC2409] nor the IPsec architecture > > described in RFC2401 [RFC2401]. > > There seems to be something wrong with "neither" here. Say "This document > does not discuss ..." Done. > Section 2: > ========== > > > Peer: > > I think the colon is unnecessary here. Removed colons from all terms. > > local-addr]. That is, it is not an IPv6 link-local. > > ... address. Added. > > This definition is taken from [I-D.arkko-multi6dt-failure- > > detection], and adapted to the MOBIKE context (we do allow > > [RFC1918] addresses here, they are very common addresses used > > inside NATs). > > Just add a plain reference, not explain the differences, since the > differences keep changing as the SHIM6 work proceeds. Also, the > reference is I-D.ietf-shim6-failure-detection. I was wondering that if someone who is very familiar with the shim6 work would not notice that we are using different definition here, so we should point out the differences, but if the terms defined there are not well defined yet, then better remove the differences part. > Similar for the other definitions. I do not think there was differences in other terms, but fixed the references. > Section 3: > ========== > > > Even if IP addresses change due to interface switching or mobility, > > the IP address obtained via the configuration payloads within IKEv2 > > remain unaffected. The IP address obtained via the IKEv2 > > configuration payloads allow the configuration of the inner IP > > address of the IPsec tunnel. As such, applications might not detect > > any change at all. > > This text in Section 3.3 seems to apply to all scenarios. Say "In all > of these scenarios, even if ..." Done. > Section 4: > ========== > > > This > > current design document focuses mainly on tunnel mode, everything > > going inside the tunnel is unaffected by the changes in the tunnel > > header IP address, and this is the mobility feature provided by the > > MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec > > tunnel might not detect the movement since their IP addresses remain > > constant. > > s/This current/The/ Done. > "mainly"? There used to be some more text about transport mode here, but now we only say that there will be future ducouments, so removed "mainly" > And there's some duplication with end of Section 3. Suggest: merge > the paragraphs and place them in Section 4. Can you give more exact editing instructions, so I can do the changes. > > MOBIKE interacts with the IPsec engine using for > > example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon > > can create entries in the Security Association (SAD) and Security > > Policy Databases (SPD). > > Maybe say "... using an internal API (such as those based on > PF_KEY [RFC2367]). Using such an API..." Done. > > Extensions of the PF_KEY interface required by MOBIKE are also within > > the scope of the working group. Finally, certain optimizations for > > wireless environments are also covered. > > Don't talk about the other work items in the WG. Delete this > paragraph. Removed. > Section 5: > ========== > > > Choosing addresses for > > the IKEv2 request is a somewhat separate problem: in many cases, they > > will be the same (and in some design choice they will always be the > > same). > > ... will be the same, and could be forced to be the same by design. Done. > > MOBIKE > > does not support unidirectional address pairs (i.e. where you can > > only send traffic in one direction when using single address pair). > > No need to redefine the term here. Just end after the word "pairs". Removed the definition. This used to be the only place earlier, but forgot to remove this when added the definition to the terminology section. > > Note that MOBIKE is not really concerned about the actual path used, > > it cannot even detect if some path is unidirectionally operational if > > the same address pair has some other unidirectional path back. > > s/really// Done. > > To detect connectivity, i.e., failures along the path, the MOBIKE > > protocol needs to have a mechanism to test connectivity. If a MOBIKE > > s/, i.e., failures along the path// Done. > s/lots/many/ Done. > > One of the main decisions in designing the MOBIKE protocol is who > > s/decisions/questions/ > s/is/was/ Done. > > As a consequence the outcome cannot > > be asymmetric decisions. > > ... the outcome is always the same for both parties. Done. > > The NAT-T support should also be optional, i.e., if the IKEv2 > > implementation does not implement NAT-T, as it is not required in > > some particular environment, implementing MOBIKE should not require > > adding support for NAT-T as well. > > s/as well/either/ Done. > > There are some cases which cannot be carried out within the > > restrictions of the MOBIKE charter. > > To avoid talking about the charter, just say "... within MOBIKE". Hmm.... Then reader might be wondering why we cannot do that. Protocol might be able to be designed to support those cases, but they are out of scope of the charter, thus we cannot do them with MOBIKE. Anyways removed the text about charter restrictions. > > On the other hand, as all implementations supporting NAT-T must be > > able to respond to port 4500 all the time, it is simpler from the > > protocol point of view to change the port numbers from 500 to 4500 > > immediately when we detect that the other end supports NAT-T. This > > way we do not need to start changing ports after we later detected > > NAT, which would have caused complications to the protocol. > > s/when we detect/upon detecting/ > s/we do not need to start changing/it is not necessary to change/ Done. > (Its better style to not use "we", I think. Go through the rest of > the document, too, there are multiple occurrences. Such as in the > next paragraph.) There is way too many occurrences that I do not want to start fixing them all now. Actually I myself find it sometimes easier to read text that uses "we" than text written to avoid using "we". > > The working group decided that MOBIKE uses NAT-T mechanisms from the > > IKEv2 protocol as much as possible, but decided to change the dynamic > > address update for IKEv2 packets to MUST NOT (it would break path > > testing using IKEv2 packets, see Section 6.2). The working group > > also decided to only send keepalives to the current address pair. > > Dynamic address update for IPsec packets? I'm unsure what you mean > here. In any case, pointing to the actual requirement in IKEv2 spec > would be useful here. RFC 4306, section 2.23 second last paragraph. It is little bit hard to put exact references to the section 2.23 as it is several pages long and this text refers to the one paragraph in there. If you search "dynamically update the address" from the ikev2 document you will find the correct place. Didn't do anything for this yet. > > From a technical point of view this feature addresses two issues: > > > > o There is no need to transmit IPsec data traffic. IPsec protected > > data can be dropped which saves bandwidth. This does not provide > > a functional benefit, i.e., nothing breaks if this feature is not > > provided. > > > > o MOBIKE signaling messages are also ignored. The IKE-SA must not > > be deleted and the suspend functionality (realized with the zero > > address set) may require the IKE-SA to be tagged with a lifetime > > value since the IKE-SA should not be kept alive for an undefined > > period of time. Note that IKEv2 does not require that the IKE-SA > > has a lifetime associated with it. In order to prevent the IKE-SA > > from being deleted the dead-peer detection mechanism needs to be > > suspended as well. > > ... this feature raises two issues? As zero address set functionality would be solving those two issues, I would say it addresses those issues, not raises them. They are already present in the current protocol, and we do not propose any solution for them now. I.e the issues is that we waste bandwidth by sending data which will be ignored by the other end, and we tear down the IKE SA because the other end cannot reply to our signaling packets. Perhaps better way woud be to say "From a technical point of view this would provide following two features:"? > > Due to the fact that this extension could be complicated and there > > was no clear need for it, a first version of the MOBIKE protocol will > > not provide this feature. > > Due to its complexity and no clear requirement for it, it was decided > that MOBIKE does not support this feature. Done. > > What happens there is that the initiator does the normal address > > update, and that succeeds, and then the responder starts a return > > routability check. > > s/does/performs/ Done. > > the same as the return routability check in MIP6: The MIP6 WG decided > > is different from Mobile IPv6 [RFC 3775], which does not > perform return routability operations between the mobile node > and its home agent at all. Done. > > Working group decided to use a protocol format where both ends send a > > full list of their addresses to the other end, and that list > > overwrites the previous list. To support NAT-T the IP-addresses of > > the received packet is added to the list (and they are not present in > > the list). > > ...are considered as one address of the peer, even if not present > in the list. Done. > Other: > ===== > > > be routed along a different path, for example by load balancers. > > s/by load balancers/due to load balancing/ > > (My speller didn't think "balancer" is a word.) Done. (ispell do claim that "balancer" is correct because of root word "balance"). > > the correct IP addresses before the initiator can belive it is alive > > s/belive/believe/ Done. (Ispell did consider belive to be correct because of root word "bel" :-) > > redirections by an authenticated attacker. Return routability checks > > s/redirections/redirection/ Done. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 10:26:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eto3v-0000PF-6t for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 10:26:59 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05862 for ; Tue, 3 Jan 2006 10:25:43 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E1B13FB284; Tue, 3 Jan 2006 10:26:55 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A9160FB27C; Tue, 3 Jan 2006 10:26:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 006BAFB27D; Tue, 3 Jan 2006 10:26:53 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D07FEFB24A for ; Tue, 3 Jan 2006 10:26:51 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03FQngi014802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 17:26:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03FQmBf001059; Tue, 3 Jan 2006 17:26:48 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.38840.873375.724594@fireball.acr.fi> Date: Tue, 3 Jan 2006 17:26:48 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A9335A.2020906@piuha.net> References: <43A9335A.2020906@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: MOBIKE Mailing List Subject: [Mobike] design draft issue: existing documents claim X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > > IKEv2 assumes that an IKE SA is created implicitly between the IP > > address pair that is used during the protocol execution when > > establishing the IKEv2 SA. This means that, in each host, only one > > IP address pair is stored for the IKEv2 SA as part of a single IKEv2 > > protocol session, and, for tunnel mode SAs, the hosts places this > > single pair in the outer IP headers. Existing documents make no > > provision to change this pair after an IKE SA is created. > But doesn't NAT-T allow a limited form of changes? There is text in the RFC 4306 section 2.23 saying that implementation SHOULD dynamically update the address of the host behind NAT if they detect it is changed, but that is only limited for the NAT-T case and only so that host not behind NAT does that for host behind NAT. I added text saying "(except for dynamic address update of NAT-T)" to the end. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 11:04:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etody-00031O-Pu for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 11:04:16 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14564 for ; Tue, 3 Jan 2006 11:03:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C5472FB284; Tue, 3 Jan 2006 11:04:12 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 02C14FB27C; Tue, 3 Jan 2006 11:04:10 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 77CDFFB27D; Tue, 3 Jan 2006 11:04:08 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 06FE9FB24F for ; Tue, 3 Jan 2006 11:04:06 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03G41qm003540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:04:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03G41OE019447; Tue, 3 Jan 2006 18:04:01 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.41073.164519.184463@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:04:01 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A93382.2060600@piuha.net> References: <43A93382.2060600@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 30 min Cc: MOBIKE Mailing List Subject: [Mobike] D103 design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > > > Primary Path: > The protocol draft uses the term "current path" (and so does > the latest version of the SHIM6 draft where the primary path > term was originally taken from). > > Use the term "current path" instead here in Section 2 as well > as in the rest of the document. Changed to use current instead of primary. > > > Preferred Address: > > > > The IP address of a peer to which MOBIKE and IPsec traffic should > > be sent by default. A given peer has only one active preferred > > address at a given point in time, except for the small time period > > where it switches from an old to a new preferred address. This > > definition is taken from [I-D.ietf-hip-mm] and adapted to the > > MOBIKE context. > > The protocol draft does not use this term. True, but design document do use this term when describing different options we had. This document is not only describing what we have in the protocol document (the protocol document does that), this also describes why and how we ended up there. > Peer address set is closer to what we want here? No peer address set is the set of all addresses, and preferred address is the one address the other end preferred to be used. If we have only one address pair in use (as we have with initiator decides option) then the preferred addresses and current addresses are mostly same. > (Also, I'm not sure the protocol we have actually communicates > the address preferences. The initiator makes a decision, but > does the ordering in an address update indicate preference?) In current protocolwe do not communicate that, but we did consider options where we did communicate those, and we do describe those in the document, and then we say we ended up using initiator decides. > > The MOBIKE protocol should be able to perform the following > > operations: > > > > o Inform the other peer about the peer address set > > > > o Inform the other peer about the preferred address > > > > o Test connectivity along a path and thereby to detect an outage > > situation > > > > o Change the preferred address > > Again, not sure we actually communicate the preferred > information -- but I may be missing something. In initiator decides the preferred information is not needed to be communicated that much, as initiator decides... the initiator simply needs to know his own preferences and use those, as he is the one making decisions. Again in other options we would need that information. > > Another MOBIKE usage scenario is depicted in Figure 2. In this > > scenario, the MOBIKE peers are equipped with multiple interfaces (and > > multiple IP addresses). Peer A has two interface cards with two IP > > addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 > > and IP_B2. Each peer selects one of its IP addresses as the > > preferred address which is used for subsequent communication. > > Various reasons (e.g., hardware or network link failures), may > > require a peer to switch from one interface to another. > > Is this in line with what the protocol draft does? No, and it does not try to be aligned. We are describing generic scenario, the actual protocol work differs from this generic scenario, and we do not fully support this in the protocol we selected. As in our case the initiator decides the preferences then the responders preferences are ignored in our protocol. > > Operational address pair: > > > > A pair of operational addresses are said to be an operational > > address pair, if and only if bidirectional connectivity can be > > shown between the two addresses. Note that sometimes it is > > necessary to consider connectivity on a per-flow level between two > > endpoints. This differentiation might be necessary to address > > certain Network Address Translation types or specific firewalls. > > This definition is taken from [I-D.arkko-multi6dt-failure- > > detection] and adapted for the MOBIKE context. Although it is > > possible to further differentiate unidirectional and bidirectional > > operational address pairs, only bidirectional connectivity is > > relevant to this document and unidirectional connectivity is out > > of scope. > > (snip) > > > Bidirectional Address Pair:: > > > > The address pair, where traffic can be sent to the both > > directions, simply by reversing the IP addresses. Note, that the > > path of the packets going to each direction might be different. > > > > Unidirectional Address Pair:: > > > > The address pair, where traffic can only be sent in one direction, > > and reversing the IP addresses and sending reply back does not > > work. > > The explanation of directionality on the first definition > seems superfluous. Mostly leftovers from the time when we didn't have bidirectional / unidirectional address pairs defined here at all. On the other hand, I do not think the extra text there does any harm, and might actually make it easier to understand what operational address pair is. I do hate terms refering to other terms refering to other terms where you need to parse through several definations of the terms before you can find out what the term actually means. > > Figure 1 shows a break-before-make mobility scenario where a mobile > > node changes its point of network attachment. Prior to the change, > > the mobile node had established an IPsec connection with a security > > gateway which offered, for example, access to a corporate network. > > The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took > > place over the path labeled as 'old path'. The involved packets > > carried the MN's "old" IP address and were forwarded by the "old" > > access router (OAR) to the security gateway (GW). > > Consider talking only about routers, not access routers. I actually think access router is better, as we are not talking about routers in the general, we are talking about the closest router providing us the access to the internet. > > MOBIKE interacts with the IPsec engine using for > > example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon > > can create entries in the Security Association (SAD) and Security > > Policy Databases (SPD). The IPsec engine may also interact with > > IKEv2 and MOBIKE daemon using this API. > > "IPsec engine" is a term that exists in RFC2401, I think. Use > "IPsec implementation" or some other term. Nope. IPsec engine is not defined in the RFC 2401 or in the RFC 4301. I have normally used IPsec engine to refer to the "kernel" side of the IPsec implementation, i.e. things related to the actual packets, SAD, and partly SPD too (i.e. those parts of SPD which are not related to the IKE or policy management). IPsec implementation is bit wrong, as MOBIKE can be considered as part of IPsec implementation too... as it is IKEv2 extension and IKEv2 is part of IPsec implementation (i.e. part of the IPsec architecture defined in RFC 4301). If you have better term to use than IPsec engine, I can switch to that, but I myself cannot think one now. > > In order to address certain failure > > cases, MOBIKE should perform connectivity tests between the peers > > (potentially over a number of different paths). > > I think they are called "path tests" in the protocol draft. I think path tests is bad name, as we are not testing paths, we are testing connectivity between two addresses. > > Those external hole punching mechanisms are beyond the scope of > > Firewall pinhole opening is a better term, I think. Changed. > > One type of attack that needs to be taken care of in the MOBIKE > > protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec] > > and [Aur02] for more information about flooding attacks. > > Called bombing attack earlier, and in the protocol draft. Changed. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 11:22:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtovY-0006ym-29 for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 11:22:24 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17511 for ; Tue, 3 Jan 2006 11:21:08 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5A037FB284; Tue, 3 Jan 2006 11:22:21 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B12F8FB27C; Tue, 3 Jan 2006 11:22:19 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9A482FB27D; Tue, 3 Jan 2006 11:22:17 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8DC45FB277 for ; Tue, 3 Jan 2006 11:22:16 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03GMBx6025903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:22:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03GMBi2018073; Tue, 3 Jan 2006 18:22:11 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.42163.128375.486229@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:22:11 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A933AB.8060704@piuha.net> References: <43A933AB.8060704@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: MOBIKE Mailing List Subject: [Mobike] D104 design draft issue: definition of load balancing X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > Note that MOBIKE does not aim to support load balancing between > > multiple IP addresses. That is, each peer uses only one of the > > available IP addresses at a given point in time. > > > This may not be exact enough. I suppose we mean "... only one > of the available address pairs at a given point in time". Changed. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 11:32:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etp5O-0000Ml-PD for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 11:32:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18961 for ; Tue, 3 Jan 2006 11:31:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 99915FB294; Tue, 3 Jan 2006 11:32:32 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4A213FB283; Tue, 3 Jan 2006 11:32:29 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B23EFFB284; Tue, 3 Jan 2006 11:32:27 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2BF2AFB27D for ; Tue, 3 Jan 2006 11:32:26 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03GWJ5p025915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:32:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03GWJVv025999; Tue, 3 Jan 2006 18:32:19 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.42771.665907.250601@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:32:19 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A933C2.1000305@piuha.net> References: <43A933C2.1000305@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: MOBIKE Mailing List Subject: [Mobike] D105 design draft issue: figure 3 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > +-------------+ +---------+ > > |User-space | | MOBIKE | > > |Protocols | +-->>| Daemon | > > |relevant for | | | | > > |MOBIKE | | +---------+ > > +-------------+ | ^ > > User Space ^ | ^ > > ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ > > Kernel Space v | v > > _______ | v > > +-------------+ / \ | +--------------+ > > |Routing | / Trigger \ | | IPsec | > > |Protocols |<<-->>| Database |<<-+ +>+ Engine | > > | | \ / | | (+Databases) | > > +-----+---+---+ \_______/ | +------+-------+ > > ^ ^ ^ | ^ > > | +---------------+-------------+--------+-----+ > > | v | | | > > | +-------------+ | | | > > I | |Kernel-space | | | | I > > n | +-------->+Protocols +<----+-----+ | | n > > t v v |relevant for | | v v v t > > e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e > > r | Input | +-------------+ | | Outgoing | r > > f | Packet +<--------------------------+ | Interface | f > > ==a>|Processing|===============================| Processing |=a> > > c | | | | c > > e +----------+ +------------+ e > > s s > > ===> = IP packets arriving/leaving a MOBIKE node > > <-> = control and configuration operations > > > > Figure 3: Framework > > > I am confused by the role of the "Kernel-space protocols > relevant for MOBIKE" box in this figure. There are parts > of a node implementation that have to deal with IPsec > processing; is this what you mean? And there are parts > of a node implementation that may provide information > to, e.g., MOBIKE and MOBILE IP -- such as IPv6 NUD or > DNA. Is this what you mean? I think both, i.e. both the IPsec processing things, i.e. for example detecting IPsec packets coming from wrong address, etc, and also other protocols like you list there. There is quite limited space for drawing pictures in ascii, so it is better to cluster things a bit more and describe the actual modules needed, and not try to duplicate each box from the Pasi's slide. > I think the latter is an important > part that should be shown, but such components would appear > to provide input to the MOBIKE daemon directly or via > a "trigger database" rather than effect input and output > processing directly. The kernel-space protocols has arrows to trigger database, and to the input / output processing. > What are "User-space Protocols Relevant for MOBIKE"? > I can't think of any... DHCP, perhaps PPP etc. > Also, I'd rather not see "routing protocols" in this > figure, as it will confuse people. Routing do affect the selection of the addresses and interfaces, so I think it needs to be shown here. > And while a trigger database is a good idea, I'd rather not > introduce it here. It would be better to have a simplified ascii > version of the slide from IETF-62: I think having trigger database there actually do simplify the picture quite a lot, and that's why I think it is good idea to keep it there. > http://www3.ietf.org/proceedings/05mar/slides/mobike-1/sld6.htm Simplifying that picture does not really help, as the main idea for that picture was to so complicated enough picture having all kind of boxes and arrows, so that everybody would understand that this MOBIKE is only very small part of the whole solution. Simplification of a very complicated picture which is complicated on purpose (actually complicated to make sure it obfuscates things) doesn't really help... :-) -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 11:38:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpB5-0001rb-62 for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 11:38:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19924 for ; Tue, 3 Jan 2006 11:37:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1CF4AFB28B; Tue, 3 Jan 2006 11:38:23 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3ADDBFB277; Tue, 3 Jan 2006 11:38:17 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1AD53FB27D; Tue, 3 Jan 2006 11:38:16 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D6BE8FB249 for ; Tue, 3 Jan 2006 11:38:14 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03Gc2Wm027456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:38:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03Gc2CE028006; Tue, 3 Jan 2006 18:38:02 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.43114.668805.682871@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:38:02 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A933CC.30605@piuha.net> References: <43A933CC.30605@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: MOBIKE Mailing List Subject: [Mobike] D106 design draft issue: nat-p X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > This gives extra > > protection against 3rd party bombing attacks (the attacker cannot > > divert the traffic to some 3rd party). > > > This seems inaccurate, or at least too strong. We have > other mechanisms to prevent that, and the NAT-T based > attack only works for on-path attackers. Just say > "This avoids any possibility of on-path attackers modifying > addresses in headers" and refer to Francis's pseudonat > attack draft. Why do you think that NAT-preventation does not protect against 3rd party bombing attacks? If we do put all IP addresses used inside the packets, and cryptographically integrity protect them, and we enable NAT preventation, which means we do not allow NATs, how can attacker divert the traffic to some 3rd party? -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 11:47:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpJm-0004N2-V2 for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 11:47:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21692 for ; Tue, 3 Jan 2006 11:46:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3DDCEFB28E; Tue, 3 Jan 2006 11:47:25 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D8323FB282; Tue, 3 Jan 2006 11:47:23 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A363DFB284; Tue, 3 Jan 2006 11:47:22 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 0877CFB27D for ; Tue, 3 Jan 2006 11:47:18 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03GlGbu005984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:47:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03GlGQX027827; Tue, 3 Jan 2006 18:47:16 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.43667.989186.249127@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:47:15 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A9341B.9050808@piuha.net> References: <43A9341B.9050808@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: MOBIKE Mailing List Subject: [Mobike] D107 design draft issue: section 5.5 nits X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > If the addresses are part of the certificate then it is > > not necessary to execute the weaker return routability check. The > > return routability check is a form of authorization check, although > > it provides weaker guarantees than the inclusion of the IP address as > > a part of a certificate. If multiple addresses are communicated to > > the remote peer then some of these addresses may be already verified > > even if the primary address is still operational. > > s/the weaker/the/ (the strength is explained in next sentence) Done. > Also, it seems like there is some text missing here that we > had in the protocol draft about the need to have some authority > involved in the certs... surely the pure inclusion of data in > a self-signed certificate, for instance, does not make the > data reliable. I think adding that text to the protocol draft was completely unnessarely in the first place, as of course certificates needs to be validated before you use them. > I do not understand the last sentence. I guess you are trying > to say that verification can take place in parallel with ongoing > use of another, current address pair? No, it means that if we have already done return routability check or if the IP-address was listed in the certificate, then we might already have verified some of those addresses resently. I.e. for example if we move between two address pairs, we do not necessarely need to do return routability checks for them for every time. I agree that the "even if the current address is still operational." is quite confusing there, so I removed it. > > Another option is to use the [I-D.dupont-mipv6-3bombing] approach > > which suggests to perform a return routability check only when an > > address update needs to be sent from some address other than the > > indicated preferred address. > > I would delete this paragraph. There are a zillion variations > of the return routability procedure, and there is no need > to point to one of the variants here, particularly if that variant > has not been in use in other contexts. True. Deleted (and the reference, as it was last one). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 12:01:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpXh-0006uV-Mb for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 12:01:49 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23466 for ; Tue, 3 Jan 2006 12:00:34 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 701E0FB292; Tue, 3 Jan 2006 12:01:46 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D9E56FB27D; Tue, 3 Jan 2006 12:01:39 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EE699FB282; Tue, 3 Jan 2006 12:01:37 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 715A3FB277 for ; Tue, 3 Jan 2006 12:01:36 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03H1Uru017511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 19:01:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03H1UiY029229; Tue, 3 Jan 2006 19:01:30 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.44522.460691.692268@fireball.acr.fi> Date: Tue, 3 Jan 2006 19:01:30 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A9342B.6050207@piuha.net> References: <43A9342B.6050207@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: MOBIKE Mailing List Subject: [Mobike] D108 design draft issue: ikev2 payloads X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > Some implementations might have problems parsing more > > than certain number of IKEv2 payloads, but if the sender sends them > > in the most preferred first, the receiver can only use the first > > addresses, it was willing to parse. > > > Hmm... the IKEv2 spec seems to say that you MUST > be able to reject Critical=1 payloads that you don't > recognize. This seems to imply that you must go through > all the payloads, or am I missing something? You need to go through all payloads to check the critical bit and that the payload chaining is correct. On the other hand you do not need to parse 256 status notifications or 100 certificates the other end decided to send to you. You only need to parse first certificate payload, as it is end entity certificate, and you can ignore the rest, and fetch the certificates from some other source if you want. I do know there was some IKEv1 implementations that refused to parse some of our packets as they did have fixed limit of number of certificate payloads they accepted, or they had fixed limit of number of SA proposal you could have etc. I wouldn't be suprised that there would be implementation out that has fixed number of status notifications it will parse or decode. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 12:13:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etpib-00018R-7w for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 12:13:05 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24736 for ; Tue, 3 Jan 2006 12:11:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3E0B0FB28E; Tue, 3 Jan 2006 12:13:02 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E34E2FB27D; Tue, 3 Jan 2006 12:13:00 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 93F90FB284; Tue, 3 Jan 2006 12:12:58 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 4FF35FB277 for ; Tue, 3 Jan 2006 12:12:54 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03HCnfL005155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 19:12:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03HCnfB023397; Tue, 3 Jan 2006 19:12:49 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.45201.524607.918065@fireball.acr.fi> Date: Tue, 3 Jan 2006 19:12:49 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A93455.7020507@piuha.net> References: <43A93455.7020507@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 6 min Cc: MOBIKE Mailing List Subject: [Mobike] D109 design draft issue: security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] > > 7. Security Considerations > > This section seems weak compared to the one in > the protocol draft. Consider simply referring to the > protocol spec unless there is some new information > (e.g. design decisions not covered in the protocol > spec). As we do not really define protocol here, there is not that much of real security considerations. The current security considerations lists the generic problems against all protocols of this type. I am not sure adding pointer to the protocol document helps that much, as I assume people will read the protocol document anyways, but perhaps adding text "See Security considerations section of for more information about security considerations of the actual protocol." helps. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 12:33:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etq24-0005mc-JL for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 12:33:13 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27722 for ; Tue, 3 Jan 2006 12:31:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8EF52FB27D; Tue, 3 Jan 2006 12:33:06 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2679EFB27D; Tue, 3 Jan 2006 12:33:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5BAEFFB282; Tue, 3 Jan 2006 12:33:02 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8FF3DFB27C for ; Tue, 3 Jan 2006 12:33:00 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03HWtNx015600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 19:32:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03HWrPc021261; Tue, 3 Jan 2006 19:32:53 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.46405.952440.581359@fireball.acr.fi> Date: Tue, 3 Jan 2006 19:32:53 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200512211437.jBLEblls099898@givry.rennes.enst-bretagne.fr> References: <4399660A.5040106@piuha.net> <200512211437.jBLEblls099898@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 17 min Cc: MOBIKE Mailing List , Jari Arkko , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Francis Dupont writes: > there is nothing about the fact the design and the protocol are about > a first version of the MOBIKE tools. I support anyone who'd like to > make it an issue as the current solution addresses only one part of > the charter scenarios. Jari has already several times asked me to remove all references to the charter, thus I am not going to add anything new about the charter or future work... > > 1. Introduction > > ... > > single pair in the outer IP headers. Existing documents make no > > provision to change this pair after an IKE SA is created. > > this is not true: RFC 3775 and 3776 K bit stuff does exactly this. We are now talking about the IPsec. As far as I know those RFCs only cover MOBILE IP case, thus they are not generic IPsec solutions. I might be wrong, as I have not followed what was done there. > > 3.2. Multihoming Scenario > > > > ... > > Note that MOBIKE does not aim to support load balancing between > > multiple IP addresses. That is, each peer uses only one of the > > available IP addresses at a given point in time. > > This is not the common definition of load balancing (where the > restriction to only one address is per communication). I think we have discussed this enough earlier. If you have exact text changes I can check them out, but I am not going to start discussion about what is load balancing and what is not again. > > 5.3. Scope of SA Changes > ranges of SPI values don't make sense: please use a reasonnable > argument or no argument at all! Would you be happier if that would be list of ranges of SPI values? Actually ranges makes perfectly sense there, as the end allocating them can allocate them so that he can effectively move the SPIs he wants to move by just having one range (or few ranges). > > automatically move all IPsec SAs when the IKE SA moves, then we only > > need to keep track of which IKE SA was used to create the IPsec SA, > > and fetch the IP addresses from the IKE SA, i.e. there is no need to > > store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec- > > I don't believe there is an implementation which doesn't store IP > addresses per IPsec SA. Might be true now, but might be more common in the future, as they might want to store the IP address to the shared state, so they can update is very quickly for thousands of SAs (and save memory etc). > > On the other hand, even if we tie the IKE SA update to the IPsec SA > > update, then we can create separate IKE SAs for this scenario, e.g., > > we create one IKE SA which has both links as endpoints, and it is > > used for important traffic, and then we create another IKE SA which > > has only the fast and/or cheap connection, which is then used for > > that kind of bulk traffic. > > We can drop the whole MOBIKE stuff using the same argument. I think there is few orders of magnitude difference there. I would guess there would be at most 2-3 different types of IPsec SAs which would be moved separately. On the other hand there can be hundreds or thousands of movements in quite short time in certain time period. Thus we do need MOBIKE, but we might still be able to use only few IKE SAs for different types of traffic. Anyways this issue is already decided in the protocol draft (issue 8), thus discussion of the issue itself is pointless. If you have exact text changes to the document, then send them, but discussion about the issue 8 should not be restarted. > The working group decided to move all IPsec SAs implicitly when the > IKE SA address pair changes. If more granular handling of the IPsec > SA is required, then multiple IKE SAs can be created one for each set > of IPsec SAs needed. > > Please keep this and not try to give poor arguments to defend > the decision (it is the WG decision ".") If you have good arguments in either direction which is not mentioned in the draft, send text. Working group did decided to select the issue 8 with all IPsec SAs move when IKE SA move, so the arguments were enough for the working group. I think the main reason was that it is simplier, and the feature is not needed that much. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 12:46:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqF8-0008Kx-Dv for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 12:46:42 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01354 for ; Tue, 3 Jan 2006 12:45:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BA0BCFB28B; Tue, 3 Jan 2006 12:46:40 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 82ACAFB282; Tue, 3 Jan 2006 12:46:39 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E9C76FB283; Tue, 3 Jan 2006 12:46:37 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 83726FB24A for ; Tue, 3 Jan 2006 12:46:36 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03HkNXW002234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 19:46:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03HkMAv029814; Tue, 3 Jan 2006 19:46:22 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.47214.518582.189717@fireball.acr.fi> Date: Tue, 3 Jan 2006 19:46:22 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200512211651.jBLGpY3b000570@givry.rennes.enst-bretagne.fr> References: <4399660A.5040106@piuha.net> <200512211651.jBLGpY3b000570@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: MOBIKE Mailing List , Jari Arkko , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Francis Dupont writes: > > 6.4. Updating address list > > > s/list/set/ (this is important because lists should be ordered but > not sets). Here we have sets with a particular element. Done. > > MOBIKE could send the full peer address list every time any of the IP > > s/full/whole/ ? Done. > > 7. Security Considerations > > > > As all the messages are already authenticated by IKEv2 there is no > > risk that any attackers would modify the contents of the packets. > > as messages and packets are not the same this is not correct > (as the following show), so s/packets/messages/ Done. > > The IP addresses in the IP header of the packets are not > > authenticated, thus the protocol defined must take care that they are > > only used as an indication that something might be different, and > > that do not cause any direct actions, except when doing NAT > > Traversal. > > I strongly disagree: not authenticate the IP addresses just leaves > the protocol vulnerable to attacks modifying them, i.e., you can > establish the IKE SA and IPsec SAs with a bad address (cf what I call The IP addresses in the IP header are not authenticated. That is state of fact. Only solution to fix that would be running MOBIKE over AH, which would authenticate the IP address in the *IP header*. So this text here tells that if protocol uses those address from the *IP header* it needs to take care. > - reflect the IP address in messages in order to detect changes. > This is the option used by Mobike which requires either NAT dectection > or NAT prevention This option does not make IP addresses in the *IP header* authenticated. It will make separate copy of the IP addresses in the payload, which will be then authenticated, and those can be used in places where the unauthenticatede IP addresses from the *IP header* cannot be used. > So please update the design security considerations! If you have exact text changes, please send them. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 12:57:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqPu-000225-0r for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 12:57:50 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03028 for ; Tue, 3 Jan 2006 12:56:34 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 721B8FB28B; Tue, 3 Jan 2006 12:57:46 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1F414FB27C; Tue, 3 Jan 2006 12:57:44 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 65C87FB282; Tue, 3 Jan 2006 12:57:42 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id EC123FB24F for ; Tue, 3 Jan 2006 12:57:40 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03HvKCn000635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 19:57:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03HvKMa018500; Tue, 3 Jan 2006 19:57:20 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.47872.365772.320789@fireball.acr.fi> Date: Tue, 3 Jan 2006 19:57:20 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43A93446.4080907@piuha.net> References: <43A93446.4080907@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: MOBIKE Mailing List Subject: [Mobike] D112 design draft issue: references X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: > > > 10.1. Normative references > > > > [I-D.ietf-ipsec-ikev2] > > Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", > > draft-ietf-ipsec-ikev2-17 (work in progress), > > October 2004. > > > > [I-D.ietf-ipsec-rfc2401bis] > > Kent, S. and K. Seo, "Security Architecture for the > > Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work > > in progress), April 2005. > > It might be that the MOBIKE protocol spec is a useful > reference to the reader as well... I do not think you must read the protocol draft to understand this document, thats why it is informative reference. On the other hand you do need to know something about IKEv2 or RFC4301 architecture before reading this. > > [I-D.arkko-multi6dt-failure-detection] > > Arkko, J., "Failure Detection and Locator Selection in > > Multi6", draft-arkko-multi6dt-failure-detection-00 (work > > in progress), October 2004. > > Refer to draft-ietf-shim6-failure-detection-03 instead (to > appear today). Updated. > > [I-D.ietf-mip6-ro-sec] > > Nikander, P., "Mobile IP version 6 Route Optimization > > Security Design Background", draft-ietf-mip6-ro-sec-03 > > (work in progress), May 2005. > > This is now RFC 4225. Updated. Changed also IKEv2 to RFC4306 and RFC2401bis to RFC4301. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 13:08:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqaM-00044u-RJ for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 13:08:39 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04805 for ; Tue, 3 Jan 2006 13:07:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D7B5BFB28B; Tue, 3 Jan 2006 13:08:33 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1B218FB27D; Tue, 3 Jan 2006 13:08:32 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DD04CFB282; Tue, 3 Jan 2006 13:08:30 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 607EDFB27C for ; Tue, 3 Jan 2006 13:08:29 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03I8NXL021396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 20:08:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03I8MAx029240; Tue, 3 Jan 2006 20:08:22 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.48534.341076.638470@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:08:22 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: mobike@machshav.com Subject: [Mobike] D113 Design draft, overall comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Pasi.Eronen@nokia.com writes: > - My first impression is that the document probably isn't very easy > to read for someone who hasn't followed the design discussions. > But I don't know what exactly should be done to help this, > and perhaps it's not even that important. I did receive comments from here in the office, that reading this document at the same time as reading protocol document, made the protocol document much clearer. Didn't really ask if the other way was true also, but I would guess it is same in both directions. This is more abstract and gives background, and the protocol document gives information how the protocol looks like. > - The document should probably more explicitly say that the scope > is the design of draft-ietf-mobike-protocol, not any other work > items that MOBIKE WG may decide to work on. I think Jari already removed most of the references to the other works... :-) > - There's some overlap in the general background/motivation text > and scenarios (sections 1 and 3) with draft-ietf-mobike-protocol. > Perhaps it would be easier to say that this document is meant > to be read with draft-ietf-mobike-protocol, not alone. I think you can read either one of mobike documents alone, but it is easier to read if you read both of them at the same time, regardless whether you are interested in the bits on the wire (protocol document) or the design and background (this document). > - I'd suggest placing all instances of MAY/SHOULD/MUST etc. in > quotes (or changing them to lowercase) to show that we're just > describing that e.g. we decided to add this requirement in the > protocol, but this document itself is not imposing any > requirements for anyone. All cases where there is MAY/SHOULD/MUST here it is actually refering to the IKEv2 or protocol document text. I.e. when we decided to change SHOULD of the IKEv2 document to MUST NOT in the protocol document we do mention MUST NOT here (this is actually mentioned 3 times in different places). Only SHOULD is where it tells that IKEv2 says SHOULD in that place... The only MAY is where it tells what WG decided on issue 6... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 13:20:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etqln-0006hU-G9 for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 13:20:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06197 for ; Tue, 3 Jan 2006 13:19:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EFC00FB284; Tue, 3 Jan 2006 13:20:25 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E14E7FB27D; Tue, 3 Jan 2006 13:20:24 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D77F6FB282; Tue, 3 Jan 2006 13:20:20 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 66FDAFB27C for ; Tue, 3 Jan 2006 13:20:19 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03IKDla015996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 20:20:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03IKCd4011049; Tue, 3 Jan 2006 20:20:12 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.49244.630781.817841@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:20:12 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 7 min Cc: mobike@machshav.com Subject: [Mobike] D114 Design draft, terminology X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Pasi.Eronen@nokia.com writes: > - Overall: My impression is that most of this section is baggage we > accumulated from other documents, but don't actually need > anymore. Some of the terms are never used outside the terminology > section, and some others are used only once or twice. We did has this discussion in the IETF last time, and I think most of the people there did want to keep the terms. > - "Available address": Neither IKEv2, 2401bis nor > draft-ietf-mobike-protocol prohibits using IPsec for > link-local addresses (although it's probably not very useful > in most cases), so this definition is not totally accurate. > > - "Available address": RFC2462 defines "tentative address" > as "an address whose uniqueness on a link is being verified, > prior to its assignment to an interface." Thus, it seems > mentioning tentative addresses in this context is redundant. I myself think we should keep the Available address. > - "Locally operational address" is not used anywhere > else except the terminology section. True that we could combine it to the peer address set, but I think it is easier to keep this and define peer address set based on it. > - "Full Cone", "Restricted Cone", and "Port Restricted Cone" are > not used anywhere in the document. True, we could remove those. Remove (and the reference to 3489 too). > - "Preferred Address": This term is quite unclear (as I've pointed > out earlier). Does this mean the "current address" ("what was > in the newest UPDATE_SA_ADDRESSES message" -- but then calling > it "preferred" is misleading), or something different? It does not match anything that is used by the protocol document, as we decided to select initiator decides option. It really has different meaning from the current address in cases where we can have asymmetry, and as we do describe why we ended up having initiator decides, we need to also describe cases where we have asymmetry. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 13:32:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etqx8-0000fF-Mf for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 13:32:10 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07996 for ; Tue, 3 Jan 2006 13:30:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ADB38FB284; Tue, 3 Jan 2006 13:32:08 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2F45FB27D; Tue, 3 Jan 2006 13:32:06 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 41498FB282; Tue, 3 Jan 2006 13:32:05 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D8D02FB27C for ; Tue, 3 Jan 2006 13:32:00 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03IVqGL011048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 20:31:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03IVpQ3027682; Tue, 3 Jan 2006 20:31:51 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.49943.767018.951734@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:31:51 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: mobike@machshav.com Subject: [Mobike] D115 Design draft, return routability X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Pasi.Eronen@nokia.com writes: > - "Finally it would be possible not to execute return routability > checks at all. In case of indirect change notifications we only > move to the new preferred address after successful dead-peer > detection (i.e., a response to a DPD test) on the new address, > which is already a return routability check." > > Confusing text; we don't execute return routability checks at > all, but we do it already. And what exactly are the indirect > change notifications we're talking about here? ICMP messages, or path failing, i.e. anything we do not get directly from the other end. I.e. if we notice that path has failed, and we do DPD to verify it and then change to new address, that changing to new address can actually already act as return routability check in certain cases. Added text "(i.e. something we notice from the network, not from the peer directly)" and "(i.e. notification from the other end directly)" after indirect notifications and direct notifications. We used to have much more text describing those, but that was removed few versions back. > - "but potential attacks are possible if a return > routability check does not include some kind of a nonce." > > A return routability check verifies that the peer can receive > messages sent to this address. If the message doesn't do this, > then IMHO it's not a return routability check at all. So I'd > rewrite this section to say something like "A successful IKEv2 > informational exchange itself does not perform a return > routability check because ... and thus a nonce is needed ...". There are multiple different levels of return routability check. For example if you do not care about authenticated attacker faking packets (I do not), then normal IKEv2 informational exchange is return routability check. Your definition of he return routability check is not only one, and this section tries to explain different return routability checks. > - The text about different levels of return routability checks is > very confusing. A return routability check should verify the IKEv2 > peer can receive packets sent to the given address; a check that > just verifies that "someone can receive packets at the given > address" is something quite different! I'd suggest removing most > of this text. I disagree. It might be clear for you what you mean by return routability check, but I have noticed that people do have very different views what it is. Thus we need to explain what do we mean it with in this context. I would say that outside the security area most common format of return routability check would be "someone can receive packets at the given address". > - Section 5.5.1: Again, confusing text: if some other protocol wants > to know "can remote entity A receive packets sent to X?", MOBIKE > might be able to provide information that "remote entity B can > receive packets sent to X" -- but this is not very useful unless we > can also know that A and B are the same entity (with some reasonable > definition of "sameness"). I'd suggest shortening this text and > stating that this was deemed complex, not absolutely needed, and > thus beyond the scope. I again think we do need this, just to explain people that this is complex issue and we do point out few most common cases there. Saying "this is complex, we do not tell you anything about it" does not really help. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 13:45:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etr9t-0003Z4-U5 for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 13:45:22 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10245 for ; Tue, 3 Jan 2006 13:44:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ABB8FFB284; Tue, 3 Jan 2006 13:45:19 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 54C50FB27D; Tue, 3 Jan 2006 13:45:14 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 87464FB282; Tue, 3 Jan 2006 13:45:13 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 597C2FB27C for ; Tue, 3 Jan 2006 13:45:08 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03IipOc014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 20:44:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03IioPC022629; Tue, 3 Jan 2006 20:44:50 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.50722.611977.764644@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:44:50 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: mobike@machshav.com Subject: [Mobike] D116 Design draft, misc. comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Pasi.Eronen@nokia.com writes: > - Section 1, "for example when using SecurID cards" -> "for example, > when using human-operated token cards" Done. > - Section 3.2: "Each peer selects one of its IP addresses as the > preferred address which is used for subsequent communication." > There's some conflict here. It's the initiator who selects > which addresses are used for subsequent communication (except > in relatively rare situations, ie. responder address changes). In mobike-protocol it is initiator. Here we also describe other options. No conflict, we simply do not fully support that scenario in current protocol (i.e. responder preference is ignored). > - Section 4: "The MOBIKE protocol should be able to perform...": > this text may need to be rewritten once we either come up > with a reasonable definition for "preferred address", or > get rid of the term completely. Again disagree. This is not describing only the current protocol, but also design choises behind the current protocol. That means we need to describe things in more general ways than what current protocol document requires. > - Section 4: The talk about "MOBIKE daemon" creates the impression > that there typically would be both an "IKEv2 daemon" and > "MOBIKE daemon", running as separate processes. While this is > not impossible, I would find it a very strange way to implement > a relatively minor extension to IKEv2. (After all, if we implement > some other IKEv2 extension like draft-nir-ikev2-auth-lt, > we don't call it the "Repeated Authentication Daemon" or something.) True. Perhaps MOBIKE module would be better term. Changed to MOBIKE module. > - Section 5.1.4, 1st paragraph: closing parenthesis missing. Fixed. > - Section 5.2.1, a couple of informative references might be > in order (UNSAF, MIDCOM, NSIS NATFW) Sure, give RFC / Internet-draft names, I will add them. > - Section 6.3: "The selected format needs to be flexible enough to > include additional information in future versions of the protocol > (e.g. to enable load balancing). This may be realized with an > reserved field, which can later be used to store additional > information. As there may arise other information which may have to > be tied to an address in the future, a reserved field seems like a > prudent design in any case." > > IMHO it would be quite difficult to design the protocol in a way > that would totally prevent future extensions from sending > additional information. But currently we don't have any "reserved" > fields there (simply because they're not needed -- the normal > IKEv2 extension mechanisms will allow us to add more stuff later). Actually we do. We have notification data, that is either empty of fixed length, which means we can add stuff to it. > - References: should draft-ietf-mobike-protocol be normative? I do not think so. It is not mandatory to read current protocol to understand why we ended up there, and what other options were considered and rejected. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 13:52:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrGZ-0004dz-Mn for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 13:52:16 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11233 for ; Tue, 3 Jan 2006 13:50:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DF3AEFB290; Tue, 3 Jan 2006 13:52:11 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6E3C1FB27D; Tue, 3 Jan 2006 13:52:09 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 98C8BFB282; Tue, 3 Jan 2006 13:52:07 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2A9ECFB27C for ; Tue, 3 Jan 2006 13:52:06 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03Ipt6n010339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 20:51:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03IpscV011378; Tue, 3 Jan 2006 20:51:54 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.51146.115714.63930@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:51:54 +0200 From: Tero Kivinen To: mobike@machshav.com In-Reply-To: <43B2933C.2090102@piuha.net> References: <002d01c60bb1$02f18f20$a42e1dc2@ad.checkpoint.com> <43B2933C.2090102@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: Yoav Nir , Jari Arkko , pasi.eronen@nokia.com, Yaron Sheffer Subject: Re: [Mobike] D117 WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] Jari Arkko writes: >We have looked at the two drafts, and everything looks OK except that the >protocol assumes that the IPsec stack on the client knows when the >(externally visible) IP address has changed. It does assume that you notice your local IP address changing, i.e. not the address of the NAT box that is between you and the other end. If the client does not notice IP address changing, then the other end will assume there is NAT box between, and depending whether NAT preventation or NAT transition is enabled, the connection is either disconnected, or NAT-T is enabled. > This is obviously not the case >when the client is behind an edge router which has just restarted. When this >happens, NAT mappings are created arbitrarily, and the IPsec gateway will >receive ESP/UDP and IKE packets from a "new" source. This is covered by NAT-T part of the MOBIKE protocol (unless you have configured NAT prevention on, in which case no NATs are allowed). >Please let me know if it's just something I am missing, or if indeed the >current protocol does not address this scenario. The scenario is supported. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 03 13:58:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrMC-0005y2-L6 for mobike-archive@megatron.ietf.org; Tue, 03 Jan 2006 13:58:04 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12120 for ; Tue, 3 Jan 2006 13:56:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D5000FB290; Tue, 3 Jan 2006 13:58:01 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 576EEFB283; Tue, 3 Jan 2006 13:58:00 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 03D42FB284; Tue, 3 Jan 2006 13:57:59 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id CF35BFB282 for ; Tue, 3 Jan 2006 13:57:57 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03IvsSo004208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jan 2006 20:57:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03IvrYe004343; Tue, 3 Jan 2006 20:57:53 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17338.51505.811261.2028@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:57:53 +0200 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Subject: [Mobike] mobike-design document X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] I have now finished processing the comments received during the WGLC. I will hope people who commented would have time to check if the changes I made addressed their issues, and send me a note so I could close those issues. The working copy of the draft can be found from the link above. I will be out of office for two weeks starting on Saturday, so I would really like to get comments back before that if possible. I will issue new version of the document before I leave, so in case people are happy with the changes we can go forward while I am away. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jan 04 06:35:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6vD-0005v3-B0 for mobike-archive@megatron.ietf.org; Wed, 04 Jan 2006 06:35:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16374 for ; Wed, 4 Jan 2006 06:33:59 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EE72DFB282; Wed, 4 Jan 2006 06:35:10 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC3C2FB277; Wed, 4 Jan 2006 06:35:08 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 55BC6FB27D; Wed, 4 Jan 2006 06:35:07 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 7362EFB262 for ; Wed, 4 Jan 2006 06:35:05 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k04BYmA05232; Wed, 4 Jan 2006 12:34:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k04BYklk074322; Wed, 4 Jan 2006 12:34:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601041134.k04BYklk074322@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Tue, 03 Jan 2006 19:32:53 +0200. <17338.46405.952440.581359@fireball.acr.fi> Date: Wed, 04 Jan 2006 12:34:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Jari Arkko , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: Francis Dupont writes: > there is nothing about the fact the design and the protocol are about > a first version of the MOBIKE tools. I support anyone who'd like to > make it an issue as the current solution addresses only one part of > the charter scenarios. Jari has already several times asked me to remove all references to the charter, thus I am not going to add anything new about the charter or future work... => to refer to the charter is only one way to solve the issue. > > 1. Introduction > > ... > > single pair in the outer IP headers. Existing documents make no > > provision to change this pair after an IKE SA is created. > > this is not true: RFC 3775 and 3776 K bit stuff does exactly this. We are now talking about the IPsec. As far as I know those RFCs only cover MOBILE IP case, thus they are not generic IPsec solutions. I might be wrong, as I have not followed what was done there. => I agree, IMHO the word "internal" (to IPsec) or something equivalent is enough, for instance "Existing IPsec documents" works well. > > 3.2. Multihoming Scenario > > > > ... > > Note that MOBIKE does not aim to support load balancing between > > multiple IP addresses. That is, each peer uses only one of the > > available IP addresses at a given point in time. > > This is not the common definition of load balancing (where the > restriction to only one address is per communication). I think we have discussed this enough earlier. If you have exact text changes I can check them out, but I am not going to start discussion about what is load balancing and what is not again. => so the text should be more accurate about what it calls load balancing, i.e., why not add this definition in the terminology section? (the idea is the document may use what it likes as soon as it is either a common term or a defined-within term). > > 5.3. Scope of SA Changes > ranges of SPI values don't make sense: please use a reasonnable > argument or no argument at all! Would you be happier if that would be list of ranges of SPI values? => no, ranges don't make sense with pseudo-random values. Actually ranges makes perfectly sense there, as the end allocating them can allocate them so that he can effectively move the SPIs he wants to move by just having one range (or few ranges). => RFC 4302 says "arbitrary value". I am not convinced there is no attack against predictable SPIs. As far as I know all implementations use (pseudo) random SPIs... This is what I assume when I say ranges don't make sense there. > > On the other hand, even if we tie the IKE SA update to the IPsec SA > > update, then we can create separate IKE SAs for this scenario, e.g., > > we create one IKE SA which has both links as endpoints, and it is > > used for important traffic, and then we create another IKE SA which > > has only the fast and/or cheap connection, which is then used for > > that kind of bulk traffic. > > We can drop the whole MOBIKE stuff using the same argument. I think there is few orders of magnitude difference there. I would guess there would be at most 2-3 different types of IPsec SAs which would be moved separately. On the other hand there can be hundreds or thousands of movements in quite short time in certain time period. Thus we do need MOBIKE, but we might still be able to use only few IKE SAs for different types of traffic. Anyways this issue is already decided in the protocol draft (issue 8), thus discussion of the issue itself is pointless. => I am not against this "authority" argument, my concern is about a poor argumentation to defend the decision, i.e., I strongly suggest to remove the whole argumentation and just to say it is the WG decision. If you have exact text changes to the document, then send them, but discussion about the issue 8 should not be restarted. => I don't want to restart it this time, just to remove it (:-). > The working group decided to move all IPsec SAs implicitly when the > IKE SA address pair changes. If more granular handling of the IPsec > SA is required, then multiple IKE SAs can be created one for each set > of IPsec SAs needed. > > Please keep this and not try to give poor arguments to defend > the decision (it is the WG decision ".") If you have good arguments in either direction which is not mentioned in the draft, send text. Working group did decided to select the issue 8 with all IPsec SAs move when IKE SA move, so the arguments were enough for the working group. I think the main reason was that it is simplier, and the feature is not needed that much. => as your idea is to keep the cover on the pot you should follow my suggestion: just keep the presentation of the issue and the decision. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jan 04 06:43:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu73G-0007WF-1w for mobike-archive@megatron.ietf.org; Wed, 04 Jan 2006 06:43:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17132 for ; Wed, 4 Jan 2006 06:42:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AA2B7FB283; Wed, 4 Jan 2006 06:43:31 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0DA6BFB262; Wed, 4 Jan 2006 06:43:30 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 31722FB281; Wed, 4 Jan 2006 06:43:29 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D127DFB249 for ; Wed, 4 Jan 2006 06:43:27 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k04BhEA06033; Wed, 4 Jan 2006 12:43:14 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k04BhEsL074364; Wed, 4 Jan 2006 12:43:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601041143.k04BhEsL074364@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Tue, 03 Jan 2006 19:46:22 +0200. <17338.47214.518582.189717@fireball.acr.fi> Date: Wed, 04 Jan 2006 12:43:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Jari Arkko , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > I strongly disagree: not authenticate the IP addresses just leaves > the protocol vulnerable to attacks modifying them, i.e., you can > establish the IKE SA and IPsec SAs with a bad address (cf what I call The IP addresses in the IP header are not authenticated. That is state of fact. => yes but the protocol document addresses this issue so I simply suggest to put the same text into the design document. Only solution to fix that would be running MOBIKE over AH, which would authenticate the IP address in the *IP header*. So this text here tells that if protocol uses those address from the *IP header* it needs to take care. => I agree but to explain how is not bad, is it? > - reflect the IP address in messages in order to detect changes. > This is the option used by Mobike which requires either NAT dectection > or NAT prevention This option does not make IP addresses in the *IP header* authenticated. It will make separate copy of the IP addresses in the payload, which will be then authenticated, and those can be used in places where the unauthenticatede IP addresses from the *IP header* cannot be used. => strictly you're right but this is not how it is implemented (as the options are not copies but hashes of the IP addresses the IP addresses from the IP header are used but only after being checked against the authenticated "copies"). > So please update the design security considerations! If you have exact text changes, please send them. => I keep this message and I'll try to propose something. Regards Francis.Dupont@point6.net _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jan 04 07:41:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu7xI-0003G8-Nf for mobike-archive@megatron.ietf.org; Wed, 04 Jan 2006 07:41:28 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23841 for ; Wed, 4 Jan 2006 07:40:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3F8A1FB285; Wed, 4 Jan 2006 07:41:25 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 24FF2FB281; Wed, 4 Jan 2006 07:41:22 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8137EFB282; Wed, 4 Jan 2006 07:41:19 -0500 (EST) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by machshav.com (Postfix) with ESMTP id A2A84FB277 for ; Wed, 4 Jan 2006 07:41:17 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k04CfAbD029365; Wed, 4 Jan 2006 13:41:10 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k04Cf9DL023541; Wed, 4 Jan 2006 13:41:10 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 13:41:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jan 2006 13:41:06 +0100 Message-ID: Thread-Topic: [Mobike] D116 Design draft, misc. comments Thread-Index: AcYQleAdP8o+EEDjTea1UC/uO0tyoQAjYN3w From: "Tschofenig, Hannes" To: "Tero Kivinen" , X-OriginalArrivalTime: 04 Jan 2006 12:41:06.0728 (UTC) FILETIME=[21A43280:01C6112C] Cc: mobike@machshav.com Subject: Re: [Mobike] D116 Design draft, misc. comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable hi tero, = please find a minor comment below: = > -----Urspr=FCngliche Nachricht----- > Von: mobike-bounces@machshav.com = > [mailto:mobike-bounces@machshav.com] Im Auftrag von Tero Kivinen > Gesendet: Dienstag, 3. Januar 2006 19:45 > An: Pasi.Eronen@nokia.com > Cc: mobike@machshav.com > Betreff: [Mobike] D116 Design draft, misc. comments > = > [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html > working copy of document: > http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] > = > Pasi.Eronen@nokia.com writes: > > - Section 1, "for example when using SecurID cards" -> "for = > example, = > > when using human-operated token cards" = > = > Done. > = > > - Section 3.2: "Each peer selects one of its IP addresses as the > > preferred address which is used for subsequent communication." > > There's some conflict here. It's the initiator who selects > > which addresses are used for subsequent communication (except > > in relatively rare situations, ie. responder address changes). > = > In mobike-protocol it is initiator. Here we also describe other > options. No conflict, we simply do not fully support that scenario in > current protocol (i.e. responder preference is ignored). = > = > > - Section 4: "The MOBIKE protocol should be able to perform...": > > this text may need to be rewritten once we either come up = > > with a reasonable definition for "preferred address", or = > > get rid of the term completely. > = > Again disagree. This is not describing only the current protocol, but > also design choises behind the current protocol. That means we need to > describe things in more general ways than what current protocol > document requires. > = > > - Section 4: The talk about "MOBIKE daemon" creates the impression > > that there typically would be both an "IKEv2 daemon" and > > "MOBIKE daemon", running as separate processes. While this is = > > not impossible, I would find it a very strange way to implement > > a relatively minor extension to IKEv2. (After all, if we = > implement = > > some other IKEv2 extension like draft-nir-ikev2-auth-lt, > > we don't call it the "Repeated Authentication Daemon" or = > something.) > = > True. Perhaps MOBIKE module would be better term. Changed to MOBIKE > module. = > = > > - Section 5.1.4, 1st paragraph: closing parenthesis missing. > = > Fixed. = > = > > - Section 5.2.1, a couple of informative references might be = > > in order (UNSAF, MIDCOM, NSIS NATFW) > = > Sure, give RFC / Internet-draft names, I will add them. = here are the references: = [UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. for midcom we could reference: [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. and = [MIDCOM-MIB] Quittek, J., Stiemerling, M. and P. Srisuresh, "Definitions o= f Managed Objects for Middlebox Communication", draft-ietf-midcom-mib-05.tx= t (work in progress), March 2005. here is the nsis reference: = [NSISNATFW] Stiemerling, M., Tschofenig, H. and C. Aoun, "A NAT/Firewall = NSIS Signaling Layer Protocol (NSLP)", Internet-Draft draft-ietf-nsis-nslp-= natfw-08, October 2005. > = > > - Section 6.3: "The selected format needs to be flexible enough to > > include additional information in future versions of the protocol > > (e.g. to enable load balancing). This may be realized with an > > reserved field, which can later be used to store additional > > information. As there may arise other information which = > may have to > > be tied to an address in the future, a reserved field seems like a > > prudent design in any case." > > = > > IMHO it would be quite difficult to design the protocol in a way = > > that would totally prevent future extensions from sending > > additional information. But currently we don't have any = > "reserved" = > > fields there (simply because they're not needed -- the normal = > > IKEv2 extension mechanisms will allow us to add more stuff later). > = > Actually we do. We have notification data, that is either empty of > fixed length, which means we can add stuff to it. = > = > > - References: should draft-ietf-mobike-protocol be normative? > = > I do not think so. It is not mandatory to read current protocol to > understand why we ended up there, and what other options were > considered and rejected. = ciao hannes > -- = > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > = _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jan 04 08:13:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8Si-0002Yd-2b for mobike-archive@megatron.ietf.org; Wed, 04 Jan 2006 08:13:56 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28180 for ; Wed, 4 Jan 2006 08:12:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 91202FB284; Wed, 4 Jan 2006 08:13:53 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8B2C0FB281; Wed, 4 Jan 2006 08:13:52 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7BA39FB282; Wed, 4 Jan 2006 08:13:50 -0500 (EST) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by machshav.com (Postfix) with ESMTP id 78AA2FB277 for ; Wed, 4 Jan 2006 08:13:49 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k04DDloj025235; Wed, 4 Jan 2006 14:13:47 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k04DDkPk019469; Wed, 4 Jan 2006 14:13:46 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 14:13:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jan 2006 14:13:46 +0100 Message-ID: Thread-Topic: [Mobike] WGLC on the design draft Thread-Index: AcYGTu39f7aWuVSaS5aJoCvALmZppwK4COdA From: "Tschofenig, Hannes" To: "Francis Dupont" , "Jari Arkko" X-OriginalArrivalTime: 04 Jan 2006 13:13:46.0473 (UTC) FILETIME=[B1BD8D90:01C61130] Cc: MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit hi francis, thanks for the feedback. > 6.3. Message presentation > > ... > Load balancing is currently outside the scope of MOBIKE, however > > => as you shot in your feet with the non standard definition of load > balancing now you are in trouble because you still don't want the real > load balancing (multiple addresses in the same SA at the same time) > but want the thing in the middle (one address per SA but different > addresses in SAs and/or in time). > i am not sure what exactly you would like to have changed. could you please elaborate a bit? ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 06:13:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuT3W-0006le-Ds for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 06:13:18 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27467 for ; Thu, 5 Jan 2006 06:12:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B14A1FB290; Thu, 5 Jan 2006 06:13:10 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 031DCFB286; Thu, 5 Jan 2006 06:13:09 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0450BFB28B; Thu, 5 Jan 2006 06:13:08 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7B6FCFB285 for ; Thu, 5 Jan 2006 06:13:04 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k05BCxZ0015653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2006 13:12:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k05BCvYH020446; Thu, 5 Jan 2006 13:12:57 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17340.65337.331602.920131@fireball.acr.fi> Date: Thu, 5 Jan 2006 13:12:57 +0200 From: Tero Kivinen To: "Tschofenig, Hannes" In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] D116 Design draft, misc. comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tschofenig, Hannes writes: > > > - Section 5.2.1, a couple of informative references might be > > > in order (UNSAF, MIDCOM, NSIS NATFW) > > > > Sure, give RFC / Internet-draft names, I will add them. > > here are the references: > > [UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral > Self-Address Fixing (UNSAF) Across Network Address > Translation", RFC 3424, November 2002. > > > for midcom we could reference: > > [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. > Rayhan, "Middlebox communication architecture and > framework", RFC 3303, August 2002. Added those. > [MIDCOM-MIB] Quittek, J., Stiemerling, M. and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", draft-ietf-midcom-mib-05.txt (work in progress), March 2005. Is the mib here really relevant for the mobike design? I think the architecture and framework should be enough. I didn't add this one yet. > here is the nsis reference: > > [NSISNATFW] Stiemerling, M., Tschofenig, H. and C. Aoun, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-08, October 2005. Added that. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 07:09:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuTwI-0001qd-UT for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 07:09:55 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04595 for ; Thu, 5 Jan 2006 07:08:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B7D73FB290; Thu, 5 Jan 2006 07:09:52 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 11191FB286; Thu, 5 Jan 2006 07:09:51 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5AA32FB28B; Thu, 5 Jan 2006 07:09:49 -0500 (EST) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by machshav.com (Postfix) with ESMTP id 0FD3DFB285 for ; Thu, 5 Jan 2006 07:09:48 -0500 (EST) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k05C9eDq025283; Thu, 5 Jan 2006 13:09:40 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k05C9eEf010570; Thu, 5 Jan 2006 13:09:40 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 13:09:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jan 2006 13:05:53 +0100 Message-ID: Thread-Topic: [Mobike] D116 Design draft, misc. comments Thread-Index: AcYR6RDQxb6S4jXURH+CB2BlELnl1wABrDnQ From: "Tschofenig, Hannes" To: "Tero Kivinen" X-OriginalArrivalTime: 05 Jan 2006 12:09:39.0256 (UTC) FILETIME=[E7089380:01C611F0] Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] D116 Design draft, misc. comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable hi tero, = = > -----Urspr=FCngliche Nachricht----- > Von: Tero Kivinen [mailto:kivinen@iki.fi] = > Gesendet: Donnerstag, 5. Januar 2006 12:13 > An: Tschofenig, Hannes > Cc: Pasi.Eronen@nokia.com; mobike@machshav.com > Betreff: Re: [Mobike] D116 Design draft, misc. comments > = > Tschofenig, Hannes writes: > > > > - Section 5.2.1, a couple of informative references might be = > > > > in order (UNSAF, MIDCOM, NSIS NATFW) > > > = > > > Sure, give RFC / Internet-draft names, I will add them. = > > = > > here are the references: = > > = > > [UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral > > Self-Address Fixing (UNSAF) Across Network Address > > Translation", RFC 3424, November 2002. > > = > > = > > for midcom we could reference: > > = > > [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., = > Molitor, A. and A. > > Rayhan, "Middlebox communication architecture and > > framework", RFC 3303, August 2002. > = > Added those. = > = > > [MIDCOM-MIB] Quittek, J., Stiemerling, M. and P. = > Srisuresh, "Definitions of Managed Objects for Middlebox = > Communication", draft-ietf-midcom-mib-05.txt (work in = > progress), March 2005. > = > Is the mib here really relevant for the mobike design? I think the > architecture and framework should be enough. I didn't add this one > yet. = it is ok for me to reference just the framework. i guess that everyone then= already understands what is meant. = ciao hannes > = > > here is the nsis reference: = > > = > > [NSISNATFW] Stiemerling, M., Tschofenig, H. and C. Aoun, = > "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", = > Internet-Draft draft-ietf-nsis-nslp-natfw-08, October 2005. > = > Added that. = > -- = > kivinen@safenet-inc.com > = _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 07:33:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUJC-0001NX-9R for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 07:33:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07216 for ; Thu, 5 Jan 2006 07:32:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0B03EFB290; Thu, 5 Jan 2006 07:33:31 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 62813FB286; Thu, 5 Jan 2006 07:33:29 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6AC69FB28B; Thu, 5 Jan 2006 07:33:27 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id F1DEDFB280 for ; Thu, 5 Jan 2006 07:33:25 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k05CXLQp018865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2006 14:33:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k05CXKpL014297; Thu, 5 Jan 2006 14:33:20 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17341.4624.63925.406248@fireball.acr.fi> Date: Thu, 5 Jan 2006 14:33:20 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200601041134.k04BYklk074322@givry.rennes.enst-bretagne.fr> References: <17338.46405.952440.581359@fireball.acr.fi> <200601041134.k04BYklk074322@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 58 min Cc: Jari Arkko , MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont writes: > > We are now talking about the IPsec. As far as I know those RFCs only > > cover MOBILE IP case, thus they are not generic IPsec solutions. I > > might be wrong, as I have not followed what was done there. > > I agree, IMHO the word "internal" (to IPsec) or something equivalent > is enough, for instance "Existing IPsec documents" works well. Changed to that "Existing IPsec document ...". > so the text should be more accurate about what it calls load balancing, > i.e., why not add this definition in the terminology section? (the idea is > the document may use what it likes as soon as it is either a common > term or a defined-within term). Most comments have been that would need to remove extra terms from the terminology section, so I do not think we need to add one more, that is only in 1-2 places in the document. > no, ranges don't make sense with pseudo-random values. There are implementations who do allocate SPI values in groups, where ranges makes perfect sense for the implementation allocating the SPIs. For the other end ranges does not mean anything, but it does compress the list of SPIs much smaller if SPI values are allocated knowing the fact. > RFC 4302 says "arbitrary value". I am not convinced there is no > attack against predictable SPIs. As far as I know all > implementations use (pseudo) random SPIs... This is what I assume > when I say ranges don't make sense there. RFC4302 also says: However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. which means that allocating SPIs of the high bandwidth SAs from range 0xe0000000-0xefffffff, and SPIs of the low bandwidth high availibility SAs from range 0xd000000-0xdfffffff, would still be completely aligned with the RFC4302. The idea is that SPI is arbitrary number and only creator of the SPI can know why certain value was used. Also SPIs allocated from those 24 bit ranges are still not predictable. I still do not completely how you want to modify that text, i.e. what is more efficient format than list of ranges that you want to mention there? > I am not against this "authority" argument, my concern is about a > poor argumentation to defend the decision, i.e., I strongly suggest > to remove the whole argumentation and just to say it is the WG > decision. The text there is not there to "defend" the decision, it is there for background information, and to explain that we did consider these things, and that we made this decision. If you have better arguments for either side, feel free to submit them, I can add them there too. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 07:58:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUhX-0001YB-Le for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 07:58:43 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09758 for ; Thu, 5 Jan 2006 07:57:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 13FF0FB286; Thu, 5 Jan 2006 07:58:42 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57905FB24A; Thu, 5 Jan 2006 07:58:40 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5210EFB262; Thu, 5 Jan 2006 07:58:39 -0500 (EST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 160D8FB23E for ; Thu, 5 Jan 2006 07:58:38 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k05CwaCd005623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2006 14:58:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k05CwZNi001477; Thu, 5 Jan 2006 14:58:35 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17341.6139.490231.597809@fireball.acr.fi> Date: Thu, 5 Jan 2006 14:58:35 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200601041143.k04BhEsL074364@givry.rennes.enst-bretagne.fr> References: <17338.47214.518582.189717@fireball.acr.fi> <200601041143.k04BhEsL074364@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 9 min Cc: Jari Arkko , MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont writes: > In your previous mail you wrote: > > > I strongly disagree: not authenticate the IP addresses just leaves > > the protocol vulnerable to attacks modifying them, i.e., you can > > establish the IKE SA and IPsec SAs with a bad address (cf what I call > > The IP addresses in the IP header are not authenticated. That is state > of fact. > > => yes but the protocol document addresses this issue so I simply suggest > to put the same text into the design document. This document is not meant to be limited to the specific protocol, it tries to be more generic one. The protocol document provided solution to that and the text describing that solution belongs to that document. > => strictly you're right but this is not how it is implemented (as the > options are not copies but hashes of the IP addresses the IP addresses > from the IP header are used but only after being checked against the > authenticated "copies"). Actually current draft-ietf-mobike-protocol-07 do copy the addresses and ports from the IP header to the NO_NATS_ALLOWED payload (without any hashes or similar). It will return error (UNEXPECTEED_NAT_DETECTED) if those do not match. But as these are things that can change so it is better that the generic design document does not mention those, but simply mentions that there is problem, and the actual protocol document needs to take care of them. We do now have text: ---------------------------------------------------------------------- See Security considerations section of [I-D.ietf-mobike-protocol] for more information about security considerations of the actual protocol. ---------------------------------------------------------------------- at the end of security considerations section. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 16:49:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eucyi-0004zl-Pr for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 16:49:01 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26333 for ; Thu, 5 Jan 2006 16:47:42 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A7A5CFB27F; Thu, 5 Jan 2006 16:48:56 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 64065FB24F for ; Thu, 5 Jan 2006 16:48:54 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k05Llw211566; Thu, 5 Jan 2006 22:47:58 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k05Lludo006739; Thu, 5 Jan 2006 22:47:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601052147.k05Lludo006739@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tschofenig, Hannes" In-reply-to: Your message of Wed, 04 Jan 2006 14:13:46 +0100. Date: Thu, 05 Jan 2006 22:47:56 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Jari Arkko , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > 6.3. Message presentation > > ... > Load balancing is currently outside the scope of MOBIKE, however > > => as you shot in your feet with the non standard definition of load > balancing now you are in trouble because you still don't want the real > load balancing (multiple addresses in the same SA at the same time) > but want the thing in the middle (one address per SA but different > addresses in SAs and/or in time). i am not sure what exactly you would like to have changed. could you please elaborate a bit? => IMHO the problem is simple: there are 3 definitions of load balancing: Charter's one: o Load balancing. Multihoming is supported only in the sense of failing over to another interface; sending traffic over multiple addresses using the same SA is not supported. (note this is the commonly accepted one) Section 3.2 one: Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available IP addresses at a given point in time. (note this is a very limited, and IMHO too limited) Section 6.3 one which is not really described. What I'd like is a *place* for the limited load balancing (which is not commonly named load balancing outside the two current documents as it is *not* covered by the charter limitation) where a SA uses one address at one time but not all SAs use the same address. Now how to do this? 6.3 doesn't seem to be the right place because the text is clearly about possible address lists when what is needed are SPI lists. So I suggest to fix the text in 3.2 and does not say that MOBIKE but the current design does not aim to support load balancing (keeping the same definition). Note I am not the only person who can compare the design document and the charter so IMHO this should be really addressed before the IETF last call. Regards Francis.Dupont@point6.net _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 17:07:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EudGv-0002in-Hm for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 17:07:49 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29842 for ; Thu, 5 Jan 2006 17:06:33 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 111AEFB27F; Thu, 5 Jan 2006 17:07:47 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 29A66FB277 for ; Thu, 5 Jan 2006 17:07:44 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k05M7U212897; Thu, 5 Jan 2006 23:07:30 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k05M7U9o006821; Thu, 5 Jan 2006 23:07:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601052207.k05M7U9o006821@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Thu, 05 Jan 2006 14:33:20 +0200. <17341.4624.63925.406248@fireball.acr.fi> Date: Thu, 05 Jan 2006 23:07:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Jari Arkko , MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > I am not against this "authority" argument, my concern is about a > poor argumentation to defend the decision, i.e., I strongly suggest > to remove the whole argumentation and just to say it is the WG > decision. The text there is not there to "defend" the decision, it is there for background information, and to explain that we did consider these things, and that we made this decision. => but you should agree we have a more technical and detailed discussion now than when before the decision was made (:-). If you have better arguments for either side, feel free to submit them, I can add them there too. => the issue is we already have too many arguments and none can be as good as the "authority" one. Regards Francis.Dupont@point6.net _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 05 17:20:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EudT1-0003JR-Gm for mobike-archive@megatron.ietf.org; Thu, 05 Jan 2006 17:20:19 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01179 for ; Thu, 5 Jan 2006 17:19:03 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BD96DFB286; Thu, 5 Jan 2006 17:20:17 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 9974BFB285 for ; Thu, 5 Jan 2006 17:20:14 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k05MJx213621; Thu, 5 Jan 2006 23:19:59 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k05MJxWl006859; Thu, 5 Jan 2006 23:19:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601052219.k05MJxWl006859@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Thu, 05 Jan 2006 14:58:35 +0200. <17341.6139.490231.597809@fireball.acr.fi> Date: Thu, 05 Jan 2006 23:19:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Jari Arkko , Paul Hoffman Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > => yes but the protocol document addresses this issue so I simply suggest > to put the same text into the design document. This document is not meant to be limited to the specific protocol, it tries to be more generic one. The protocol document provided solution to that and the text describing that solution belongs to that document. > => strictly you're right but this is not how it is implemented (as the > options are not copies but hashes of the IP addresses the IP addresses > from the IP header are used but only after being checked against the > authenticated "copies"). Actually current draft-ietf-mobike-protocol-07 do copy the addresses and ports from the IP header to the NO_NATS_ALLOWED payload (without any hashes or similar). => only in the NAT prevention case, in the NAT detection case a hash is used in order to hide the real address. It will return error (UNEXPECTEED_NAT_DETECTED) if those do not match. But as these are things that can change so it is better that the generic design document does not mention those, but simply mentions that there is problem, and the actual protocol document needs to take care of them. => we agree. We do now have text: ^^^ ---------------------------------------------------------------------- See Security considerations section of [I-D.ietf-mobike-protocol] for more information about security considerations of the actual protocol. ---------------------------------------------------------------------- at the end of security considerations section. => this is a fine way to have to present problems but not the solutions (so to keep what has to be in the document). Regards Francis.Dupont@point6.net _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 06 01:39:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EulFy-00083U-Tg for mobike-archive@megatron.ietf.org; Fri, 06 Jan 2006 01:39:22 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08882 for ; Fri, 6 Jan 2006 01:38:02 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9A72AFB290; Fri, 6 Jan 2006 01:39:15 -0500 (EST) X-Original-To: Mobike@machshav.com Delivered-To: Mobike@machshav.com Received: from web35406.mail.mud.yahoo.com (web35406.mail.mud.yahoo.com [66.163.179.115]) by machshav.com (Postfix) with SMTP id A8C67FB286 for ; Fri, 6 Jan 2006 01:39:13 -0500 (EST) Received: (qmail 32117 invoked by uid 60001); 6 Jan 2006 06:39:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X0AB/SJUCI32V+gyEgqM9hYLWMclQBA120cl5seN6cwm1DeiNzn2f26cbc2OdgBwEx05bxuq2jG39Y2Ryz0haHYDkFBMdWUwXWdML8g7ofM111gyROXYbt0SSDJmmcBF1WwJxJ/wd4rN7c4G24YTPOxLDp2+60CdNSqCQCLATcE= ; Message-ID: <20060106063910.32115.qmail@web35406.mail.mud.yahoo.com> Received: from [203.130.213.233] by web35406.mail.mud.yahoo.com via HTTP; Fri, 06 Jan 2006 06:39:10 GMT Date: Fri, 6 Jan 2006 06:39:10 +0000 (GMT) From: Noval Aspani To: unsubscribe-Mobike@machshav.com MIME-Version: 1.0 Cc: Mobike@machshav.com Subject: [Mobike] (no subject) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jan 07 13:19:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvIeq-000243-Lv for mobike-archive@megatron.ietf.org; Sat, 07 Jan 2006 13:19:16 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25411 for ; Sat, 7 Jan 2006 13:17:59 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 329AFFB28D; Sat, 7 Jan 2006 13:19:14 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id B8AFFFB28A for ; Sat, 7 Jan 2006 13:19:11 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k07IJ8pj027776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Jan 2006 20:19:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k07IJ8sM005562; Sat, 7 Jan 2006 20:19:08 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17344.1564.111808.628646@fireball.acr.fi> Date: Sat, 7 Jan 2006 20:19:08 +0200 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Subject: [Mobike] draft-ietf-mobike-design-06.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html working copy of document: http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] I haven't received ACK from Pasi or Arkko yet, but as I need to go in few minutes, I will submit this current draft to the IETF secretary. If nobody has any comments to it I think it could also go to the IETF wide last call (i.e. Francis if you still have some exact text changes, please say so, I have only seen your discussions but I haven't seen any exact text changes). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 09 15:50:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3xu-0002w4-TB for mobike-archive@megatron.ietf.org; Mon, 09 Jan 2006 15:50:07 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20935 for ; Mon, 9 Jan 2006 15:48:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 356ECFB27D; Mon, 9 Jan 2006 20:50:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 7C9A6FB27C for ; Mon, 9 Jan 2006 20:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ew3xp-0003oW-Dh; Mon, 09 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jan 2006 15:50:01 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-06.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : Design of the MOBIKE Protocol Author(s) : T. Kivinen, H. Tschofenig Filename : draft-ietf-mobike-design-06.txt Pages : 37 Date : 2006-1-9 The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-06.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-06.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-06.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: <2006-1-9144314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-9144314.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 Thu Jan 26 07:51:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26bJ-0003vK-Ga for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 07:51:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10540 for ; Thu, 26 Jan 2006 07:50:13 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1C85CFB27F; Thu, 26 Jan 2006 07:51:42 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 41497FB27D for ; Thu, 26 Jan 2006 07:51:39 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0QCpVoE018223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2006 14:51:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0QCpTQZ016027; Thu, 26 Jan 2006 14:51:29 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17368.50641.411722.954187@fireball.acr.fi> Date: Thu, 26 Jan 2006 14:51:29 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200601052147.k05Lludo006739@givry.rennes.enst-bretagne.fr> References: <200601052147.k05Lludo006739@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 22 min Cc: Jari Arkko , MOBIKE Mailing List , Paul Hoffman , "Tschofenig, Hannes" Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis Dupont writes: > IMHO the problem is simple: there are 3 definitions of load > balancing: I do not agree that there is 3 definitions of load balancing. > Charter's one: > o Load balancing. Multihoming is supported only in the sense of > failing over to another interface; sending traffic over multiple > addresses using the same SA is not supported. > (note this is the commonly accepted one) > > Section 3.2 one: > Note that MOBIKE does not aim to support load balancing between > multiple IP addresses. That is, each peer uses only one of the > available IP addresses at a given point in time. > (note this is a very limited, and IMHO too limited) I think those definitions are mostly same, the charter version does not say anything what happens with multiple SAs, thus it keeps that open. The charter definition still says that it is failing over to another interface, which means it will not use multiple interfaces at all, it uses one and if that fails, it fails over to another interface, using only that after that. > Section 6.3 one which is not really described. Section 6.3 does not define any load balancing, it simply says that in future we might work on the load balancing issues too, thus we need to make sure our protocol is such it can be extended. > What I'd like is a *place* for the limited load balancing (which is not > commonly named load balancing outside the two current documents as it is > *not* covered by the charter limitation) where a SA uses one address at > one time but not all SAs use the same address. You can already do that. It is in the protocol. Simply create multiple IKE SAs and each of them can use separate address. Each IPsec SA inside those IKE SA moves along with the IKE SA. So we already have that feature you are asking for. It is also described in the design document (last sentence of the section 5.3). > Now how to do this? 6.3 doesn't seem to be the right place because the text > is clearly about possible address lists when what is needed are SPI lists. 6.3 is definately wrong place. The section 5.3 already talks about list of SPIs and also list of ranges of SPI values. > So I suggest to fix the text in 3.2 and does not say that MOBIKE but the > current design does not aim to support load balancing (keeping the same > definition). Load balancing in any forms is explicit non-goal for MOBIKE WG. The charter says that very clearly. The charter also lists that multihoming is only supported to support failing over, not for other reasons. It also explictly says that usingtraffic over mulple address for same SA is outside the scope, but that does not mean it would be the only thing covered by load balancing. Load balancing in general is outside the scope of MOBIKE WG. > Note I am not the only person who can compare the design document and > the charter so IMHO this should be really addressed before the IETF last > call. I do not really find anything that would be conflicting between the charter and the design document about the load balancing. Both of them say load balancing is outside the scope of MOBIKE WG and the current protocols. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:00:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26jv-0007EO-H2 for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:00:39 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11191 for ; Thu, 26 Jan 2006 07:59:07 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86D4AFB27D; Thu, 26 Jan 2006 08:00:37 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 297FDFB27C for ; Thu, 26 Jan 2006 08:00:34 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0QD0Uts014240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jan 2006 15:00:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0QD0UD3010154; Thu, 26 Jan 2006 15:00:30 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17368.51182.236728.223716@fireball.acr.fi> Date: Thu, 26 Jan 2006 15:00:30 +0200 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Subject: [Mobike] draft-ietf-mobike-design-06.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html] There has now been 2 weeks since I posted the new updated version having changes done because of the working group last call. I hope people who sent comments have had time to verify the changes made, and as there has not been any comments, I hope the changes have been ok. Anyways, I think we could continue this document forward to the IETF last call. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:14:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26xP-0004Kk-8N for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:14:35 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12549 for ; Thu, 26 Jan 2006 08:13:03 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8C0DBFB27F; Thu, 26 Jan 2006 08:14:33 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E16C5FB27D for ; Thu, 26 Jan 2006 08:14:31 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E5D8789904; Thu, 26 Jan 2006 15:14:29 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9F3E489902; Thu, 26 Jan 2006 15:14:29 +0200 (EET) Message-ID: <43D8CB51.5050909@piuha.net> Date: Thu, 26 Jan 2006 15:14:57 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93351.7090105@piuha.net> <17338.38245.21488.69655@fireball.acr.fi> In-Reply-To: <17338.38245.21488.69655@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] #D101: design draft issue: editorial X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > > >>> This definition is taken from [I-D.arkko-multi6dt-failure- >>> detection], and adapted to the MOBIKE context (we do allow >>> [RFC1918] addresses here, they are very common addresses used >>> inside NATs). >>> >>> >>Just add a plain reference, not explain the differences, since the >>differences keep changing as the SHIM6 work proceeds. Also, the >>reference is I-D.ietf-shim6-failure-detection. >> >> > >I was wondering that if someone who is very familiar with the shim6 >work would not notice that we are using different definition here, so >we should point out the differences, but if the terms defined there >are not well defined yet, then better remove the differences part. > > Right. Yes, remove the differences. >>Similar for the other definitions. >> >> > >I do not think there was differences in other terms, but fixed the >references. > > Ok. >>"mainly"? >> >> > >There used to be some more text about transport mode here, but now we >only say that there will be future ducouments, so removed "mainly" > > Ok. >>And there's some duplication with end of Section 3. Suggest: merge >>the paragraphs and place them in Section 4. >> >> > >Can you give more exact editing instructions, so I can do the changes. > > Looks OK now, not sure if you already edited this or not, but I don't remember the context anymore. >>> MOBIKE >>> does not support unidirectional address pairs (i.e. where you can >>> only send traffic in one direction when using single address pair). >>> >>> >>No need to redefine the term here. Just end after the word "pairs". >> >> > >Removed the definition. This used to be the only place earlier, but >forgot to remove this when added the definition to the terminology >section. > > Ok. >>> There are some cases which cannot be carried out within the >>> restrictions of the MOBIKE charter. >>> >>> >>To avoid talking about the charter, just say "... within MOBIKE". >> >> > >Hmm.... Then reader might be wondering why we cannot do that. Protocol >might be able to be designed to support those cases, but they are out >of scope of the charter, thus we cannot do them with MOBIKE. > >Anyways removed the text about charter restrictions. > > Ok. (You could also say that it was decided that those issues were not in the scope of the MOBIKE protocol version 1.) >>(Its better style to not use "we", I think. Go through the rest of >>the document, too, there are multiple occurrences. Such as in the >>next paragraph.) >> >> > >There is way too many occurrences that I do not want to start fixing >them all now. Actually I myself find it sometimes easier to read text >that uses "we" than text written to avoid using "we". > > Ok, nevermind... >>> The working group decided that MOBIKE uses NAT-T mechanisms from the >>> IKEv2 protocol as much as possible, but decided to change the dynamic >>> address update for IKEv2 packets to MUST NOT (it would break path >>> testing using IKEv2 packets, see Section 6.2). The working group >>> also decided to only send keepalives to the current address pair. >>> >>> >>Dynamic address update for IPsec packets? I'm unsure what you mean >>here. In any case, pointing to the actual requirement in IKEv2 spec >>would be useful here. >> >> > >RFC 4306, section 2.23 second last paragraph. It is little bit hard to >put exact references to the section 2.23 as it is several pages long >and this text refers to the one paragraph in there. > > You just did it :-) >>> From a technical point of view this feature addresses two issues: >>> >>> o There is no need to transmit IPsec data traffic. IPsec protected >>> data can be dropped which saves bandwidth. This does not provide >>> a functional benefit, i.e., nothing breaks if this feature is not >>> provided. >>> >>> o MOBIKE signaling messages are also ignored. The IKE-SA must not >>> be deleted and the suspend functionality (realized with the zero >>> address set) may require the IKE-SA to be tagged with a lifetime >>> value since the IKE-SA should not be kept alive for an undefined >>> period of time. Note that IKEv2 does not require that the IKE-SA >>> has a lifetime associated with it. In order to prevent the IKE-SA >>> from being deleted the dead-peer detection mechanism needs to be >>> suspended as well. >>> >>> >>... this feature raises two issues? >> >> > >As zero address set functionality would be solving those two issues, I >would say it addresses those issues, not raises them. They are already >present in the current protocol, and we do not propose any solution >for them now. I.e the issues is that we waste bandwidth by sending >data which will be ignored by the other end, and we tear down the IKE >SA because the other end cannot reply to our signaling packets. > >Perhaps better way woud be to say "From a technical point of view this >would provide following two features:"? > > Ok. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:15:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26xy-0004VO-V6 for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:15:11 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12607 for ; Thu, 26 Jan 2006 08:13:38 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B2F22FB27F; Thu, 26 Jan 2006 08:15:08 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 95C6AFB27D for ; Thu, 26 Jan 2006 08:15:06 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C43CA89903; Thu, 26 Jan 2006 15:15:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8C2D089902; Thu, 26 Jan 2006 15:15:05 +0200 (EET) Message-ID: <43D8CB74.5040101@piuha.net> Date: Thu, 26 Jan 2006 15:15:32 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A9335A.2020906@piuha.net> <17338.38840.873375.724594@fireball.acr.fi> In-Reply-To: <17338.38840.873375.724594@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] design draft issue: existing documents claim X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Ok. --Jari Tero Kivinen wrote: >Jari Arkko writes: > > >>> IKEv2 assumes that an IKE SA is created implicitly between the IP >>> address pair that is used during the protocol execution when >>> establishing the IKEv2 SA. This means that, in each host, only one >>> IP address pair is stored for the IKEv2 SA as part of a single IKEv2 >>> protocol session, and, for tunnel mode SAs, the hosts places this >>> single pair in the outer IP headers. Existing documents make no >>> provision to change this pair after an IKE SA is created. >>> >>> >>But doesn't NAT-T allow a limited form of changes? >> >> > >There is text in the RFC 4306 section 2.23 saying that implementation >SHOULD dynamically update the address of the host behind NAT if they >detect it is changed, but that is only limited for the NAT-T case and >only so that host not behind NAT does that for host behind NAT. > >I added text saying "(except for dynamic address update of NAT-T)" to >the end. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:29:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Bl-0001h1-Uh for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:29:26 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13730 for ; Thu, 26 Jan 2006 08:27:53 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1E0EBFB27C; Thu, 26 Jan 2006 08:29:24 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C018EFB277 for ; Thu, 26 Jan 2006 08:29:21 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AEB5089903; Thu, 26 Jan 2006 15:29:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3455489902; Thu, 26 Jan 2006 15:29:20 +0200 (EET) Message-ID: <43D8CECB.4010103@piuha.net> Date: Thu, 26 Jan 2006 15:29:47 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93382.2060600@piuha.net> <17338.41073.164519.184463@fireball.acr.fi> In-Reply-To: <17338.41073.164519.184463@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D103 design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > > >>> Preferred Address: >>> >>> The IP address of a peer to which MOBIKE and IPsec traffic should >>> be sent by default. A given peer has only one active preferred >>> address at a given point in time, except for the small time period >>> where it switches from an old to a new preferred address. This >>> definition is taken from [I-D.ietf-hip-mm] and adapted to the >>> MOBIKE context. >>> >>> >>The protocol draft does not use this term. >> >> > >True, but design document do use this term when describing different >options we had. This document is not only describing what we have in >the protocol document (the protocol document does that), this also >describes why and how we ended up there. > > Ah, I see now. OK. >>Peer address set is closer to what we want here? >> >> > >No peer address set is the set of all addresses, and preferred address >is the one address the other end preferred to be used. If we have only >one address pair in use (as we have with initiator decides option) >then the preferred addresses and current addresses are mostly same. > > Ok, I think. >>(Also, I'm not sure the protocol we have actually communicates >>the address preferences. The initiator makes a decision, but >>does the ordering in an address update indicate preference?) >> >> > >In current protocolwe do not communicate that, but we did consider >options where we did communicate those, and we do describe those in >the document, and then we say we ended up using initiator decides. > > Right. Can we make this clearer in the design document? >>> The MOBIKE protocol should be able to perform the following >>> operations: >>> >>> o Inform the other peer about the peer address set >>> >>> o Inform the other peer about the preferred address >>> >>> o Test connectivity along a path and thereby to detect an outage >>> situation >>> >>> o Change the preferred address >>> >>> >>Again, not sure we actually communicate the preferred >>information -- but I may be missing something. >> >> > >In initiator decides the preferred information is not needed to be >communicated that much, as initiator decides... the initiator simply >needs to know his own preferences and use those, as he is the one >making decisions. Again in other options we would need that >information. > > I understand. But you said "MOBIKE *protocol* should be able to perform ...". >>> Another MOBIKE usage scenario is depicted in Figure 2. In this >>> scenario, the MOBIKE peers are equipped with multiple interfaces (and >>> multiple IP addresses). Peer A has two interface cards with two IP >>> addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 >>> and IP_B2. Each peer selects one of its IP addresses as the >>> preferred address which is used for subsequent communication. >>> Various reasons (e.g., hardware or network link failures), may >>> require a peer to switch from one interface to another. >>> >>> >>Is this in line with what the protocol draft does? >> >> > >No, and it does not try to be aligned. We are describing generic >scenario, the actual protocol work differs from this generic scenario, >and we do not fully support this in the protocol we selected. As in >our case the initiator decides the preferences then the responders >preferences are ignored in our protocol. > > Has that been made clear later in the document? >>> Operational address pair: >>> >>> A pair of operational addresses are said to be an operational >>> address pair, if and only if bidirectional connectivity can be >>> shown between the two addresses. Note that sometimes it is >>> necessary to consider connectivity on a per-flow level between two >>> endpoints. This differentiation might be necessary to address >>> certain Network Address Translation types or specific firewalls. >>> This definition is taken from [I-D.arkko-multi6dt-failure- >>> detection] and adapted for the MOBIKE context. Although it is >>> possible to further differentiate unidirectional and bidirectional >>> operational address pairs, only bidirectional connectivity is >>> relevant to this document and unidirectional connectivity is out >>> of scope. >>> >>> >>(snip) >> >> >> >>> Bidirectional Address Pair:: >>> >>> The address pair, where traffic can be sent to the both >>> directions, simply by reversing the IP addresses. Note, that the >>> path of the packets going to each direction might be different. >>> >>> Unidirectional Address Pair:: >>> >>> The address pair, where traffic can only be sent in one direction, >>> and reversing the IP addresses and sending reply back does not >>> work. >>> >>> >>The explanation of directionality on the first definition >>seems superfluous. >> >> > >Mostly leftovers from the time when we didn't have bidirectional / >unidirectional address pairs defined here at all. > >On the other hand, I do not think the extra text there does any harm, >and might actually make it easier to understand what operational >address pair is. I do hate terms refering to other terms refering to >other terms where you need to parse through several definations of the >terms before you can find out what the term actually means. > > Ok. > > >>> Figure 1 shows a break-before-make mobility scenario where a mobile >>> node changes its point of network attachment. Prior to the change, >>> the mobile node had established an IPsec connection with a security >>> gateway which offered, for example, access to a corporate network. >>> The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took >>> place over the path labeled as 'old path'. The involved packets >>> carried the MN's "old" IP address and were forwarded by the "old" >>> access router (OAR) to the security gateway (GW). >>> >>> >>Consider talking only about routers, not access routers. >> >> > >I actually think access router is better, as we are not talking about >routers in the general, we are talking about the closest router >providing us the access to the internet. > > Ok. > > >>> MOBIKE interacts with the IPsec engine using for >>> example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon >>> can create entries in the Security Association (SAD) and Security >>> Policy Databases (SPD). The IPsec engine may also interact with >>> IKEv2 and MOBIKE daemon using this API. >>> >>> >>"IPsec engine" is a term that exists in RFC2401, I think. Use >>"IPsec implementation" or some other term. >> >> > >Nope. IPsec engine is not defined in the RFC 2401 or in the RFC 4301. > > Right, that was my complaint, but my e-mail missed the word "not" :-) >I have normally used IPsec engine to refer to the "kernel" side of the >IPsec implementation, i.e. things related to the actual packets, SAD, >and partly SPD too (i.e. those parts of SPD which are not related to >the IKE or policy management). > >IPsec implementation is bit wrong, as MOBIKE can be considered as part >of IPsec implementation too... as it is IKEv2 extension and IKEv2 is >part of IPsec implementation (i.e. part of the IPsec architecture >defined in RFC 4301). > >If you have better term to use than IPsec engine, I can switch to >that, but I myself cannot think one now. > > I see your problem. How about "the packet processing module of the IPsec implementation"? >>> In order to address certain failure >>> cases, MOBIKE should perform connectivity tests between the peers >>> (potentially over a number of different paths). >>> >>> >>I think they are called "path tests" in the protocol draft. >> >> > >I think path tests is bad name, as we are not testing paths, we are >testing connectivity between two addresses. > > Perhaps, but we are not debating the name -- what I'm saying is that you should align the terminology with the protocol draft (even if you might think that the term in the protocol draft was wrong). Otherwise it'll be confusing. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:32:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27F9-0003T3-Sg for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:32:56 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13998 for ; Thu, 26 Jan 2006 08:31:23 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3E334FB282; Thu, 26 Jan 2006 08:32:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id DAA5CFB27C for ; Thu, 26 Jan 2006 08:32:51 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D2D0489903; Thu, 26 Jan 2006 15:32:50 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8D98D89902; Thu, 26 Jan 2006 15:32:50 +0200 (EET) Message-ID: <43D8CF9D.8030700@piuha.net> Date: Thu, 26 Jan 2006 15:33:17 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A933C2.1000305@piuha.net> <17338.42771.665907.250601@fireball.acr.fi> In-Reply-To: <17338.42771.665907.250601@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D105 design draft issue: figure 3 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I still think that the figure should be changed (e.g. there's no routing protocols in a host). But perhaps its better if I try to send you alternative text (or picture in this case). --Jari Tero Kivinen wrote: >[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html > working copy of document: > http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] > >Jari Arkko writes: > > >>> +-------------+ +---------+ >>> |User-space | | MOBIKE | >>> |Protocols | +-->>| Daemon | >>> |relevant for | | | | >>> |MOBIKE | | +---------+ >>> +-------------+ | ^ >>> User Space ^ | ^ >>> ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ >>> Kernel Space v | v >>> _______ | v >>> +-------------+ / \ | +--------------+ >>> |Routing | / Trigger \ | | IPsec | >>> |Protocols |<<-->>| Database |<<-+ +>+ Engine | >>> | | \ / | | (+Databases) | >>> +-----+---+---+ \_______/ | +------+-------+ >>> ^ ^ ^ | ^ >>> | +---------------+-------------+--------+-----+ >>> | v | | | >>> | +-------------+ | | | >>> I | |Kernel-space | | | | I >>> n | +-------->+Protocols +<----+-----+ | | n >>> t v v |relevant for | | v v v t >>> e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e >>> r | Input | +-------------+ | | Outgoing | r >>> f | Packet +<--------------------------+ | Interface | f >>> ==a>|Processing|===============================| Processing |=a> >>> c | | | | c >>> e +----------+ +------------+ e >>> s s >>> ===> = IP packets arriving/leaving a MOBIKE node >>> <-> = control and configuration operations >>> >>> Figure 3: Framework >>> >>> >>I am confused by the role of the "Kernel-space protocols >>relevant for MOBIKE" box in this figure. There are parts >>of a node implementation that have to deal with IPsec >>processing; is this what you mean? And there are parts >>of a node implementation that may provide information >>to, e.g., MOBIKE and MOBILE IP -- such as IPv6 NUD or >>DNA. Is this what you mean? >> >> > >I think both, i.e. both the IPsec processing things, i.e. for example >detecting IPsec packets coming from wrong address, etc, and also other >protocols like you list there. > >There is quite limited space for drawing pictures in ascii, so it is >better to cluster things a bit more and describe the actual modules >needed, and not try to duplicate each box from the Pasi's slide. > > > >>I think the latter is an important >>part that should be shown, but such components would appear >>to provide input to the MOBIKE daemon directly or via >>a "trigger database" rather than effect input and output >>processing directly. >> >> > >The kernel-space protocols has arrows to trigger database, and to the >input / output processing. > > > >>What are "User-space Protocols Relevant for MOBIKE"? >>I can't think of any... >> >> > >DHCP, perhaps PPP etc. > > > >>Also, I'd rather not see "routing protocols" in this >>figure, as it will confuse people. >> >> > >Routing do affect the selection of the addresses and interfaces, so I >think it needs to be shown here. > > > >>And while a trigger database is a good idea, I'd rather not >>introduce it here. It would be better to have a simplified ascii >>version of the slide from IETF-62: >> >> > >I think having trigger database there actually do simplify the picture >quite a lot, and that's why I think it is good idea to keep it there. > > > >>http://www3.ietf.org/proceedings/05mar/slides/mobike-1/sld6.htm >> >> > >Simplifying that picture does not really help, as the main idea for >that picture was to so complicated enough picture having all kind of >boxes and arrows, so that everybody would understand that this MOBIKE >is only very small part of the whole solution. > >Simplification of a very complicated picture which is complicated on >purpose (actually complicated to make sure it obfuscates things) >doesn't really help... :-) > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:35:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27HH-00045j-35 for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:35:07 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14160 for ; Thu, 26 Jan 2006 08:33:34 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B5773FB289; Thu, 26 Jan 2006 08:35:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 26352FB282 for ; Thu, 26 Jan 2006 08:35:02 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 52B1789903; Thu, 26 Jan 2006 15:35:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 159D389902; Thu, 26 Jan 2006 15:35:01 +0200 (EET) Message-ID: <43D8D01F.8090303@piuha.net> Date: Thu, 26 Jan 2006 15:35:27 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A933CC.30605@piuha.net> <17338.43114.668805.682871@fireball.acr.fi> In-Reply-To: <17338.43114.668805.682871@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D106 design draft issue: nat-p X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit A man-in-the-middle can't, but one of the participants still can. You could explain this, but the resulting text would be longer than what I proposed. --Jari Tero Kivinen wrote: >[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html > working copy of document: > http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] > >Jari Arkko writes: > > >>> This gives extra >>> protection against 3rd party bombing attacks (the attacker cannot >>> divert the traffic to some 3rd party). >>> >>> >>This seems inaccurate, or at least too strong. We have >>other mechanisms to prevent that, and the NAT-T based >>attack only works for on-path attackers. Just say >>"This avoids any possibility of on-path attackers modifying >>addresses in headers" and refer to Francis's pseudonat >>attack draft. >> >> > >Why do you think that NAT-preventation does not protect against 3rd >party bombing attacks? > >If we do put all IP addresses used inside the packets, and >cryptographically integrity protect them, and we enable NAT >preventation, which means we do not allow NATs, how can attacker >divert the traffic to some 3rd party? > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:37:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Jl-0004gQ-Ae for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:37:41 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14390 for ; Thu, 26 Jan 2006 08:36:09 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CDFEAFB286; Thu, 26 Jan 2006 08:37:39 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CA899FB277 for ; Thu, 26 Jan 2006 08:37:38 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0568089903; Thu, 26 Jan 2006 15:37:38 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C40AD89902; Thu, 26 Jan 2006 15:37:37 +0200 (EET) Message-ID: <43D8D0BD.5020304@piuha.net> Date: Thu, 26 Jan 2006 15:38:05 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A9341B.9050808@piuha.net> <17338.43667.989186.249127@fireball.acr.fi> In-Reply-To: <17338.43667.989186.249127@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D107 design draft issue: section 5.5 nits X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Ok on all. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:38:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Ky-0005Ou-UG for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:38:58 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14491 for ; Thu, 26 Jan 2006 08:37:23 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7B154FB298; Thu, 26 Jan 2006 08:38:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 622A4FB290 for ; Thu, 26 Jan 2006 08:38:52 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9135189903; Thu, 26 Jan 2006 15:38:51 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 49D5D89902; Thu, 26 Jan 2006 15:38:51 +0200 (EET) Message-ID: <43D8D106.2040203@piuha.net> Date: Thu, 26 Jan 2006 15:39:18 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A9342B.6050207@piuha.net> <17338.44522.460691.692268@fireball.acr.fi> In-Reply-To: <17338.44522.460691.692268@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D108 design draft issue: ikev2 payloads X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Ok. Tero Kivinen wrote: >[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html > working copy of document: > http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt] > >Jari Arkko writes: > > >>> Some implementations might have problems parsing more >>> than certain number of IKEv2 payloads, but if the sender sends them >>> in the most preferred first, the receiver can only use the first >>> addresses, it was willing to parse. >>> >>> >>Hmm... the IKEv2 spec seems to say that you MUST >>be able to reject Critical=1 payloads that you don't >>recognize. This seems to imply that you must go through >>all the payloads, or am I missing something? >> >> > >You need to go through all payloads to check the critical bit and that >the payload chaining is correct. On the other hand you do not need to >parse 256 status notifications or 100 certificates the other end >decided to send to you. You only need to parse first certificate >payload, as it is end entity certificate, and you can ignore the rest, >and fetch the certificates from some other source if you want. > >I do know there was some IKEv1 implementations that refused to parse >some of our packets as they did have fixed limit of number of >certificate payloads they accepted, or they had fixed limit of number >of SA proposal you could have etc. I wouldn't be suprised that there >would be implementation out that has fixed number of status >notifications it will parse or decode. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:52:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Xw-0002sL-51 for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:52:20 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16420 for ; Thu, 26 Jan 2006 08:50:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D17F7FB27D; Thu, 26 Jan 2006 08:52:13 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 7A871FB277 for ; Thu, 26 Jan 2006 08:52:12 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 42FF989903; Thu, 26 Jan 2006 15:52:11 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 09ADA89902; Thu, 26 Jan 2006 15:52:11 +0200 (EET) Message-ID: <43D8D426.2040909@piuha.net> Date: Thu, 26 Jan 2006 15:52:38 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93455.7020507@piuha.net> <17338.45201.524607.918065@fireball.acr.fi> In-Reply-To: <17338.45201.524607.918065@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D109 design draft issue: security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > >I am not sure adding pointer to the protocol document helps that much, >as I assume people will read the protocol document anyways, but >perhaps adding text "See Security considerations section of target="I-D.ietf-mobike-protocol"/> for more information about >security considerations of the actual protocol." helps. > > Yes. Maybe you could also cut the paragraph about ICMP (since it isn't complete). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 08:54:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Zk-0003Qn-D8 for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 08:54:12 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16710 for ; Thu, 26 Jan 2006 08:52:40 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 884C2FB282; Thu, 26 Jan 2006 08:54:10 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2CE05FB27C for ; Thu, 26 Jan 2006 08:54:06 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 54C1989903; Thu, 26 Jan 2006 15:54:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 19D9A89902; Thu, 26 Jan 2006 15:54:05 +0200 (EET) Message-ID: <43D8D498.2090609@piuha.net> Date: Thu, 26 Jan 2006 15:54:32 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93446.4080907@piuha.net> <17338.47872.365772.320789@fireball.acr.fi> In-Reply-To: <17338.47872.365772.320789@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D112 design draft issue: references X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >>It might be that the MOBIKE protocol spec is a useful >>reference to the reader as well... >> >> > >I do not think you must read the protocol draft to understand this >document, thats why it is informative reference. On the other hand you >do need to know something about IKEv2 or RFC4301 architecture before >reading this. > > Ok. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 09:02:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27hc-0006pm-03 for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 09:02:20 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17780 for ; Thu, 26 Jan 2006 09:00:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 910B6FB289; Thu, 26 Jan 2006 09:02:18 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 529A3FB284 for ; Thu, 26 Jan 2006 09:02:16 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7912B89903; Thu, 26 Jan 2006 16:02:15 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 426EA89902; Thu, 26 Jan 2006 16:02:15 +0200 (EET) Message-ID: <43D8D682.6000203@piuha.net> Date: Thu, 26 Jan 2006 16:02:42 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <17368.51182.236728.223716@fireball.acr.fi> In-Reply-To: <17368.51182.236728.223716@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mobike@machshav.com Subject: Re: [Mobike] draft-ietf-mobike-design-06.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero, Thanks for the updates & issue resolutions! I have now reviewed the changes per my issues, and they were OK, with the exception of few loose ends (mentioned in the e-mails). It would be great if we could solve those too. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 09:51:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28Sr-0006Nw-2d for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 09:51:09 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22031 for ; Thu, 26 Jan 2006 09:49:36 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7A27DFB27D; Thu, 26 Jan 2006 09:51:07 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id A8874FB27C for ; Thu, 26 Jan 2006 09:51:04 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k0QEogF14647; Thu, 26 Jan 2006 15:50:42 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k0QEoggu014228; Thu, 26 Jan 2006 15:50:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601261450.k0QEoggu014228@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Thu, 26 Jan 2006 14:51:29 +0200. <17368.50641.411722.954187@fireball.acr.fi> Date: Thu, 26 Jan 2006 15:50:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Jari Arkko , MOBIKE Mailing List , Paul Hoffman , "Tschofenig, Hannes" Subject: Re: [Mobike] WGLC on the design draft X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > IMHO the problem is simple: there are 3 definitions of load > balancing: I do not agree that there is 3 definitions of load balancing. => what you support and what I want are two different things and we use the same name, so I don't understand why you disagree. > Charter's one: > o Load balancing. Multihoming is supported only in the sense of > failing over to another interface; sending traffic over multiple > addresses using the same SA is not supported. > (note this is the commonly accepted one) > > Section 3.2 one: > Note that MOBIKE does not aim to support load balancing between > multiple IP addresses. That is, each peer uses only one of the > available IP addresses at a given point in time. > (note this is a very limited, and IMHO too limited) I think those definitions are mostly same, => no, there are subtle but important differences (we should disagree about the meaning of "mostly" too :-). the charter version does not say anything what happens with multiple SAs, thus it keeps that open. => yes, the charter is open, mostly because it has to address more than the mobility problem... The charter definition still says that it is failing over to another interface, which means it will not use multiple interfaces at all, it uses one and if that fails, it fails over to another interface, using only that after that. => hum: "or to use multiple interfaces simultaenously"... So I am afraid you assume too much about the charter says. > What I'd like is a *place* for the limited load balancing (which is not > commonly named load balancing outside the two current documents as it is > *not* covered by the charter limitation) where a SA uses one address at > one time but not all SAs use the same address. You can already do that. => yes, I can already manage mobility without Mobike too. It is in the protocol. Simply create multiple IKE SAs and each of them can use separate address. Each IPsec SA inside those IKE SA moves along with the IKE SA. So we already have that feature you are asking for. => no, I have no direct support of this feature. It is also described in the design document (last sentence of the section 5.3). > Now how to do this? 6.3 doesn't seem to be the right place because the text > is clearly about possible address lists when what is needed are SPI lists. 6.3 is definately wrong place. The section 5.3 already talks about list of SPIs and also list of ranges of SPI values. => but this text is not about proposing a solution but explaining why the current proposal does nothing. > So I suggest to fix the text in 3.2 and does not say that MOBIKE but the > current design does not aim to support load balancing (keeping the same > definition). Load balancing in any forms is explicit non-goal for MOBIKE WG. The charter says that very clearly. => not in any form, only "sending traffic over multiple addresses using the same SA is not supported". The charter also lists that multihoming is only supported to support failing over, not for other reasons. It also explictly says that using traffic over multiple address for same SA is outside the scope, but that does not mean it would be the only thing covered by load balancing. Load balancing in general is outside the scope of MOBIKE WG. => yes, and in fact multihoming too... (:-) > Note I am not the only person who can compare the design document and > the charter so IMHO this should be really addressed before the IETF last > call. I do not really find anything that would be conflicting between the charter and the design document about the load balancing. Both of them say load balancing is outside the scope of MOBIKE WG and the current protocols. => I'll forward your message to the MONAMI6 people and we'll see if your vision of multihoming is really compatible with the current work in other WGs. Regards Francis.Dupont@point6.net _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 17:14:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2FNb-0006si-RG for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 17:14:11 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12406 for ; Thu, 26 Jan 2006 17:12:36 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 83A7AFB282; Thu, 26 Jan 2006 17:14:06 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 83D59FB27D for ; Thu, 26 Jan 2006 17:14:04 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C2CD189903; Fri, 27 Jan 2006 00:14:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 79B8789902; Fri, 27 Jan 2006 00:14:02 +0200 (EET) Message-ID: <43D949C5.6050307@piuha.net> Date: Fri, 27 Jan 2006 00:14:29 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List X-Virus-Scanned: ClamAV using ClamSMTP Cc: Erik Nordmark Subject: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi, Erik read our protocol spec recently, and he had questions about the use of addresses in the protocol. Specifically, he was worried about "time shifting" or "address stealing" attacks where a host uses first address A in one place and then later B in another place. The question is what happens when some other host that comes later to the first place and gets the same address A as the first host. Will two hosts be able to communicate with the same peer? What will happen with ongoing sessions of the first host? I explained that in MOBIKE the outer addresses as such don't matter; they are just the tunnel endpoints (although Appendix A describes a case where an implementation can get this wrong). What matters is the inner addresses -- its those addresses that are used to match what packets go to what peer. Getting the address allocations right is essentially for the security of the system. This is indeed the case even without MOBIKE in base IKEv2 VPN usage*. However, Erik asked whether the document makes it clear that it only supports the scenario where at least one of the peers is a gateway that ensures the address allocations are correct. And I was unable to answer that. Are we making it clear enough? Also, is it possible to use MOBIKE in host-to-host tunnel mode? If so, how? And have the security considerations relating to such usage been described? Thoughts, anyone? Erik, feel free to post more detailed questions and concerns... --Jari *) But I was unable to find a statement either in RFC 4306 or the clarifications document about address allocation authorization issues. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jan 26 20:20:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2IID-0001BV-So for mobike-archive@megatron.ietf.org; Thu, 26 Jan 2006 20:20:52 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23715 for ; Thu, 26 Jan 2006 20:19:17 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 49DF1FB282; Thu, 26 Jan 2006 20:20:47 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from web80606.mail.yahoo.com (web80606.mail.yahoo.com [66.218.79.95]) by machshav.com (Postfix) with SMTP id A5E01FB27D for ; Thu, 26 Jan 2006 20:20:45 -0500 (EST) Received: (qmail 10785 invoked by uid 60001); 27 Jan 2006 01:20:43 -0000 Message-ID: <20060127012043.10783.qmail@web80606.mail.yahoo.com> Received: from [206.132.194.2] by web80606.mail.yahoo.com via HTTP; Thu, 26 Jan 2006 17:20:43 PST Date: Thu, 26 Jan 2006 17:20:43 -0800 (PST) From: Mohan Parthasarathy To: Jari Arkko , MOBIKE Mailing List In-Reply-To: <43D949C5.6050307@piuha.net> MIME-Version: 1.0 Cc: Erik Nordmark Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari, This is the same case what Thomas Aura raised and the Appendix has the answers. Regarding, host-to-host tunnel mode, i would say that it is not supported by observing the following. In the Introduction, The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. And in scope and limitations, This document focuses on the main scenario outlined above, and supports only tunnel mode IPsec SAs. This tells me that only VPN gateway is supported. In the host-to-host tunnel mode case, one can still assume that no two nodes (among a set of nodes) have the same "inner" address. Is there any problem in making such assumptions ? -mohan --- Jari Arkko wrote: > > Hi, > > Erik read our protocol spec recently, and he had > questions about the use of addresses in the > protocol. > Specifically, he was worried about "time shifting" > or "address stealing" attacks where a host uses > first address A in one place and then later B in > another place. The question is what happens when > some other host that comes later to the first place > and gets the same address A as the first host. Will > two hosts be able to communicate with the same peer? > What will happen with ongoing sessions of the first > host? > > I explained that in MOBIKE the outer addresses > as such don't matter; they are just the tunnel > endpoints (although Appendix A describes a > case where an implementation can get this > wrong). What matters is the inner addresses -- > its those addresses that are used to match what > packets go to what peer. Getting the address > allocations right is essentially for the security > of the system. This is indeed the case even without > MOBIKE in base IKEv2 VPN usage*. > > However, Erik asked whether the document makes > it clear that it only supports the scenario where > at least one of the peers is a gateway that ensures > the address allocations are correct. And I was > unable > to answer that. Are we making it clear enough? Also, > is it possible to use MOBIKE in host-to-host tunnel > mode? If so, how? And have the security > considerations > relating to such usage been described? > > Thoughts, anyone? Erik, feel free to post more > detailed > questions and concerns... > > --Jari > > *) But I was unable to find a statement either in > RFC 4306 or the clarifications document about > address allocation authorization issues. > > _______________________________________________ > 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 27 08:08:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2TKm-0007Gq-IO for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 08:08:12 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06627 for ; Fri, 27 Jan 2006 08:06:38 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 881F7FB277; Fri, 27 Jan 2006 08:08:07 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E69D3FB249 for ; Fri, 27 Jan 2006 08:08:04 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0RD82Mj017482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2006 15:08:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0RD81m6029290; Fri, 27 Jan 2006 15:08:01 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17370.6961.322532.321678@fireball.acr.fi> Date: Fri, 27 Jan 2006 15:08:01 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43D8CB51.5050909@piuha.net> References: <43A93351.7090105@piuha.net> <17338.38245.21488.69655@fireball.acr.fi> <43D8CB51.5050909@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: MOBIKE Mailing List Subject: Re: [Mobike] #D101: design draft issue: editorial X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html] This issue #D101 is now closed. Jari Arkko writes: > >RFC 4306, section 2.23 second last paragraph. It is little bit hard to > >put exact references to the section 2.23 as it is several pages long > >and this text refers to the one paragraph in there. > > > You just did it :-) Ok, added the lengthy pointer, easier now when the rfc is out as I know the text does not change anymore. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 08:23:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2TZQ-000579-My for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 08:23:20 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07438 for ; Fri, 27 Jan 2006 08:21:46 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E0D3FFB277; Fri, 27 Jan 2006 08:23:16 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 6AEECFB24F for ; Fri, 27 Jan 2006 08:23:14 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0RDNDBu016610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2006 15:23:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0RDNC5b016524; Fri, 27 Jan 2006 15:23:12 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17370.7872.846323.623288@fireball.acr.fi> Date: Fri, 27 Jan 2006 15:23:12 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43D8CECB.4010103@piuha.net> References: <43A93382.2060600@piuha.net> <17338.41073.164519.184463@fireball.acr.fi> <43D8CECB.4010103@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 11 min Cc: MOBIKE Mailing List Subject: Re: [Mobike] D103 design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html] Jari Arkko writes: > >>(Also, I'm not sure the protocol we have actually communicates > >>the address preferences. The initiator makes a decision, but > >>does the ordering in an address update indicate preference?) > > > >In current protocolwe do not communicate that, but we did consider > >options where we did communicate those, and we do describe those in > >the document, and then we say we ended up using initiator decides. > > > > > Right. Can we make this clearer in the design document? ... > I understand. But you said "MOBIKE *protocol* should be > able to perform ...". I added text there "(not all of those are done explictly by the current protocol)". > >No, and it does not try to be aligned. We are describing generic > >scenario, the actual protocol work differs from this generic scenario, > >and we do not fully support this in the protocol we selected. As in > >our case the initiator decides the preferences then the responders > >preferences are ignored in our protocol. > > > Has that been made clear later in the document? I do not think we explictly mention that we ignore responder preferences, or that we assume that the initiator uses its own preferences when selecting which address to use next. Do you think we would really need that? > >Nope. IPsec engine is not defined in the RFC 2401 or in the RFC 4301. > > > > > Right, that was my complaint, but my e-mail missed the > word "not" :-) > > >I have normally used IPsec engine to refer to the "kernel" side of the > >IPsec implementation, i.e. things related to the actual packets, SAD, > >and partly SPD too (i.e. those parts of SPD which are not related to > >the IKE or policy management). > > > >IPsec implementation is bit wrong, as MOBIKE can be considered as part > >of IPsec implementation too... as it is IKEv2 extension and IKEv2 is > >part of IPsec implementation (i.e. part of the IPsec architecture > >defined in RFC 4301). > > > >If you have better term to use than IPsec engine, I can switch to > >that, but I myself cannot think one now. > > > > > I see your problem. How about "the packet processing > module of the IPsec implementation"? Done. > >>> In order to address certain failure > >>> cases, MOBIKE should perform connectivity tests between the peers > >>> (potentially over a number of different paths). > >>> > >>> > >>I think they are called "path tests" in the protocol draft. > >> > >> > > > >I think path tests is bad name, as we are not testing paths, we are > >testing connectivity between two addresses. > > > > > Perhaps, but we are not debating the name -- what I'm > saying is that you should align the terminology with the > protocol draft (even if you might think that the term in > the protocol draft was wrong). Otherwise it'll be confusing. I tought we decided that the protocol draft should be following the design draft terminology, not the other way around. Actully in the issue 29 of the protocol draft you said: "Jari Arkko (2005-07-14): My feeling is that, for practical reasons, we should try to get rid of the term path, unless we use it in the route-included sense. There are too many people that will complain when they will see their favorite term misused :-)" And then Pasi commented: "Pasi Eronen (2005-07-14): Well, it certainly seems so... I've now changed those instances of "path" that don't really consider the route to something else (but I've kept expressions like "paths that contain NATs", "off-path", or "currently used path has stopped working", which are more about the route than just a pair of addresses). CHANGE_PATH notification was renamed to UPDATE_SA_ADDRESSES." I remember that we changed away from path in the desing draft around same time, and then we started using terms like "IP address pairs" and so on. As the "connectivity tests" do not really care about the actual routers on the path, so I do not think it should be called "path tests": "Pasi Eronen (2005-07-18): Clarified some things, now avoids using the word "path" in senses that don't really consider the route taken by the packets." -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 08:41:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2TrN-0002Ow-35 for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 08:41:53 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08707 for ; Fri, 27 Jan 2006 08:40:19 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AD31FFB27D; Fri, 27 Jan 2006 08:41:50 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E4ED0FB277 for ; Fri, 27 Jan 2006 08:41:48 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0RDflXg002636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2006 15:41:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0RDfkBv010588; Fri, 27 Jan 2006 15:41:46 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17370.8986.827751.943337@fireball.acr.fi> Date: Fri, 27 Jan 2006 15:41:46 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43D8D01F.8090303@piuha.net> References: <43A933CC.30605@piuha.net> <17338.43114.668805.682871@fireball.acr.fi> <43D8D01F.8090303@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 10 min Cc: MOBIKE Mailing List Subject: Re: [Mobike] D106 design draft issue: nat-p X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > A man-in-the-middle can't, but one of the participants > still can. You could explain this, but the resulting > text would be longer than what I proposed. Ok, changed to your text (but left out the reference, as the pseudonat draft is expired last summer). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 08:42:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2TsQ-0002oN-Vd for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 08:42:59 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08778 for ; Fri, 27 Jan 2006 08:41:26 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 92A25FB27D; Fri, 27 Jan 2006 08:42:57 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9D6BAFB277 for ; Fri, 27 Jan 2006 08:42:55 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CD1ED89907; Fri, 27 Jan 2006 15:42:54 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4C9A989906; Fri, 27 Jan 2006 15:42:54 +0200 (EET) Message-ID: <43DA2379.50304@piuha.net> Date: Fri, 27 Jan 2006 15:43:21 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A933CC.30605@piuha.net> <17338.43114.668805.682871@fireball.acr.fi> <43D8D01F.8090303@piuha.net> <17370.8986.827751.943337@fireball.acr.fi> In-Reply-To: <17370.8986.827751.943337@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D106 design draft issue: nat-p X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Ok Tero Kivinen wrote: >Jari Arkko writes: > > >>A man-in-the-middle can't, but one of the participants >>still can. You could explain this, but the resulting >>text would be longer than what I proposed. >> >> > >Ok, changed to your text (but left out the reference, as the pseudonat >draft is expired last summer). > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 08:43:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2TtP-00035f-3T for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 08:43:59 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08834 for ; Fri, 27 Jan 2006 08:42:26 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D6FB8FB277; Fri, 27 Jan 2006 08:43:57 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E682EFB24F for ; Fri, 27 Jan 2006 08:43:54 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0RDhriD007233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2006 15:43:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0RDhrTv006651; Fri, 27 Jan 2006 15:43:53 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17370.9113.717361.889944@fireball.acr.fi> Date: Fri, 27 Jan 2006 15:43:53 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43D8D426.2040909@piuha.net> References: <43A93455.7020507@piuha.net> <17338.45201.524607.918065@fireball.acr.fi> <43D8D426.2040909@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: MOBIKE Mailing List Subject: Re: [Mobike] D109 design draft issue: security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > Yes. Maybe you could also cut the paragraph about > ICMP (since it isn't complete). What do you mean that it is not complete? -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 08:52:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2U1V-0007gh-33 for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 08:52:21 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09414 for ; Fri, 27 Jan 2006 08:50:47 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4046FFB27D; Fri, 27 Jan 2006 08:52:18 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 76C03FB24F for ; Fri, 27 Jan 2006 08:52:16 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0RDqFXJ008238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2006 15:52:15 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0RDqEjG013416; Fri, 27 Jan 2006 15:52:14 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17370.9614.898295.529620@fireball.acr.fi> Date: Fri, 27 Jan 2006 15:52:14 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43DA206F.7070102@piuha.net> References: <43A93382.2060600@piuha.net> <17338.41073.164519.184463@fireball.acr.fi> <43D8CECB.4010103@piuha.net> <17370.7872.846323.623288@fireball.acr.fi> <43DA206F.7070102@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: MOBIKE Mailing List Subject: Re: [Mobike] D103 design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko writes: > Ah, now I see what your problem was. I still stand > by the earlier decisions about not using the word > path. But... the protocol document is done (approved > by IESG) and we're not editing it anymore unless > there's a major reason to do so. > > My original issue was that the protocol spec calls > the testing function "path testing". So if we are > specifically referring that functionality then perhaps > we should use the same term. Otherwise lets use > a more appropriate term. > > Oh well, I'm not sure this is easily fixable given no > edits to the protocol draft. I'll let you decide what > to do. I think we now use "connectivity test" in the more abstract general text and then we do use "path test" when we talk about the exact implementation issues on the protocol, so I do not think we have problem here. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 09:00:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2U9m-0001uW-SM for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 09:00:55 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10243 for ; Fri, 27 Jan 2006 08:59:21 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 26B95FB27F; Fri, 27 Jan 2006 09:00:50 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AAE2AFB277 for ; Fri, 27 Jan 2006 09:00:47 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6EC5F89905; Fri, 27 Jan 2006 15:29:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 327DA89904; Fri, 27 Jan 2006 15:29:56 +0200 (EET) Message-ID: <43DA206F.7070102@piuha.net> Date: Fri, 27 Jan 2006 15:30:23 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93382.2060600@piuha.net> <17338.41073.164519.184463@fireball.acr.fi> <43D8CECB.4010103@piuha.net> <17370.7872.846323.623288@fireball.acr.fi> In-Reply-To: <17370.7872.846323.623288@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D103 design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >>I understand. But you said "MOBIKE *protocol* should be >>able to perform ...". >> >> > >I added text there "(not all of those are done explictly by the >current protocol)". > > Ok. > > >>>No, and it does not try to be aligned. We are describing generic >>>scenario, the actual protocol work differs from this generic scenario, >>>and we do not fully support this in the protocol we selected. As in >>>our case the initiator decides the preferences then the responders >>>preferences are ignored in our protocol. >>> >>> >>> >>Has that been made clear later in the document? >> >> > >I do not think we explictly mention that we ignore responder >preferences, or that we assume that the initiator uses its own >preferences when selecting which address to use next. Do you think we >would really need that? > > I think it is useful to point out the differences between the abstract discussion you have in the design document and the specific capabilities of the protocol as it turned out to be. But I'll leave it you as the editor to worry about the details... >>>I think path tests is bad name, as we are not testing paths, we are >>>testing connectivity between two addresses. >>> >>> >>> >>> >>Perhaps, but we are not debating the name -- what I'm >>saying is that you should align the terminology with the >>protocol draft (even if you might think that the term in >>the protocol draft was wrong). Otherwise it'll be confusing. >> >> > >I tought we decided that the protocol draft should be following the >design draft terminology, not the other way around. Actully in the >issue 29 of the protocol draft you said: > >"Jari Arkko (2005-07-14): > >My feeling is that, for practical reasons, we should try to >get rid of the term path, unless we use it in the route-included >sense. There are too many people that will complain when >they will see their favorite term misused :-)" > >And then Pasi commented: > >"Pasi Eronen (2005-07-14): > >Well, it certainly seems so... > >I've now changed those instances of "path" that don't really >consider the route to something else (but I've kept expressions >like "paths that contain NATs", "off-path", or "currently used >path has stopped working", which are more about the route >than just a pair of addresses). CHANGE_PATH notification was >renamed to UPDATE_SA_ADDRESSES." > >I remember that we changed away from path in the desing draft around >same time, and then we started using terms like "IP address pairs" and >so on. > >As the "connectivity tests" do not really care about the actual >routers on the path, so I do not think it should be called "path >tests": > > Ah, now I see what your problem was. I still stand by the earlier decisions about not using the word path. But... the protocol document is done (approved by IESG) and we're not editing it anymore unless there's a major reason to do so. My original issue was that the protocol spec calls the testing function "path testing". So if we are specifically referring that functionality then perhaps we should use the same term. Otherwise lets use a more appropriate term. Oh well, I'm not sure this is easily fixable given no edits to the protocol draft. I'll let you decide what to do. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 09:16:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UPI-0008B2-6G for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 09:16:56 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11713 for ; Fri, 27 Jan 2006 09:15:22 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4F97FB282; Fri, 27 Jan 2006 09:16:52 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7756AFB27F for ; Fri, 27 Jan 2006 09:16:51 -0500 (EST) Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0REGmJN029998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 16:16:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0REGmNF026832; Fri, 27 Jan 2006 16:16:48 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17370.11088.244053.49083@fireball.acr.fi> Date: Fri, 27 Jan 2006 16:16:48 +0200 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 13 min Subject: [Mobike] Closed some issues, submitting new version X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit [issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html] I closed following issues (Some after ACK from auther, some after lack of comments and as I think those are already resolved): D117 Question about IP address changes D116 Misc comments from Pasi D114 Terminology comments from Pasi D113 Overall comments from Pasi D112 References D111 More comments from Francis D110 Comments from Francis D108 IKEv2 Payloads D107 Section 5.5 nits D106 NAT-P (NAT preventation) D104 Definition of load balancing D103 Terminology alignment D102 Existing documents claim D101 Editorial comments from Jari If someone disagrees about closing any of those issues, please reply quickly. Open issues are: D115 Return Routability D109 Security Considerations D105 Figure 3 D115 is waiting for Pasi to comment my changes and comments, as I am not sure if my changes satisfy him. D109 is waiting for comment from Jari, about why the ICMP text isn't complete). D105 is waiting for new picture from Jari. I will be submitting new version of the draft in few minutes. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 09:24:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UWe-0001Yy-RN for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 09:24:32 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12374 for ; Fri, 27 Jan 2006 09:23:00 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E1323FB282; Fri, 27 Jan 2006 09:24:30 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 06D54FB27F for ; Fri, 27 Jan 2006 09:24:29 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1347489906; Fri, 27 Jan 2006 16:24:28 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9D50589905; Fri, 27 Jan 2006 16:24:27 +0200 (EET) Message-ID: <43DA2D36.8030604@piuha.net> Date: Fri, 27 Jan 2006 16:24:54 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93455.7020507@piuha.net> <17338.45201.524607.918065@fireball.acr.fi> <43D8D426.2040909@piuha.net> <17370.9113.717361.889944@fireball.acr.fi> In-Reply-To: <17370.9113.717361.889944@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D109 design draft issue: security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit It treats only one aspect of unreliable indications (namely, ICMP), and does not explain everything that should probably be explained, if you compare with the protocol draft. Tero Kivinen wrote: >Jari Arkko writes: > > >>Yes. Maybe you could also cut the paragraph about >>ICMP (since it isn't complete). >> >> > >What do you mean that it is not complete? > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jan 27 09:24:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UX0-0001iP-Gr for mobike-archive@megatron.ietf.org; Fri, 27 Jan 2006 09:24:54 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12408 for ; Fri, 27 Jan 2006 09:23:20 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 54C29FB292; Fri, 27 Jan 2006 09:24:51 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 765FEFB292 for ; Fri, 27 Jan 2006 09:24:48 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A5F6D89906; Fri, 27 Jan 2006 16:24:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6BFD189905; Fri, 27 Jan 2006 16:24:47 +0200 (EET) Message-ID: <43DA2D4A.1080609@piuha.net> Date: Fri, 27 Jan 2006 16:25:14 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <43A93382.2060600@piuha.net> <17338.41073.164519.184463@fireball.acr.fi> <43D8CECB.4010103@piuha.net> <17370.7872.846323.623288@fireball.acr.fi> <43DA206F.7070102@piuha.net> <17370.9614.898295.529620@fireball.acr.fi> In-Reply-To: <17370.9614.898295.529620@fireball.acr.fi> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] D103 design draft issue: terminology alignment X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Sounds good! Thanks. Tero Kivinen wrote: >Jari Arkko writes: > > >>Ah, now I see what your problem was. I still stand >>by the earlier decisions about not using the word >>path. But... the protocol document is done (approved >>by IESG) and we're not editing it anymore unless >>there's a major reason to do so. >> >>My original issue was that the protocol spec calls >>the testing function "path testing". So if we are >>specifically referring that functionality then perhaps >>we should use the same term. Otherwise lets use >>a more appropriate term. >> >>Oh well, I'm not sure this is easily fixable given no >>edits to the protocol draft. I'll let you decide what >>to do. >> >> > >I think we now use "connectivity test" in the more abstract general >text and then we do use "path test" when we talk about the exact >implementation issues on the protocol, so I do not think we have >problem here. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jan 30 15:51:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3g06-0004ec-OV for mobike-archive@megatron.ietf.org; Mon, 30 Jan 2006 15:51:50 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26520 for ; Mon, 30 Jan 2006 15:50:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 79887FB28A; Mon, 30 Jan 2006 15:50:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 8F5D1FB289 for ; Mon, 30 Jan 2006 15:50:02 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F3fyL-0007Xf-Sb; Mon, 30 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 30 Jan 2006 15:50:01 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-07.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 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-07.txt Pages : 37 Date : 2006-1-30 The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-design-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-design-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-30104827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-30104827.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Tue Jan 31 03:57:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rKK-0000t7-Ln for mobike-archive@megatron.ietf.org; Tue, 31 Jan 2006 03:57:28 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26379 for ; Tue, 31 Jan 2006 03:55:50 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F2C0DFB28F; Tue, 31 Jan 2006 03:57:16 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 412B6FB28E for ; Tue, 31 Jan 2006 03:57:14 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6543C89909; Tue, 31 Jan 2006 10:57:13 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 119A389908; Tue, 31 Jan 2006 10:57:13 +0200 (EET) Message-ID: <43DF2683.7030907@piuha.net> Date: Tue, 31 Jan 2006 10:57:39 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy References: <20060127012043.10783.qmail@web80606.mail.yahoo.com> In-Reply-To: <20060127012043.10783.qmail@web80606.mail.yahoo.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Erik Nordmark , MOBIKE Mailing List Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: >In the Introduction, > > The main scenario for MOBIKE is enabling a remote >access VPN > user to move from one address to another without > > re-establishing all security associations with the > VPN gateway. > >And in scope and limitations, > > This document focuses on the main scenario outlined >above, and > supports only tunnel mode IPsec SAs. > >This tells me that only VPN gateway is supported. > > I think so too, but maybe it should be made more explicit, if people are misunderstanding it? >In the host-to-host tunnel mode case, one can still >assume that >no two nodes (among a set of nodes) have the same >"inner" >address. Is there any problem in making such >assumptions ? > > I was thinking about that, but I'm not sure I have a foolproof method. Maybe FCFS allocation of inner addresses is one approach, but it still has some question marks. For instance, how do we know that we can deallocate an allocated address? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 31 07:41:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3upL-0007VW-ED for mobike-archive@megatron.ietf.org; Tue, 31 Jan 2006 07:41:49 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11826 for ; Tue, 31 Jan 2006 07:39:58 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 98A6DFB290; Tue, 31 Jan 2006 07:41:29 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 37C4DFB27D for ; Tue, 31 Jan 2006 07:41:27 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 406AF8990B; Tue, 31 Jan 2006 14:41:25 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ECA958990A; Tue, 31 Jan 2006 14:41:24 +0200 (EET) Message-ID: <43DF5B0F.8060905@piuha.net> Date: Tue, 31 Jan 2006 14:41:51 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <20060127012043.10783.qmail@web80606.mail.yahoo.com> In-Reply-To: <20060127012043.10783.qmail@web80606.mail.yahoo.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: MOBIKE Mailing List Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Erik, Here are some text changes that may help clarify applicability and the issues relating to the allocation of inner addresses. First a new subsection to be added to the security considerations section: 5.x. Inner Address Ownership MOBIKE ensures that the IKEv2 peer is always the same entity regardless of its changing addresses. These addresses are in the IKEv2 messages as well as outer addresses in IPsec tunnel packets. However, MOBIKE relies entirely on IKEv2 in the use of inner addresses. Typically, the same inner addresses are employed throughout the lifetime of the IKEv2 security association, i.e., MOBIKE does not modify the inner addresses. Changing the inner address would in often result in a need to re-establish existing transport layer connections, as these are often bound to specific addresses. As with IKEv2, it is necessary to ensure that peers are authorized to use the inner addresses that they negotiate when creating child SAs. The Peer Authorization Database (PAD) specified in RFC 4301 [RFC4301] allows administrators to specify what inner addresses specific IKEv2 peers have. In addition, it is necessary to ensure that the dynamic allocation of addresses through configuration payloads does not allow peers to "hijack" addresses from other nodes. And in Section 1.2 (Limitations) change: This document focuses on the main scenario outlined above, and supports only tunnel mode IPsec SAs. => This document focuses on the main scenario outlined above, and supports only tunnel mode IPsec SAs when at least one of the parties is a VPN gateway. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 31 07:48:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3uvR-0000gw-56 for mobike-archive@megatron.ietf.org; Tue, 31 Jan 2006 07:48:05 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12246 for ; Tue, 31 Jan 2006 07:46:17 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7AE51FB290; Tue, 31 Jan 2006 07:47:51 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E1185FB28E for ; Tue, 31 Jan 2006 07:47:48 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 10EFA8990B for ; Tue, 31 Jan 2006 14:47:48 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CAADE8990A for ; Tue, 31 Jan 2006 14:47:47 +0200 (EET) Message-ID: <43DF5C8E.1090306@piuha.net> Date: Tue, 31 Jan 2006 14:48:14 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Mobike] protocol draft status X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit For your information. We have received some comments during IESG review, including a Gen-ART review by Elwyn Davies and questions from Erik Nordmark (see my earlier e-mail) that resulted in one Discuss. Here are comments: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1936&filename=draft-ietf-mobike-protocol Pasi is addressing the comments and I proposed some text to answer Erik's questions -- please comment the latter on the list. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 31 09:56:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3wvm-0003Rh-4w for mobike-archive@megatron.ietf.org; Tue, 31 Jan 2006 09:56:30 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22635 for ; Tue, 31 Jan 2006 09:54:44 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E5DDBFB291; Tue, 31 Jan 2006 09:56:16 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 881EEFB290 for ; Tue, 31 Jan 2006 09:56:15 -0500 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0VEp0XQ024290; Tue, 31 Jan 2006 16:51:12 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 16:56:05 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 16:56:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2006 16:56:07 +0200 Message-ID: In-Reply-To: <43DF5B0F.8060905@piuha.net> Thread-Topic: [Mobike] does mobike support end-to-end use of tunnel mode? Thread-Index: AcYmY7weLNVVLRvbRCSn9p01vF2UvQAEMhVA From: To: , X-OriginalArrivalTime: 31 Jan 2006 14:56:04.0748 (UTC) FILETIME=[75973CC0:01C62676] Cc: mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hmm.. I think this is more a limitation of MOBIKE (and IKEv2 in general) rather than a security consideration of MOBIKE. How about adding this to Section 1.2 (Scope and Limitations)? IKEv2 relies on information in the Peer Authorization Database (PAD) when determining if the peer is authorized to create an IPsec SA with particular traffic selectors. MOBIKE does not change this part of IKEv2. This may limit the applicability of MOBIKE in host-to-host IPsec scenarios: although MOBIKE allows the peers to update the tunnel header addresses, it does not modify the child SA authorization data in the PAD. In other words, using some particular tunnel header address does not imply that the peer is authorized to create IPsec SAs with that address in the traffic selector. Best regards, Pasi > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of ext Jari Arkko > Sent: 31 January, 2006 14:42 > To: Erik Nordmark > Cc: MOBIKE Mailing List > Subject: Re: [Mobike] does mobike support end-to-end use of > tunnel mode? > > Erik, > > Here are some text changes that may help clarify applicability > and the issues relating to the allocation of inner addresses. First > a new subsection to be added to the security considerations > section: > > 5.x. Inner Address Ownership > > MOBIKE ensures that the IKEv2 peer is always the same > entity regardless of its changing addresses. These addresses > are in the IKEv2 messages as well as outer addresses in > IPsec tunnel packets. > > However, MOBIKE relies entirely on IKEv2 in the use of inner > addresses. Typically, the same inner addresses are employed > throughout the lifetime of the IKEv2 security association, i.e., > MOBIKE does not modify the inner addresses. Changing the > inner address would in often result in a need to re-establish > existing transport layer connections, as these are often > bound to specific addresses. > > As with IKEv2, it is necessary to ensure that peers are authorized > to use the inner addresses that they negotiate when creating > child SAs. The Peer Authorization Database (PAD) specified in > RFC 4301 [RFC4301] allows administrators to specify what > inner addresses specific IKEv2 peers have. In addition, it > is necessary to ensure that the dynamic allocation of addresses > through configuration payloads does not allow peers to > "hijack" addresses from other nodes. > > And in Section 1.2 (Limitations) change: > > This document focuses on the main scenario outlined above, and > supports only tunnel mode IPsec SAs. > > => > > This document focuses on the main scenario outlined above, and > supports only tunnel mode IPsec SAs when at least one of the > parties is a VPN gateway. > > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 31 20:03:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F46Ls-00035C-Oe for mobike-archive@megatron.ietf.org; Tue, 31 Jan 2006 20:00:05 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17160 for ; Tue, 31 Jan 2006 19:58:23 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 31D7AFB28E; Tue, 31 Jan 2006 19:59:53 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from web80611.mail.yahoo.com (web80611.mail.yahoo.com [66.94.235.73]) by machshav.com (Postfix) with SMTP id E323FFB28A for ; Tue, 31 Jan 2006 19:59:50 -0500 (EST) Received: (qmail 86787 invoked by uid 60001); 1 Feb 2006 00:59:48 -0000 Message-ID: <20060201005948.86785.qmail@web80611.mail.yahoo.com> Received: from [192.100.104.29] by web80611.mail.yahoo.com via HTTP; Tue, 31 Jan 2006 16:59:48 PST Date: Tue, 31 Jan 2006 16:59:48 -0800 (PST) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, jari.arkko@piuha.net, Erik.Nordmark@Sun.COM In-Reply-To: MIME-Version: 1.0 Cc: mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit --- Pasi.Eronen@nokia.com wrote: > Hmm.. I think this is more a limitation of MOBIKE > (and IKEv2 > in general) rather than a security consideration of > MOBIKE. > > How about adding this to Section 1.2 (Scope and > Limitations)? > > IKEv2 relies on information in the Peer > Authorization Database > (PAD) when determining if the peer is authorized > to create an IPsec > SA with particular traffic selectors. MOBIKE does > not change this > part of IKEv2. This may limit the applicability > of MOBIKE in > host-to-host IPsec scenarios: although MOBIKE > allows the peers to > update the tunnel header addresses, it does not > modify the child SA > authorization data in the PAD. In other words, > using some particular > tunnel header address does not imply that the > peer is authorized > to create IPsec SAs with that address in the > traffic selector. > This still does not describe the limitation. If i can assume that the PAD can be configured appropriately, then you can ensure what address a peer gets. So, there seems to be a use case where this is limiting. Can someone describe that ? -mohan > Best regards, > Pasi > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com] On Behalf Of > ext Jari Arkko > > Sent: 31 January, 2006 14:42 > > To: Erik Nordmark > > Cc: MOBIKE Mailing List > > Subject: Re: [Mobike] does mobike support > end-to-end use of > > tunnel mode? > > > > Erik, > > > > Here are some text changes that may help clarify > applicability > > and the issues relating to the allocation of inner > addresses. First > > a new subsection to be added to the security > considerations > > section: > > > > 5.x. Inner Address Ownership > > > > MOBIKE ensures that the IKEv2 peer is always the > same > > entity regardless of its changing addresses. > These addresses > > are in the IKEv2 messages as well as outer > addresses in > > IPsec tunnel packets. > > > > However, MOBIKE relies entirely on IKEv2 in the > use of inner > > addresses. Typically, the same inner addresses > are employed > > throughout the lifetime of the IKEv2 security > association, i.e., > > MOBIKE does not modify the inner addresses. > Changing the > > inner address would in often result in a need to > re-establish > > existing transport layer connections, as these > are often > > bound to specific addresses. > > > > As with IKEv2, it is necessary to ensure that > peers are authorized > > to use the inner addresses that they negotiate > when creating > > child SAs. The Peer Authorization Database (PAD) > specified in > > RFC 4301 [RFC4301] allows administrators to > specify what > > inner addresses specific IKEv2 peers have. In > addition, it > > is necessary to ensure that the dynamic > allocation of addresses > > through configuration payloads does not allow > peers to > > "hijack" addresses from other nodes. > > > > And in Section 1.2 (Limitations) change: > > > > This document focuses on the main scenario > outlined above, and > > supports only tunnel mode IPsec SAs. > > > > => > > > > This document focuses on the main scenario > outlined above, and > > supports only tunnel mode IPsec SAs when at > least one of the > > parties is a VPN gateway. > > > > --Jari > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jan 31 20:08:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F46Tz-0004fQ-AA for mobike-archive@megatron.ietf.org; Tue, 31 Jan 2006 20:08:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18101 for ; Tue, 31 Jan 2006 20:06:41 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CA028FB292; Tue, 31 Jan 2006 20:08:16 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from web80614.mail.yahoo.com (web80614.mail.yahoo.com [66.94.235.81]) by machshav.com (Postfix) with SMTP id F3081FB28E for ; Tue, 31 Jan 2006 20:08:14 -0500 (EST) Received: (qmail 89785 invoked by uid 60001); 1 Feb 2006 01:08:14 -0000 Message-ID: <20060201010814.89783.qmail@web80614.mail.yahoo.com> Received: from [192.100.104.29] by web80614.mail.yahoo.com via HTTP; Tue, 31 Jan 2006 17:08:14 PST Date: Tue, 31 Jan 2006 17:08:14 -0800 (PST) From: Mohan Parthasarathy To: Jari Arkko In-Reply-To: <43DF2683.7030907@piuha.net> MIME-Version: 1.0 Cc: Erik Nordmark , MOBIKE Mailing List Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > >In the Introduction, > > > > The main scenario for MOBIKE is enabling a > remote > >access VPN > > user to move from one address to another without > > > > > re-establishing all security associations with > the > > VPN gateway. > > > >And in scope and limitations, > > > > This document focuses on the main scenario > outlined > >above, and > > supports only tunnel mode IPsec SAs. > > > >This tells me that only VPN gateway is supported. > > > > > I think so too, but maybe it should be made more > explicit, if people are misunderstanding it? > Sure. Extra clarification is always good. > >In the host-to-host tunnel mode case, one can still > >assume that > >no two nodes (among a set of nodes) have the same > >"inner" > >address. Is there any problem in making such > >assumptions ? > > > > > I was thinking about that, but I'm not sure I have a > foolproof > method. Maybe FCFS allocation of inner addresses is > one > approach, but it still has some question marks. For > instance, > how do we know that we can deallocate an allocated > address? > Just use static addresses. Perhaps, we should understand this use case a little better. -mohan > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike