From mobike-bounces@machshav.com Sat Jul 01 08:44:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FweqE-0007Va-6f for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 08:44:54 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FweqB-0006l0-SL for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 08:44:54 -0400 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CCEFCFB2D2; Sat, 1 Jul 2006 12:44:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from h2.proserv.net.ru (h2.proserv.net.ru [72.232.195.50]) by machshav.com (Postfix) with ESMTP id 2AEC6FB2D0 for ; Sat, 1 Jul 2006 12:44:49 +0000 (UTC) Received: from nobody by h2.proserv.net.ru with local (Exim 4.52) id 1Fweq4-0003aV-49 for mobike@machshav.com; Sat, 01 Jul 2006 15:44:21 +0300 To: mobike@machshav.com MIME-Version: 1.0 From: Message-Id: Date: Sat, 01 Jul 2006 15:44:21 +0300 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - h2.proserv.net.ru X-AntiAbuse: Original Domain - machshav.com X-AntiAbuse: Originator/Caller UID/GID - [99 501] / [47 12] X-AntiAbuse: Sender Address Domain - h2.proserv.net.ru X-Source: X-Source-Args: /usr/local/apache/bin/httpd X-Source-Dir: samsa.dn.ua:/public_html/12345 Subject: [Mobike] Visit this sites! 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: multipart/mixed; boundary="===============1928456023==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f --===============1928456023== Content-type: text/html; charset=iso-8859-1 Visit http%3A%2F%2Fwww.com%2F --===============1928456023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============1928456023==-- From mobike-bounces@machshav.com Sat Jul 01 10:06:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwg6y-0007iO-R4 for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 10:06:16 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fwg6w-00024K-Fw for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 10:06:16 -0400 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 36F97FB2AC; Sat, 1 Jul 2006 14:06:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from pqc85.pqcservice.net (d2.82.5746.static.theplanet.com [70.87.130.210]) by machshav.com (Postfix) with ESMTP id 87226FB2AA for ; Sat, 1 Jul 2006 14:06:12 +0000 (UTC) Received: from nobody by pqc85.pqcservice.net with local (Exim 4.52) id 1Fwg6w-0004ne-AC for mobike@machshav.com; Sat, 01 Jul 2006 09:06:14 -0500 To: mobike@machshav.com MIME-Version: 1.0 From: Message-Id: Date: Sat, 01 Jul 2006 09:06:14 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pqc85.pqcservice.net X-AntiAbuse: Original Domain - machshav.com X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - pqc85.pqcservice.net X-Source: X-Source-Args: X-Source-Dir: Subject: [Mobike] Visit this sites! 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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Visit %3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fadipex%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fadipex%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fxanax%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fxanax%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fphentermine%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fphentermine%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fcialis%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fcialis%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fviagra%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fviagra%2F%3C%2Fa%3E _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 01 10:19:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwgJM-0005QE-FW for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 10:19:04 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwgJK-0002ko-47 for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 10:19:04 -0400 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 19D45FB2BB; Sat, 1 Jul 2006 14:19:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from pqc85.pqcservice.net (d2.82.5746.static.theplanet.com [70.87.130.210]) by machshav.com (Postfix) with ESMTP id 5439BFB2B9 for ; Sat, 1 Jul 2006 14:18:59 +0000 (UTC) Received: from nobody by pqc85.pqcservice.net with local (Exim 4.52) id 1FwgJJ-0001Va-Cd for mobike@machshav.com; Sat, 01 Jul 2006 09:19:01 -0500 To: mobike@machshav.com MIME-Version: 1.0 From: Message-Id: Date: Sat, 01 Jul 2006 09:19:01 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pqc85.pqcservice.net X-AntiAbuse: Original Domain - machshav.com X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - pqc85.pqcservice.net X-Source: X-Source-Args: X-Source-Dir: Subject: [Mobike] Visit this sites! 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 X-Spam-Score: 0.7 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Visit http://arbat.or.at/adipex/ http://arbat.or.at/xanax/ http://arbat.or.at/phentermine/ http://arbat.or.at/cialis/ http://arbat.or.at/viagra/ _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 01 10:20:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwgKZ-0005RX-O8 for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 10:20:19 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwgKY-0002sT-DA for mobike-archive@lists.ietf.org; Sat, 01 Jul 2006 10:20:19 -0400 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CAD12FB2BB; Sat, 1 Jul 2006 14:20:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from pqc85.pqcservice.net (d2.82.5746.static.theplanet.com [70.87.130.210]) by machshav.com (Postfix) with ESMTP id 420FFFB2B9 for ; Sat, 1 Jul 2006 14:20:16 +0000 (UTC) Received: from nobody by pqc85.pqcservice.net with local (Exim 4.52) id 1FwgKY-0002Gh-BQ for mobike@machshav.com; Sat, 01 Jul 2006 09:20:18 -0500 To: mobike@machshav.com MIME-Version: 1.0 From: Message-Id: Date: Sat, 01 Jul 2006 09:20:18 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pqc85.pqcservice.net X-AntiAbuse: Original Domain - machshav.com X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - pqc85.pqcservice.net X-Source: X-Source-Args: X-Source-Dir: Subject: [Mobike] Visit this sites! 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 X-Spam-Score: 0.7 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Visit http://arbat.or.at/adipex/ http://arbat.or.at/xanax/ http://arbat.or.at/phentermine/ http://arbat.or.at/cialis/ http://arbat.or.at/viagra/ _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 12 13:19:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iMg-0006cO-HN for mobike-archive@lists.ietf.org; Wed, 12 Jul 2006 13:19:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hAm-0003oQ-SL for mobike-archive@lists.ietf.org; Wed, 12 Jul 2006 12:02:48 -0400 Received: from machshav.com ([147.28.0.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0gf5-0006rh-GR for mobike-archive@lists.ietf.org; Wed, 12 Jul 2006 11:30:06 -0400 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6C72FFB2BB; Wed, 12 Jul 2006 15:29:57 +0000 (UTC) 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 ABCB5FB2AC for ; Wed, 12 Jul 2006 15:28:24 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k6CFSLBk027178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2006 18:28:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k6CFSKjM018251; Wed, 12 Jul 2006 18:28:20 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17589.5396.962491.912360@fireball.kivinen.iki.fi> Date: Wed, 12 Jul 2006 18:28:20 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Mailman-Approved-At: Wed, 12 Jul 2006 15:29:50 +0000 Cc: rfc-editor@rfc-editor.org Subject: [Mobike] Changes to draft-ietf-mobike-design-08.txt from IESG etc 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 X-Spam-Score: -2.5 (--) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e Here is list of changes to the draft-ietf-mobike-design-08.txt from the IESG etc. I think all of those are minor editorial comments that can be put into to the document during AUTH48 (or actually rfc-editor can put them in directly while editing the draft if they like). ---------------------------------------------------------------------- Change in section 3.1 (from Lisa, changed "mobile node" to "mobile node (MN)") 3.1. Mobility Scenario 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). To 3.1. Mobility Scenario Figure 1 shows a break-before-make mobility scenario where a mobile node (MN) 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). ---------------------------------------------------------------------- Change title of 5.2 (from Lisa, added "(NAT-T)") 5.2. NAT Traversal To 5.2. NAT Traversal (NAT-T) ---------------------------------------------------------------------- Change in section 1 (From Russ, changed RFC2401bis to "the Security Architecture for the Internet Protocol", Eric Gray noted same) The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As IKEv2 is built on the architecture described in RFC2401bis [RFC4301], all protocols developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC4301. This document does not discusses mobility and multi-homing support for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401 [RFC2401]. To The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As IKEv2 is built on the architecture described in the Security Architecture for the Internet Protocol [RFC4301], all protocols developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC4301. This document does not discusses mobility and multi-homing support for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401 [RFC2401]. ---------------------------------------------------------------------- Change in sectin 4 (From Russ, changed "IKE" to "IKEv2") 4. Scope of MOBIKE Getting mobility and multihoming actually working requires many different components to work together, including coordinating decisions between different layers, different mobility mechanisms, and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE: To 4. Scope of MOBIKE Getting mobility and multihoming actually working requires many different components to work together, including coordinating decisions between different layers, different mobility mechanisms, and IPsec/IKEv2. Most of those aspects are beyond the scope of MOBIKE: ---------------------------------------------------------------------- Change in section 5.1 (From Russ, changed ":" to ".") 5.1. Choosing Addresses One of the core aspects of the MOBIKE protocol is the selection of the address for the IPsec packets we send. 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, and could be forced to be the same by design). To 5.1. Choosing Addresses One of the core aspects of the MOBIKE protocol is the selection of the address for the IPsec packets we send. 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, and could be forced to be the same by design). ---------------------------------------------------------------------- Change in section 5.1.1 (from Russ, change ", e.g., Mobile IP, and" to "other mobility protocols such as Mobile IP, and they") These triggers are largely the same as for, e.g., Mobile IP, and are beyond the scope of MOBIKE. To These triggers are largely the same as for other mobility protocols such as Mobile IP, and they are beyond the scope of MOBIKE. ---------------------------------------------------------------------- Change in section 5.1.2 (from Russ, changed "address the request came from" to "address from which the request came") There can be two kinds of connectivity "failures": local failures and path failures. Local failures are problems locally at an MOBIKE peer (e.g., an interface error). Path failures are a property of an address pair and failures of nodes and links along this path. MOBIKE does not support unidirectional address pairs. Supporting them would require abandoning the principle of sending an IKEv2 reply to the address the request came from. MOBIKE decided to deal only with bidirectional address pairs. It does consider unidirectional address pairs as broken, and does not use them, but the connection between peers will not break even if unidirectional address pairs are present, provided there is at least one bidirectional address pair MOBIKE can use. To There can be two kinds of connectivity "failures": local failures and path failures. Local failures are problems locally at an MOBIKE peer (e.g., an interface error). Path failures are a property of an address pair and failures of nodes and links along this path. MOBIKE does not support unidirectional address pairs. Supporting them would require abandoning the principle of sending an IKEv2 reply to the address from which the request came. MOBIKE decided to deal only with bidirectional address pairs. It does consider unidirectional address pairs as broken, and does not use them, but the connection between peers will not break even if unidirectional address pairs are present, provided there is at least one bidirectional address pair MOBIKE can use. ---------------------------------------------------------------------- Change in section 5.2.1 (from Russ, ", i.e., if" to ". If") 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 either. To The NAT-T support should also be optional. 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 either. ---------------------------------------------------------------------- Change in section 5.2.2 (from Russ, "old" to "the old") There are some cases which cannot be carried out within MOBIKE. One of those cases is the case where the party "outside" a symmetric NAT changes its address to something not known by the the other peer (and old address has stopped working). It cannot send a packet containing the new addresses to the peer because the NAT does not contain the necessary state. Furthermore, since the party behind the NAT does not know the new IP address, it cannot cause the NAT state to be created. To: There are some cases which cannot be carried out within MOBIKE. One of those cases is the case where the party "outside" a symmetric NAT changes its address to something not known by the the other peer (and the old address has stopped working). It cannot send a packet containing the new addresses to the peer because the NAT does not contain the necessary state. Furthermore, since the party behind the NAT does not know the new IP address, it cannot cause the NAT state to be created. ---------------------------------------------------------------------- Change in section 5.2.4 (from Russ, change "where the responder can move to," to "to which the responder can move." and change "i.e. the" to "That is, the"). MOBIKE can work in cases where the responder is behind static NAT, but in that case the initiator needs to know all the possible addresses where the responder can move to, i.e. the responder cannot move to an address which is not known by the initiator, in case initiator also moves behind NAT. To MOBIKE can work in cases where the responder is behind static NAT, but in that case the initiator needs to know all the possible addresses to which the responder can move. That is, the responder cannot move to an address which is not known by the initiator, in case initiator also moves behind NAT. ---------------------------------------------------------------------- Change in section 5.2.5 (from Russ, change ", i.e. if" to ". If") One new feature created by MOBIKE is NAT prevention, i.e. if we detect NAT between the peers, we do not allow that address pair to be used. This can be used to protect IP addresses in cases where it is known by the configuration that there is no NAT between the nodes (for example IPv6, or fixed site-to-site VPN). This avoids any possibility of on-path attackers modifying addresses in headers. This feature means that we authenticate the IP-address and detect if they were changed. As this is done on purpose to break the connectivity if NAT is detected, and decided by the configuration, there is no need to do UNSAF processing. To One new feature created by MOBIKE is NAT prevention. If we detect NAT between the peers, we do not allow that address pair to be used. This can be used to protect IP addresses in cases where it is known by the configuration that there is no NAT between the nodes (for example IPv6, or fixed site-to-site VPN). This avoids any possibility of on-path attackers modifying addresses in headers. This feature means that we authenticate the IP-address and detect if they were changed. As this is done on purpose to break the connectivity if NAT is detected, and decided by the configuration, there is no need to do UNSAF processing. ---------------------------------------------------------------------- Change in section 5.4 (from Russ, change "IKE-SA" to "IKE SA" to be consistent in document) 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. To 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. ---------------------------------------------------------------------- Change in section 5.5.2 (from Russ, add comma to "On the other hand, return ...") If the return routability check fails, we need to tear down the IKE SA if we are using IKEv2 INFORMATIONAL exchanges to send return routability checks. On the other hand return routability check can only fail permanently if there was an attack by the other end, thus tearing down the IKE SA is a suitable action in that case. To If the return routability check fails, we need to tear down the IKE SA if we are using IKEv2 INFORMATIONAL exchanges to send return routability checks. On the other hand, return routability check can only fail permanently if there was an attack by the other end, thus tearing down the IKE SA is a suitable action in that case. ---------------------------------------------------------------------- Change in section 5.6 (from Russ and Brian, change "but will" to "and might be") Current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behavior would also be useful, but will be discussed in future documents. To Current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behavior would also be useful and might be be discussed in future documents. ---------------------------------------------------------------------- Change in section 6.2 (from Russ, change "packets. I.e. a" to "packets; a") Working group decided to use normal IKEv2 exchanges for path testing, and decided to change the dynamic address updating of NAT-T to MUST NOT for IKE SA packets. I.e. a new protocol outside of IKEv2 was not adopted. To Working group decided to use normal IKEv2 exchanges for path testing, and decided to change the dynamic address updating of NAT-T to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was not adopted. ---------------------------------------------------------------------- Change in section 6.3 (from Russ, change "notify, i.e. there" to "notify. There") Working group decided to use IKEv2 Notify payloads, and put only one data item per notify, i.e. there will be one Notify payload for each item to be sent. To Working group decided to use IKEv2 Notify payloads, and put only one data item per notify. There will be one Notify payload for each item to be sent. ---------------------------------------------------------------------- Change in section 6.4 (from Russ, change "IP-addresses" to "IP addresses", this same change should be done on section 5.2.5, 6.2 (2 times), and here). 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 are considered as one address of the peer, even when not present in the list. To 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 are considered as one address of the peer, even when not present in the list. ---------------------------------------------------------------------- Change in section 7 (from Russ, change "modify" to "undetectedly modify"). As all the packets are already authenticated by IKEv2 there is no risk that any attackers would modify the contents of the packets. 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. To As all the packets are already authenticated by IKEv2 there is no risk that any attackers would undetectedly modify the contents of the packets. 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. ---------------------------------------------------------------------- -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 13 10:35:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12Hq-00044C-KA for mobike-archive@lists.ietf.org; Thu, 13 Jul 2006 10:35:30 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12Ho-0006jg-99 for mobike-archive@lists.ietf.org; Thu, 13 Jul 2006 10:35:30 -0400 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 04533FB2E3; Thu, 13 Jul 2006 14:35:27 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by machshav.com (Postfix) with ESMTP id 5546EFB2E2 for ; Thu, 13 Jul 2006 14:35:25 +0000 (UTC) Received: from [132.219.13.244] (h1c52-net84db.lab.risq.net [132.219.28.82] (may be forged)) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DEZEGY027054; Thu, 13 Jul 2006 07:35:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17589.5396.962491.912360@fireball.kivinen.iki.fi> References: <17589.5396.962491.912360@fireball.kivinen.iki.fi> Date: Thu, 13 Jul 2006 10:35:38 -0400 To: Tero Kivinen , mobike@machshav.com From: Paul Hoffman Subject: Re: [Mobike] Changes to draft-ietf-mobike-design-08.txt from IESG etc 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 At 6:28 PM +0300 7/12/06, Tero Kivinen wrote: >Here is list of changes to the draft-ietf-mobike-design-08.txt from >the IESG etc. I think all of those are minor editorial comments that >can be put into to the document during AUTH48 (or actually rfc-editor >can put them in directly while editing the draft if they like). All seem minor and fine. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike