From mailman-bounces@machshav.com Thu Jul 1 01:01:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15802 for ; Thu, 1 Jul 2004 01:01:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2C634FB50A; Thu, 1 Jul 2004 01:01:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D74C4FB533 for ; Thu, 1 Jul 2004 01:00:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: machshav.com mailing list memberships reminder From: mailman-owner@machshav.com To: mobike-archive@ietf.org X-No-Archive: yes Message-ID: Date: Thu, 01 Jul 2004 05:00:15 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.4 List-Id: mailman.machshav.com X-List-Administrivia: yes Sender: mailman-bounces@machshav.com Errors-To: mailman-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your machshav.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@machshav.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@machshav.com. Thanks! Passwords for mobike-archive@lists.ietf.org: List Password // URL ---- -------- mobike@machshav.com behoef https://www.machshav.com/mailman/options.cgi/mobike/mobike-archive%40lists.ietf.org From mobike-bounces@machshav.com Fri Jul 9 02:45:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06328 for ; Fri, 9 Jul 2004 02:45:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1AC8DFB4DC; Fri, 9 Jul 2004 02:45:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6C4C3FB452; Fri, 9 Jul 2004 02:45:42 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 30F72FB4DA; Fri, 9 Jul 2004 02:45:41 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 1FA3DFB44D for ; Fri, 9 Jul 2004 02:45:40 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i696jbA18622 for ; Fri, 9 Jul 2004 09:45:38 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 09:45:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i696jIOt023124 for ; Fri, 9 Jul 2004 09:45:18 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00ddnLii; Fri, 09 Jul 2004 09:45:16 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i696jGu20306 for ; Fri, 9 Jul 2004 09:45:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 09:45:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 09:45:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2004 09:45:12 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C13A@esebe023.ntc.nokia.com> Thread-Topic: Working out the details of SA updates Thread-Index: AcRlgEi4mvu4IW0iT76One3BK+2a9w== From: To: X-OriginalArrivalTime: 09 Jul 2004 06:45:11.0979 (UTC) FILETIME=[488017B0:01C46580] Subject: [Mobike] Working out the details of SA updates X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi everyone, I've put together a new draft about a possible MOBIKE protocol. =20 This is not a revision of the SMOBIKE draft, but takes a rather=20 different approach, more resembling Francis's and Tero's drafts. A temporary copy of the draft (which will be removed when the=20 draft appears on ietf.org) is available from: http://www.vpnc.org/ietf-mobike/TEMP-draft-eronen-mobike-mopo-00.txt The main "beef" of this draft is actually working out the details=20 of how updating the various Security Associations could work. In particular, supporting window size 1 properly was somewhat tricky (and I'm not sure I got all the details right yet). The basic problem was that if you don't update any addresses before RR succeeds, and you can't send the message verifying RR=20 before there is room in the window, and existing requests cannot get out of the window before you update something, you have a=20 deadlock. Another complicated issue was that some situations require simultaneous update of both parties' addresses. For instance, if your own address changes, you also have to pick the right=20 destination address for the address update message. (And this is not the same problem that is usually handled by normal IP=20 source address selection.) This draft also makes "IP address integrity protection" (or=20 "NAT prevention") an orthogonal feature, so it can protect=20 the addresses also when the SA is created (and can be optional if NAT support is needed). Comments are most welcome! (I'm mostly out of office=20 during the next three weeks, so I won't read my emails very often. But see you in San Diego!) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 15 20:07:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20712 for ; Thu, 15 Jul 2004 20:07:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 84FCAFB4DD; Thu, 15 Jul 2004 20:07:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C1548FB4D9; Thu, 15 Jul 2004 20:07:17 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C686DFB4DA; Thu, 15 Jul 2004 20:07:16 -0400 (EDT) Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by machshav.com (Postfix) with SMTP id 43984FB44D for ; Thu, 15 Jul 2004 20:07:15 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 16 Jul 2004 00:07:14 -0000 Message-ID: <00c801c46ac8$d8c4b4f0$861167c0@adithya> From: "Mohan Parthasarathy" To: "MOBIKE Mailing List" Date: Thu, 15 Jul 2004 17:07:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [Mobike] MOBIKE with NAT X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Hi, I submitted a short draft to show how mobike can work with NAT without opening up the third party bombing attack. It does not specify a new MOBIKE protocol. Just the focus on NAT. The intent is to generate some discussion on this topic. As specified in the draft, it works in some simple scenarios. It does not claim to work in all scenarios. Comments are welcome. http://www.ietf.org/internet-drafts/draft-mohanp-mobike-nat-00.txt -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 20 12:53:10 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04674 for ; Tue, 20 Jul 2004 12:53:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4F93EFB4E0; Tue, 20 Jul 2004 12:53:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EDB24FB452; Tue, 20 Jul 2004 12:53:10 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DC377FB4DB; Tue, 20 Jul 2004 12:53:08 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 893F6FB452 for ; Tue, 20 Jul 2004 12:53:08 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGr3ev055769 for ; Tue, 20 Jul 2004 09:53:04 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 20 Jul 2004 09:50:46 -0700 To: mobike@machshav.com From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Mobike] Agenda for MOBIKE at the IETF in San Diego X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Greetings again. We are scheduled for 2.5 hours on Monday night. Our agenda is quite open, with draft-ietf-mobike-design being the main topic of conversation. There certainly is plenty there to fill up the time with. Do people here think there is value to again having presentations on the protocol proposals, or should we just focus on the design document? Are there other topics that we should be discussing at the face-to-face meeting? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 21 09:33:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16832 for ; Wed, 21 Jul 2004 09:33:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1C617FB4DF; Wed, 21 Jul 2004 09:33:05 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A50DAFB44D; Wed, 21 Jul 2004 09:33:04 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 45E67FB4D9; Wed, 21 Jul 2004 09:33:03 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 11F14FB44D for ; Wed, 21 Jul 2004 09:33:02 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LDWvv04245; Wed, 21 Jul 2004 16:32:57 +0300 (EET DST) X-Scanned: Wed, 21 Jul 2004 16:31:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6LDVOaZ007809; Wed, 21 Jul 2004 16:31:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 008IKCaP; Wed, 21 Jul 2004 16:31:23 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LDVLn29302; Wed, 21 Jul 2004 16:31:21 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Jul 2004 16:31:20 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Mobike] Agenda for MOBIKE at the IETF in San Diego Date: Wed, 21 Jul 2004 16:31:18 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C143@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] Agenda for MOBIKE at the IETF in San Diego Thread-Index: AcRueiFzFJkh8rz/Q1OeJx/giKVhYQAqdoAg From: To: , X-OriginalArrivalTime: 21 Jul 2004 13:31:20.0416 (UTC) FILETIME=[022D7E00:01C46F27] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Paul Hoffman wrote: >=20 > Greetings again. We are scheduled for 2.5 hours on Monday night. Our=20 > agenda is quite open, with draft-ietf-mobike-design being the main=20 > topic of conversation. There certainly is plenty there to fill up the=20 > time with. >=20 > Do people here think there is value to again having presentations on=20 > the protocol proposals, or should we just focus on the design=20 > document? >=20 > Are there other topics that we should be discussing at the=20 > face-to-face meeting? I think it would be beneficial to discuss the protocol proposals=20 as well, and what approaches they take to the various issues discussed in the design document. BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 27 13:20:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00192 for ; Tue, 27 Jul 2004 13:20:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 910A8FB4DB; Tue, 27 Jul 2004 13:20:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ACC6FFB4D7; Tue, 27 Jul 2004 13:20:09 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A57E0FB4D9; Tue, 27 Jul 2004 13:20:07 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 153ADFB452 for ; Tue, 27 Jul 2004 13:20:07 -0400 (EDT) Message-ID: <010201c473fe$124ab5b0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "MOBIKE Mailing List" Date: Tue, 27 Jul 2004 10:20:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Mobike] Protocol Drafts - What's different. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I read through the protocol drafts and I can't see much difference in the technical content. Would the authors like to articulate what the differences are? jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 27 22:20:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28707 for ; Tue, 27 Jul 2004 22:20:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1841CFB4DB; Tue, 27 Jul 2004 22:20:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B3198FB4D7; Tue, 27 Jul 2004 22:20:19 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 10BE5FB4D9; Tue, 27 Jul 2004 22:20:18 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 9C195FB452 for ; Tue, 27 Jul 2004 22:20:17 -0400 (EDT) Received: from [165.121.169.136] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S2K9cS006030 for ; Tue, 27 Jul 2004 19:20:10 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 27 Jul 2004 19:16:57 -0700 To: mobike@machshav.com From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Mobike] Agenda for San Diego X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Greetings again. We will be meeting next week on Monday night at 1930. The agenda (as best as we know) is: - Agenda bashing (short) - draft-ietf-mobike-design (long) - Proposals for protocols (informal) - Revision of our milestones (mandatory) Before Monday, please be sure to read the design draft , which is also linked from the main WG page at . Active discussion will be appreciated. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 28 04:18:21 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13328 for ; Wed, 28 Jul 2004 04:18:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6FC5FFB4E1; Wed, 28 Jul 2004 04:18:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A4DEDFB4DA; Wed, 28 Jul 2004 04:18:16 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0182FFB4DB; Wed, 28 Jul 2004 04:18:11 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 69928FB4D9 for ; Wed, 28 Jul 2004 04:18:07 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i6S8I0N32627; Wed, 28 Jul 2004 10:18:00 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i6S8HxSj079435; Wed, 28 Jul 2004 10:18:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200407280818.i6S8HxSj079435@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mobike] Protocol Drafts - What's different. In-reply-to: Your message of Tue, 27 Jul 2004 10:20:51 PDT. <010201c473fe$124ab5b0$536115ac@dcml.docomolabsusa.com> Date: Wed, 28 Jul 2004 10:17:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I read through the protocol drafts and I can't see much difference in the technical content. Would the authors like to articulate what the differences are? => a way should be to write a draft with the common part, shouldn't it? 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 Jul 28 07:17:46 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21786 for ; Wed, 28 Jul 2004 07:17:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3B57DFB4D9; Wed, 28 Jul 2004 07:17:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86309FB4DB; Wed, 28 Jul 2004 07:17:39 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D772BFB4DA; Wed, 28 Jul 2004 07:17:37 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 0CE80FB4D8 for ; Wed, 28 Jul 2004 07:17:37 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i6SBHVqO024628; Wed, 28 Jul 2004 13:17:32 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i6SBHV6j005237; Wed, 28 Jul 2004 13:17:31 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <3SSX54QJ>; Wed, 28 Jul 2004 13:17:30 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686480@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'James Kempf'" Subject: RE: [Mobike] Protocol Drafts - What's different. Date: Wed, 28 Jul 2004 13:16:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com hi james, with we tried to raise the need for a nat traversal support. during the last ietf meeting we noticed that other people have a different view about this issue. ciao hannes > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, July 27, 2004 7:21 PM > To: MOBIKE Mailing List > Subject: [Mobike] Protocol Drafts - What's different. > > I read through the protocol drafts and I can't see much > difference in the technical content. Would the authors like > to articulate what the differences are? > > jak > > > _______________________________________________ > 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 Jul 28 11:58:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09541 for ; Wed, 28 Jul 2004 11:58:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 34256FB4DB; Wed, 28 Jul 2004 11:58:51 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3FF7DFB4D9; Wed, 28 Jul 2004 11:58:50 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BB6D3FB4DA; Wed, 28 Jul 2004 11:58:48 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id A13D2FB4D8 for ; Wed, 28 Jul 2004 11:58:47 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6SFwj024163; Wed, 28 Jul 2004 18:58:45 +0300 (EET DST) X-Scanned: Wed, 28 Jul 2004 18:58:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6SFw760016419; Wed, 28 Jul 2004 18:58:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00POJJAb; Wed, 28 Jul 2004 18:58:06 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6SFw6u18916; Wed, 28 Jul 2004 18:58:06 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Jul 2004 18:58:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Protocol Drafts - What's different. Date: Wed, 28 Jul 2004 18:58:06 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C144@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] Protocol Drafts - What's different. Thread-Index: AcR0DbFnOgiUA2OPSVm0HYgBSPBD0wAqp5mQ From: To: , X-OriginalArrivalTime: 28 Jul 2004 15:58:06.0919 (UTC) FILETIME=[AC277570:01C474BB] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable James Kempf wrote: >=20 > I read through the protocol drafts and I can't see much=20 > difference in the technical content. Would the authors like=20 > to articulate what the differences are? I hope this kind of stuff will be included in protocol presentations at San Diego. But here's a short list of some differences (which is sort of biased, and probably=20 contains several errors due to my misunderstanding of=20 various protocol details). Window size requirements =20 mopo-ike, smobike: Work with window size 1, even if something=20 else, such as an information exchange for dead peer detection=20 or rekeying a child SA was going on when mobility occured. addrmgmt: Probably does not work with window size 1, since=20 return routability is verified using a separate informational=20 exchange before updating SAs. mobike-protocol: Seems to work with window size 1, since the informational exchange to verify return routability is done=20 after the SAs have been updated. NAT behavior mopo-ike: Works in many situations: moving behind NAT enables=20 NAT traversal (UDP encapsulation, automatic address updates=20 and keepalives) and moving back to clear disables them. smobike: Works in many sitations, but differently. Moving=20 behind NAT enables UDP encapsulation and keepalives; moving=20 back disables them. Automatic address updates are always used. mobike-protocol, addrmgmt: Do not work with NATs. When A changes its address, and B has several addresses: =20 addrmgmt: Seems to assume that B's address stays the same? mopo-ike: Provides a way to find out which of B's addresses=20 work with the new address of A. mobike-protocol, smobike: Seem to assume that A already knows=20 which of B's addresses is the right one to use? =20 If there is no response to an IKE request, and both parties have several addresses (so it is not clear which end is having problems): mopo-ike: Provides a way for the parties to locate the problem. addrmgmt, smobike: Seem to assume the information is obtained=20 in some other, unspecified way? mobike-protocol: There is some support for testing addresses, but it cannot always locate the problem without additional information obtained in some unspecified way? Scope of address updates: mopo-ike/smobike/mobike-protocol: All child SAs are updated=20 at the same time.=20 addrmgmt: Updating individual child SAs is possible. (In some cases, it is not totally clear to me what the situation is, since the drafts are not very detailed --- but that's quite=20 understandable, since most of them are -00 versions.) Cheers, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 29 04:51:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27280 for ; Thu, 29 Jul 2004 04:51:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AD2D7FB4D9; Thu, 29 Jul 2004 04:51:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C4CD6FB4D7; Thu, 29 Jul 2004 04:51:49 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 25C3CFB4D8; Thu, 29 Jul 2004 04:51:47 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id A64C5FB452 for ; Thu, 29 Jul 2004 04:51:45 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i6T8pef14748; Thu, 29 Jul 2004 10:51:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i6T8pcSj086005; Thu, 29 Jul 2004 10:51:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200407290851.i6T8pcSj086005@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Protocol Drafts - What's different. In-reply-to: Your message of Wed, 28 Jul 2004 18:58:06 +0300. <052E0C61B69C3741AFA5FE88ACC775A60227C144@esebe023.ntc.nokia.com> Date: Thu, 29 Jul 2004 10:51:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: kempf@docomolabs-usa.com, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: Window size requirements => if you speak about the IKE message window, there are two windows, one for each way (i.e., one for each peer as the initiator of the exchange). Without two windows simultaneous exchanges could give deadlocks and/or spurious retransmissions. addrmgmt: Probably does not work with window size 1, since return routability is verified using a separate informational exchange before updating SAs. => the optional RR check uses the other way... NAT behavior mobike-protocol, addrmgmt: Do not work with NATs. => and nothing will be done to change this if the WG still believes interoperability with NATs is not useful. When A changes its address, and B has several addresses: addrmgmt: Seems to assume that B's address stays the same? => the answer is simple: B is supposed to manage its addresses. Note that the addrmgmt provides a way for A to change the B address too but it is not the standard way. If there is no response to an IKE request, and both parties have several addresses (so it is not clear which end is having problems): addrmgmt, smobike: Seem to assume the information is obtained in some other, unspecified way? => yes, this is supposed to be done by the generic mobility/multi-homing/etc control mechanism. Scope of address updates: addrmgmt: Updating individual child SAs is possible. => IMHO this is the main difference: the idea is to manage all the IPsec SAs between two multi-homed peers using different peer addresses from one IKE SA. 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 Thu Jul 29 12:45:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23988 for ; Thu, 29 Jul 2004 12:45:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C93C5FB4DA; Thu, 29 Jul 2004 12:45:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 05969FB4D7; Thu, 29 Jul 2004 12:45:17 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5CF42FB4D8; Thu, 29 Jul 2004 12:45:15 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id B035BFB452 for ; Thu, 29 Jul 2004 12:45:14 -0400 (EDT) Message-ID: <003101c4758b$87cf7300$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Francis Dupont" , References: <200407290851.i6T8pcSj086005@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Protocol Drafts - What's different. Date: Thu, 29 Jul 2004 09:45:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > mobike-protocol, addrmgmt: Do not work with NATs. > > => and nothing will be done to change this if the WG still believes > interoperability with NATs is not useful. > Is that really what the WG believes? Given that the base IKEv2 protocol includes NAT support, it seems a little strange to exclude it in MOBIKE. (Please, no comments about the immorality of NATs. Living in America, I have to suffer enough of that kind of stuff from the current USG.). > Scope of address updates: > > addrmgmt: Updating individual child SAs is possible. > > => IMHO this is the main difference: the idea is to manage all the IPsec > SAs between two multi-homed peers using different peer addresses from > one IKE SA. > Actually, I like this. It might be very useful for multihoming. The only issue is if updating individual child SAs is always necessary, or if they can be updated en masse. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 29 13:43:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27536 for ; Thu, 29 Jul 2004 13:43:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 81367FB4DA; Thu, 29 Jul 2004 13:43:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AF7D5FB4D7; Thu, 29 Jul 2004 13:43:33 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5750AFB4D8; Thu, 29 Jul 2004 13:43:31 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id CBDFEFB452 for ; Thu, 29 Jul 2004 13:43:30 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 75D4489841; Thu, 29 Jul 2004 20:43:28 +0300 (EEST) Message-ID: <410935F6.9010108@piuha.net> Date: Thu, 29 Jul 2004 20:37:58 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobike] Protocol Drafts - What's different. References: <200407290851.i6T8pcSj086005@givry.rennes.enst-bretagne.fr> <003101c4758b$87cf7300$536115ac@dcml.docomolabsusa.com> In-Reply-To: <003101c4758b$87cf7300$536115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit James Kempf wrote: >> mobike-protocol, addrmgmt: Do not work with NATs. >> >>=> and nothing will be done to change this if the WG still believes >>interoperability with NATs is not useful. >> > > > Is that really what the WG believes? Given that the base IKEv2 protocol > includes NAT support, it seems a little strange to exclude it in MOBIKE. > (Please, no comments about the immorality of NATs. Living in America, I have > to suffer enough of that kind of stuff from the current USG.). Francis said "_if_ the WG still believes". Anyway, I think our meeting in Seoul plus discussions on the list seem to say that people *do* care about NATs. But the issue may be more about what we can do than what we want to do. I'm not sure we fully understand the interaction between mobike and nat-t yet. Or at least I do not personally feel that understand it well enough. I hope that Tero and Francis can talk about this in the meeting. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 29 15:24:35 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03843 for ; Thu, 29 Jul 2004 15:24:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F027AFB4D7; Thu, 29 Jul 2004 15:24:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2BEFCFB4D7; Thu, 29 Jul 2004 15:24:35 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 07110FB4D8; Thu, 29 Jul 2004 15:24:33 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id AFE02FB452 for ; Thu, 29 Jul 2004 15:24:32 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJOHv8091344; Thu, 29 Jul 2004 12:24:18 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <410935F6.9010108@piuha.net> References: <200407290851.i6T8pcSj086005@givry.rennes.enst-bretagne.fr> <003101c4758b$87cf7300$536115ac@dcml.docomolabsusa.com> <410935F6.9010108@piuha.net> Date: Thu, 29 Jul 2004 12:24:21 -0700 To: jari.arkko@piuha.net, James Kempf From: Paul Hoffman / VPNC Subject: Re: [Mobike] Protocol Drafts - What's different. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, Francis Dupont X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com At 8:37 PM +0300 7/29/04, Jari Arkko wrote: >Anyway, I think our meeting in Seoul plus discussions on >the list seem to say that people *do* care about NATs. Agree. >But the issue may be more about what we can do than what we >want to do. I'm not sure we fully understand the interaction >between mobike and nat-t yet. Agree. > Or at least I do not personally >feel that understand it well enough. I hope that Tero and >Francis can talk about this in the meeting. That would be great. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 31 03:15:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12186 for ; Sat, 31 Jul 2004 03:15:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4206AFB4DA; Sat, 31 Jul 2004 03:15:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1E3E5FB4D7; Sat, 31 Jul 2004 03:15:15 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 93B6AFB4D8; Sat, 31 Jul 2004 03:15:13 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id D2D7AFB44D for ; Sat, 31 Jul 2004 03:15:12 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7586A89846; Sat, 31 Jul 2004 10:15:10 +0300 (EEST) Message-ID: <410B45B1.90109@piuha.net> Date: Sat, 31 Jul 2004 10:09:37 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy References: <200407151921.PAA16270@ietf.org> In-Reply-To: <200407151921.PAA16270@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List Subject: [Mobike] Comments on draft-mohanp-mobike-nat-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan, Thank you for this draft! It does show one simple way of authenticating NAT-based addresses. A couple of comments and/or questions: > The solution described in this document may not work with all NAT > devices. It assumes that Network address Port Translation (NAPT) is > used by the NAT device. It also does not work with multiple NAPT > devices in the path. The solution is mainly targeted for SOHO type > environments where there is a NAPT with public address on one side > and a DHCP server to allocate private addresses on the other side. We have to discuss how big this limitation is. A NAT at the ISP and another NAT at the home WLAN/router/firewall box is a common configuration. OTOH, it seems that your solution *could* work even across multiple NAPT devices, as long as the host can learn the true public IP address. For instance, if my ISP sends a DHCP option to my home box about the public IP address, then my home box can do NAT and send this same option to the hosts in my home network. > 4.0 DHCP option > > This option is used to indicate the presence of NAT in the network by > including the public address of the NAT. The option SHOULD be > included by the DHCP server in the DHCPACK packet if there is a NAT > present in the network and the public address of the NAT is known. > The format of the option is as follows. I wonder if there's a chicken and egg problem here. Remember that we started from wanting to authenticate addresses, including those inserted by NATs. Now, the only simple way I see the DHCP server can know the address is that it is in the same box as the NAT is. This means that you'll be trusting the information from the NAT box, through DHCP. But the NAT could still lie. Of course, this does help in the sense that now only your home NAT box can lie about your address, not anyone else on the path. > 5) The peer on receiving the MOBIKE address update packet verifies > that the public address in the payload matches the address on > the IP header. If not, it drops the packet as it implies that Besides DHCP, you could use also other local information to ensure that rogue "NATs" do not change your addresses. For instance, you could dynamically discover the IP address after a movement, but not accept any new public addresses later unless you move. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 31 19:09:10 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21472 for ; Sat, 31 Jul 2004 19:09:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7CF8DFB4DA; Sat, 31 Jul 2004 19:09:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BAD0AFB4D7; Sat, 31 Jul 2004 19:09:11 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 48634FB4D8; Sat, 31 Jul 2004 19:09:10 -0400 (EDT) Received: from smtp810.mail.sc5.yahoo.com (smtp810.mail.sc5.yahoo.com [66.163.170.80]) by machshav.com (Postfix) with SMTP id BD9B7FB44D for ; Sat, 31 Jul 2004 19:09:09 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.160.95 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 31 Jul 2004 23:09:09 -0000 Message-ID: <004f01c47753$61d079a0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: References: <200407151921.PAA16270@ietf.org> <410B45B1.90109@piuha.net> Subject: Re: [Mobike] Comments on draft-mohanp-mobike-nat-00.txt Date: Sat, 31 Jul 2004 16:09:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari, Thanks for your comments. My comments in-line... > > Thank you for this draft! It does show one simple way > of authenticating NAT-based addresses. > > A couple of comments and/or questions: > > > The solution described in this document may not work with all NAT > > devices. It assumes that Network address Port Translation (NAPT) is > > used by the NAT device. It also does not work with multiple NAPT > > devices in the path. The solution is mainly targeted for SOHO type > > environments where there is a NAPT with public address on one side > > and a DHCP server to allocate private addresses on the other side. > > We have to discuss how big this limitation is. A NAT at the > ISP and another NAT at the home WLAN/router/firewall box > is a common configuration. > Agreed. But there may be other mechanisms to learn the NAT bindings. For example, there might be other applications on the node that uses STUN to learn the NAT bindings. One could potentially learn the NAT binding and use it across all applications including IKE. STUN does provide some security, but we need to understand it a bit more. If someone can forge the address during this process, then we can't prevent the 3rd party bombing attack. Also, this might introduce additional latency. Perhaps, still better than re-negotiating a new SA. > OTOH, it seems that your solution *could* work even across > multiple NAPT devices, as long as the host can learn the > true public IP address. For instance, if my ISP sends a > DHCP option to my home box about the public IP address, then > my home box can do NAT and send this same option to the hosts > in my home network. > Yes. That should be possible. I was too biased about the setup i have at home :-) > > 4.0 DHCP option > > > > This option is used to indicate the presence of NAT in the network by > > including the public address of the NAT. The option SHOULD be > > included by the DHCP server in the DHCPACK packet if there is a NAT > > present in the network and the public address of the NAT is known. > > The format of the option is as follows. > > I wonder if there's a chicken and egg problem here. Remember that > we started from wanting to authenticate addresses, including those > inserted by NATs. Now, the only simple way I see the DHCP server > can know the address is that it is in the same box as the NAT is. > Agreed. We should still try to explore other ways as i described above. > This means that you'll be trusting the information from the NAT > box, through DHCP. But the NAT could still lie. > > Of course, this does help in the sense that now only your home > NAT box can lie about your address, not anyone else on the path. > Yes, the whole thing hinges on how securely you can learn the address to begin with. > > 5) The peer on receiving the MOBIKE address update packet verifies > > that the public address in the payload matches the address on > > the IP header. If not, it drops the packet as it implies that > > Besides DHCP, you could use also other local information to > ensure that rogue "NATs" do not change your addresses. For instance, > you could dynamically discover the IP address after a movement, > but not accept any new public addresses later unless you move. > Yes, that should add some robustness. Thanks 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