From mailman-bounces@machshav.com Wed Sep 1 01:02:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06542 for ; Wed, 1 Sep 2004 01:02:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 44C2FFB4EA; Wed, 1 Sep 2004 01:02:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CB418FB574 for ; Wed, 1 Sep 2004 01:01:17 -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: Wed, 01 Sep 2004 05:00:09 +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 Thu Sep 2 14:24:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25680 for ; Thu, 2 Sep 2004 14:24:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 96DEEFB453; Thu, 2 Sep 2004 14:24:38 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7AC49FB44F; Thu, 2 Sep 2004 14:24:37 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4EF08FB451; Thu, 2 Sep 2004 14:24:36 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 3E469FB44C for ; Thu, 2 Sep 2004 14:24:35 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i82IOXT22960 for ; Thu, 2 Sep 2004 21:24:33 +0300 (EET DST) X-Scanned: Thu, 2 Sep 2004 21:23:46 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i82INkPr011580 for ; Thu, 2 Sep 2004 21:23:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00aqkfko; Thu, 02 Sep 2004 21:23:44 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i82INhS26413 for ; Thu, 2 Sep 2004 21:23:44 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Sep 2004 13:23:34 -0500 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] New issue 18: Threat discussion Date: Thu, 2 Sep 2004 14:23:32 -0400 Message-ID: Thread-Topic: New issue 18: Threat discussion Thread-Index: AcSJ7zrp+ll6ZMdeRvOy1D8v0YYq7wHKYZ2g From: To: , X-OriginalArrivalTime: 02 Sep 2004 18:23:34.0770 (UTC) FILETIME=[F53AD520:01C49119] 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 Pasi, Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack? The problem is of general nature, and will impact IP, IPsec traffic as much as (MOB)IKE traffic.=20 Any solution to this attack has to be of general nature rather than MOBIKE-specific solution just working for MOBIKE. Just trying to understand.... Best, Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext=20 > Sent: Tuesday, August 24, 2004 11:30 AM > To: mobike@machshav.com > Subject: [Mobike] New issue 18: Threat discussion >=20 >=20 > At the San Diego meeting I promised to create a new issue > about the various threats the protocol should consider. >=20 > So far, we have at least the following (notation: the IKE > peers are A and B; C is an innocent victim). >=20 > 1) Unauthenticated attacker directs the traffic stream > from B to a third party C, with the intent flooding C > with unwanted traffic. >=20 > 2) Authenticated peer A directs the traffic stream from B > to a third party C, with the intent of flooding C with > unwanted traffic. >=20 > 3) Unauthenticated attacker directs the traffic stream > from B to somewhere (perhaps to the attacker or /dev/null),=20 > with the intent of preventing the legitimate peers from=20 > communicating. >=20 > 4) Unauthenticated attacker causes the IKE_SA to be > closed by modifying just one or two IKE packets (if > attacker can modify all packets, he can of course DoS). >=20 > Do we have any other threats, assuming we don't need to=20 > repeat those where MOBIKE doesn't change anything in > normal IKEv2? Should we add some discussion about these=20 > to the design document and/or protocol proposals? >=20 > (BTW, a comment about terminology: Francis has quite > consistently called case 1 "transient pseudo-NAT attack"=20 > and case 2 "third party bombing". I (and several others)=20 > have sometimes called both 1 and 2 third party bombing.) >=20 > Cheers, > Pasi > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 2 14:56:37 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27664 for ; Thu, 2 Sep 2004 14:56:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3A07BFB459; Thu, 2 Sep 2004 14:56:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ADE28FB44F; Thu, 2 Sep 2004 14:56:32 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3CF43FB451; Thu, 2 Sep 2004 14:56:31 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 1CCC5FB44C for ; Thu, 2 Sep 2004 14:56:30 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i82IuSj08273 for ; Thu, 2 Sep 2004 21:56:28 +0300 (EET DST) X-Scanned: Thu, 2 Sep 2004 21:54:45 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i82IsjqZ024229 for ; Thu, 2 Sep 2004 21:54:45 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00nWqKf3; Thu, 02 Sep 2004 21:54:44 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i82IsiS05776 for ; Thu, 2 Sep 2004 21:54:44 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Sep 2004 13:54:16 -0500 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] New issue 18: Threat discussion Date: Thu, 2 Sep 2004 14:54:14 -0400 Message-ID: Thread-Topic: New issue 18: Threat discussion Thread-Index: AcSJ7zrp+ll6ZMdeRvOy1D8v0YYq7wHKYZ2gAAEEMOA= From: To: , , X-OriginalArrivalTime: 02 Sep 2004 18:54:16.0589 (UTC) FILETIME=[3F0A1BD0:01C4911E] 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 Actually, let me rephrase: I do not want to imply that "transient pseudo-NAT" attack has no=20 relevance for MOBIKE. MOBIKE is all about authenticated management of (change of) address. And "pseudo-NAT" is about malicious change of address.=20 So there is definite relevance there. The issue is that problem can be manifested in several scenarios=20 other than just IKE. It may make sense to either do a general solution (else where?) or if we do MOBIKE-specific solution, we should let other affected working groups be made aware of it. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext=20 > Sent: Thursday, September 02, 2004 2:24 PM > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: RE: [Mobike] New issue 18: Threat discussion >=20 >=20 >=20 > Hi Pasi, >=20 > Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack? > The problem is of general nature, and will impact IP, IPsec traffic > as much as (MOB)IKE traffic.=20 >=20 > Any solution to this attack has to be of general nature rather than > MOBIKE-specific solution just working for MOBIKE. >=20 > Just trying to understand.... >=20 > Best, > Atul >=20 >=20 > > -----Original Message----- > > From: mobike-bounces@machshav.com=20 > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext=20 > > Sent: Tuesday, August 24, 2004 11:30 AM > > To: mobike@machshav.com > > Subject: [Mobike] New issue 18: Threat discussion > >=20 > >=20 > > At the San Diego meeting I promised to create a new issue > > about the various threats the protocol should consider. > >=20 > > So far, we have at least the following (notation: the IKE > > peers are A and B; C is an innocent victim). > >=20 > > 1) Unauthenticated attacker directs the traffic stream > > from B to a third party C, with the intent flooding C > > with unwanted traffic. > >=20 > > 2) Authenticated peer A directs the traffic stream from B > > to a third party C, with the intent of flooding C with > > unwanted traffic. > >=20 > > 3) Unauthenticated attacker directs the traffic stream > > from B to somewhere (perhaps to the attacker or /dev/null),=20 > > with the intent of preventing the legitimate peers from=20 > > communicating. > >=20 > > 4) Unauthenticated attacker causes the IKE_SA to be > > closed by modifying just one or two IKE packets (if > > attacker can modify all packets, he can of course DoS). > >=20 > > Do we have any other threats, assuming we don't need to=20 > > repeat those where MOBIKE doesn't change anything in > > normal IKEv2? Should we add some discussion about these=20 > > to the design document and/or protocol proposals? > >=20 > > (BTW, a comment about terminology: Francis has quite > > consistently called case 1 "transient pseudo-NAT attack"=20 > > and case 2 "third party bombing". I (and several others)=20 > > have sometimes called both 1 and 2 third party bombing.) > >=20 > > Cheers, > > Pasi > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 2 20:05:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24718 for ; Thu, 2 Sep 2004 20:05:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 78DFAFB451; Thu, 2 Sep 2004 20:05:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B89CBFB44F; Thu, 2 Sep 2004 20:05:39 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 489FAFB451; Thu, 2 Sep 2004 20:05:38 -0400 (EDT) Received: from smtp802.mail.sc5.yahoo.com (smtp802.mail.sc5.yahoo.com [66.163.168.181]) by machshav.com (Postfix) with SMTP id AEFFCFB44C for ; Thu, 2 Sep 2004 20:05:37 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 3 Sep 2004 00:05:37 -0000 Message-ID: <01a101c49149$bda565f0$861167c0@adithya> From: "Mohan Parthasarathy" To: , References: <052E0C61B69C3741AFA5FE88ACC775A6010C3C10@esebe023.ntc.nokia.com> Subject: Re: [Mobike] New issue 18: Threat discussion Date: Thu, 2 Sep 2004 17:05:36 -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 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 Pasi, Couple of questions ---------------------------------- At the San Diego meeting I promised to create a new issue about the various threats the protocol should consider. So far, we have at least the following (notation: the IKE peers are A and B; C is an innocent victim). 1) Unauthenticated attacker directs the traffic stream from B to a third party C, with the intent flooding C with unwanted traffic. mohanp> Is this attack where the unauthenticated attacker is modifying mohanp> the packets of the authenticated client or doing the attack mohanp> independently ? 2) Authenticated peer A directs the traffic stream from B to a third party C, with the intent of flooding C with unwanted traffic. 3) Unauthenticated attacker directs the traffic stream from B to somewhere (perhaps to the attacker or /dev/null), with the intent of preventing the legitimate peers from communicating. mohanp> Why is this different from (1) ? 4) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). Do we have any other threats, assuming we don't need to repeat those where MOBIKE doesn't change anything in normal IKEv2? Should we add some discussion about these to the design document and/or protocol proposals? (BTW, a comment about terminology: Francis has quite consistently called case 1 "transient pseudo-NAT attack" and case 2 "third party bombing". I (and several others) have sometimes called both 1 and 2 third party bombing.) Cheers, Pasi -mohanp _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 2 20:14:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25292 for ; Thu, 2 Sep 2004 20:14:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E9525FB458; Thu, 2 Sep 2004 20:14:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BA051FB44F; Thu, 2 Sep 2004 20:14:29 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2981EFB451; Thu, 2 Sep 2004 20:14:28 -0400 (EDT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by machshav.com (Postfix) with SMTP id 802DAFB44C for ; Thu, 2 Sep 2004 20:14:27 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 3 Sep 2004 00:14:27 -0000 Message-ID: <01ab01c4914a$f99670d0$861167c0@adithya> From: "Mohan Parthasarathy" To: , References: <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> Subject: Re: [Mobike] New issue 17: Full connectivity Date: Thu, 2 Sep 2004 17:14:27 -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 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 Pasi, I might have missed this at San Deigo. Why would anybody assume about the connectivity about the address i.e why is this question even coming up ? If both the peers have multiple address, then you have to support address list and can't make any assumptions about the connectivity. You said below that if we don't make the assumption, then both address can change at the same time on the SAs. Perhaps, i am missing the "assumption" part. Assuming something is fully connected at some point in time does not mean that it stays that way forever. So, even if we make the assumption, both the address may change at the same time, right ? What am i missing ? -mohan ----- Original Message ----- From: To: Sent: Tuesday, August 24, 2004 8:10 AM Subject: [Mobike] New issue 17: Full connectivity Hi, Based on talks at San Diego, I've created a new issue on the issue tracker: "If both parties have several addresses, do we assume that all pairs have connectivity between them?" There was discussion about this in mid-April (one example mentioned was two SGWs connected via two different private networks), and most people thought we should not assume this. Assuming this would also seem to largely rule out IPv4/v6 mobility. If we decide _not_ to make this assumption, then we have cases where we have to change both parties's addresses in SAs at the same time. It also seems the protocol will require some kind of address lists, so something like SMOBIKE won't work (unless we assume one party knows several addresses for the other party via some other means than address lists sent within the protocol). Any comments? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 3 08:40:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24620 for ; Fri, 3 Sep 2004 08:40:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0E77EFB459; Fri, 3 Sep 2004 08:40:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D551AFB451; Fri, 3 Sep 2004 08:40:45 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 38719FB455; Fri, 3 Sep 2004 08:40:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 16612FB44C for ; Fri, 3 Sep 2004 08:40:43 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83Cefj18402; Fri, 3 Sep 2004 15:40:41 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 15:38:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i83Ccdtc028888; Fri, 3 Sep 2004 15:38:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00CSLXY9; Fri, 03 Sep 2004 15:38:37 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83CcbS08278; Fri, 3 Sep 2004 15:38:37 +0300 (EET DST) Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 15:38:38 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 15:38:36 +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] New issue 17: Full connectivity Date: Fri, 3 Sep 2004 15:38:36 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FC8E@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 17: Full connectivity Thread-Index: AcSRSwodPuQNmdK8Sm+dKzDbMcyp2wAZ4NNA From: To: , X-OriginalArrivalTime: 03 Sep 2004 12:38:36.0762 (UTC) FILETIME=[EEAB33A0:01C491B2] 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, Yes, I certainly agree that we should not assume this. I brought this=20 up because at some point, Francis was suggesting that each end=20 should be responsible for only changing its own address=20 (e.g. 2004-07-29), but probably I misunderstood him here. This question also has an important relationship to issue 16: in=20 general, it may be difficult to tell the difference between lack of=20 full connectivity and a failure somewhere in the middle of the=20 network (and usually there is even no need to tell the difference). So the answers to these issues are related: if we handle the lack=20 of full connectivity properly, we most likely have everything needed=20 to recover from problems that can only be detected by end-to-end=20 messages (e.g., failure in the "middle of the network"); and vice versa. Best regards, Pasi > -----Original Message----- > From: Mohan Parthasarathy > Sent: Friday, September 03, 2004 3:14 AM > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: Re: [Mobike] New issue 17: Full connectivity >=20 > Pasi, >=20 > I might have missed this at San Deigo. Why would anybody > assume about the connectivity about the address i.e why is > this question even coming up ? If both the peers have > multiple address, then you have to support address list and > can't make any assumptions about the connectivity. You said > below that if we don't make the assumption, then both address > can change at the same time on the SAs. Perhaps, i am missing > the "assumption" part. Assuming something is fully connected > at some point in time does not mean that it stays that way > forever. So, even if we make the assumption, both the address > may change at the same time, right ? What am i missing ? > =20 > -mohan >=20 > ----- Original Message -----=20 > From: > To: > Sent: Tuesday, August 24, 2004 8:10 AM > Subject: [Mobike] New issue 17: Full connectivity >=20 >=20 > Hi, >=20 > Based on talks at San Diego, I've created a new issue > on the issue tracker: >=20 > "If both parties have several addresses, do we assume=20 > that all pairs have connectivity between them?" >=20 > There was discussion about this in mid-April (one example=20 > mentioned was two SGWs connected via two different private=20 > networks), and most people thought we should not assume this. >=20 > Assuming this would also seem to largely rule out IPv4/v6 > mobility. >=20 > If we decide _not_ to make this assumption, then we have cases=20 > where we have to change both parties's addresses in SAs=20 > at the same time. >=20 > It also seems the protocol will require some kind of address > lists, so something like SMOBIKE won't work (unless we assume=20 > one party knows several addresses for the other party via some=20 > other means than address lists sent within the protocol). >=20 > Any comments? >=20 > Best regards, > Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 3 08:50:27 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25307 for ; Fri, 3 Sep 2004 08:50:27 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 75E54FB4D5; Fri, 3 Sep 2004 08:50:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 20A2BFB451; Fri, 3 Sep 2004 08:50:26 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CB057FB458; Fri, 3 Sep 2004 08:50:23 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id CDD2EFB44C for ; Fri, 3 Sep 2004 08:50:22 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83CnQ109655; Fri, 3 Sep 2004 15:50:01 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 15:43:19 +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 i83ChJG8007811; Fri, 3 Sep 2004 15:43:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00oS13lC; Fri, 03 Sep 2004 15:43:17 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83Ch6Y00336; Fri, 3 Sep 2004 15:43:06 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 15:43:05 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 15:43:03 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 15:43:04 +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] New issue 18: Threat discussion Date: Fri, 3 Sep 2004 15:43:04 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FC8F@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 18: Threat discussion Thread-Index: AcSRShrbL4pkoF9VTx+5P6Bm5LcOPgAaQmoA From: To: , X-OriginalArrivalTime: 03 Sep 2004 12:43:04.0200 (UTC) FILETIME=[8E130080:01C491B3] 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 Mohan Parthasarathy wrote: > > 1) Unauthenticated attacker directs the traffic stream > from B to a third party C, with the intent flooding C > with unwanted traffic. >=20 > Is this attack where the unauthenticated attacker is modifying > the packets of the authenticated client or doing the attack > independently ? Both cases need to be considered, but obviously handling the latter one should be very easy.=20 > 2) Authenticated peer A directs the traffic stream from B > to a third party C, with the intent of flooding C with > unwanted traffic. >=20 > 3) Unauthenticated attacker directs the traffic stream > from B to somewhere (perhaps to the attacker or /dev/null),=20 > with the intent of preventing the legitimate peers from=20 > communicating. >=20 > Why is this different from (1) ? Hmm... perhaps it's not different (Francis also suggested that they should be merged). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 3 17:36:32 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16426 for ; Fri, 3 Sep 2004 17:36:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 47A39FB4D5; Fri, 3 Sep 2004 17:36:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 402F6FB457; Fri, 3 Sep 2004 17:36:32 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B10BFFB458; Fri, 3 Sep 2004 17:36:30 -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 80BC8FB44C for ; Fri, 3 Sep 2004 17:36:29 -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 i83LaPL30301; Fri, 3 Sep 2004 23:36:25 +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 i83LaQSj064315; Fri, 3 Sep 2004 23:36:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409032136.i83LaQSj064315@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Atul.Sharma@nokia.com Subject: Re: [Mobike] New issue 18: Threat discussion In-reply-to: Your message of Thu, 02 Sep 2004 14:54:14 EDT. Date: Fri, 03 Sep 2004 23:36:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.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: Actually, let me rephrase: I do not want to imply that "transient pseudo-NAT" attack has no relevance for MOBIKE. MOBIKE is all about authenticated management of (change of) address. And "pseudo-NAT" is about malicious change of address. So there is definite relevance there. The issue is that problem can be manifested in several scenarios other than just IKE. => in my draft I talk about signaling protocols with two concrete examples, mobile IP (look at RFC 3519 security considerations) and IKE. IMHO MOBIKE is concerned both for itself and as a source of clarification for IKE in a mobile/multi-homed environment. It may make sense to either do a general solution (else where?) => there is an easy solution but obviously incompatible with NAT traversal. or if we do MOBIKE-specific solution, => I don't believe in a MOBIKE-specific solution. In fact, the current discussion is about the defense against "third party bombing" which includes "transient pseudo-NAT"/ we should let other affected working groups be made aware of it. => this is done for mobile IP and this is a bit late for IKE (in fact this is covered by the pki4ipsec profile in its default policies). But IMHO it will be good to include somewhere in a MOBIKE document a clarification about this attack, just in order to avoid unsafe misinterpretation of the IKEv2 address agility. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Sep 3 21:27:30 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29112 for ; Fri, 3 Sep 2004 21:27:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ADB85FB459; Fri, 3 Sep 2004 21:27:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2FB0FFB455; Fri, 3 Sep 2004 21:27:29 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56BB6FB457; Fri, 3 Sep 2004 21:27:27 -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 9004EFB44C for ; Fri, 3 Sep 2004 21:27:26 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 4 Sep 2004 01:27:25 -0000 Message-ID: <008f01c4921e$55377af0$861167c0@adithya> From: "Mohan Parthasarathy" To: , , References: Subject: Re: [Mobike] New issue 18: Threat discussion Date: Fri, 3 Sep 2004 18:27:24 -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 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 Atul, Actually, let me rephrase: I do not want to imply that "transient pseudo-NAT" attack has no relevance for MOBIKE. MOBIKE is all about authenticated management of (change of) address. And "pseudo-NAT" is about malicious change of address. So there is definite relevance there. The issue is that problem can be manifested in several scenarios other than just IKE. It may make sense to either do a general solution (else where?) or if we do MOBIKE-specific solution, we should let other affected working groups be made aware of it. mohanp> I don't understand this point. How does solving this in other protocols mohanp> solve it for MOBIKE ? -mohan Atul > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext > Sent: Thursday, September 02, 2004 2:24 PM > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > Subject: RE: [Mobike] New issue 18: Threat discussion > > > > Hi Pasi, > > Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack? > The problem is of general nature, and will impact IP, IPsec traffic > as much as (MOB)IKE traffic. > > Any solution to this attack has to be of general nature rather than > MOBIKE-specific solution just working for MOBIKE. > > Just trying to understand.... > > Best, > Atul > > > > -----Original Message----- > > From: mobike-bounces@machshav.com > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext > > Sent: Tuesday, August 24, 2004 11:30 AM > > To: mobike@machshav.com > > Subject: [Mobike] New issue 18: Threat discussion > > > > > > At the San Diego meeting I promised to create a new issue > > about the various threats the protocol should consider. > > > > So far, we have at least the following (notation: the IKE > > peers are A and B; C is an innocent victim). > > > > 1) Unauthenticated attacker directs the traffic stream > > from B to a third party C, with the intent flooding C > > with unwanted traffic. > > > > 2) Authenticated peer A directs the traffic stream from B > > to a third party C, with the intent of flooding C with > > unwanted traffic. > > > > 3) Unauthenticated attacker directs the traffic stream > > from B to somewhere (perhaps to the attacker or /dev/null), > > with the intent of preventing the legitimate peers from > > communicating. > > > > 4) Unauthenticated attacker causes the IKE_SA to be > > closed by modifying just one or two IKE packets (if > > attacker can modify all packets, he can of course DoS). > > > > Do we have any other threats, assuming we don't need to > > repeat those where MOBIKE doesn't change anything in > > normal IKEv2? Should we add some discussion about these > > to the design document and/or protocol proposals? > > > > (BTW, a comment about terminology: Francis has quite > > consistently called case 1 "transient pseudo-NAT attack" > > and case 2 "third party bombing". I (and several others) > > have sometimes called both 1 and 2 third party bombing.) > > > > Cheers, > > Pasi > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Sep 4 10:56:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20269 for ; Sat, 4 Sep 2004 10:56:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 01E10FB4D5; Sat, 4 Sep 2004 10:56:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41629FB457; Sat, 4 Sep 2004 10:56:43 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 69CEAFB459; Sat, 4 Sep 2004 10:56:41 -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 43488FB44C for ; Sat, 4 Sep 2004 10:56:40 -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 i84EubL24099; Sat, 4 Sep 2004 16:56:37 +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 i84EuaSj069558; Sat, 4 Sep 2004 16:56:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409041456.i84EuaSj069558@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 17: Full connectivity In-reply-to: Your message of Fri, 03 Sep 2004 15:38:36 +0300. <125EA890549C8641A72F3809CB80DCCD16FC8E@esebe056.ntc.nokia.com> Date: Sat, 04 Sep 2004 16:56:36 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mohanp@sbcglobal.net, 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: Yes, I certainly agree that we should not assume this. I brought this up because at some point, Francis was suggesting that each end should be responsible for only changing its own address (e.g. 2004-07-29), but probably I misunderstood him here. => perhaps a SHOULD is a bit too strong here, IMHO this is only the common/likely case. There is a known exception: when the addresses are paired, it is better to change both addresses. I have two arguments in favor of my opinion: - a node has a better control on the condition of its own addresses - when an address becomes unusable, the only critical thing is to change the local address of *inbound* SAs. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 6 08:43:19 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00942 for ; Mon, 6 Sep 2004 08:43:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 05486FB455; Mon, 6 Sep 2004 08:43:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 07B6AFB451; Mon, 6 Sep 2004 08:43:18 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C65FCFB452; Mon, 6 Sep 2004 08:43:15 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id A78E7FB44C for ; Mon, 6 Sep 2004 08:43:14 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i86ChA112527; Mon, 6 Sep 2004 15:43:10 +0300 (EET DST) X-Scanned: Mon, 6 Sep 2004 15:41:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i86CfJlN028430; Mon, 6 Sep 2004 15:41:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 003RPgOz; Mon, 06 Sep 2004 15:41:17 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i86CfGS28445; Mon, 6 Sep 2004 15:41:16 +0300 (EET DST) Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Sep 2004 15:41:04 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Sep 2004 15:41:04 +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] New issue 17: Full connectivity Date: Mon, 6 Sep 2004 15:41:02 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178337@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 17: Full connectivity Thread-Index: AcSSj4Rt29GQO2tHQV66z3P2q6XfbABfY9aw From: To: , X-OriginalArrivalTime: 06 Sep 2004 12:41:04.0191 (UTC) FILETIME=[C5C854F0:01C4940E] 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 Francis.Dupont@enst-bretagne.fr wrote: > In your previous mail you wrote: >=20 > Yes, I certainly agree that we should not assume this. I=20 > brought this up because at some point, Francis was suggesting=20 > that each end should be responsible for only changing its own=20 > address (e.g. 2004-07-29), but probably I misunderstood him here. > =20 > =3D> perhaps a SHOULD is a bit too strong here, IMHO this is only the > common/likely case. There is a known exception: when the addresses > are paired, it is better to change both addresses. > I have two arguments in favor of my opinion: > - a node has a better control on the condition of its own addresses > - when an address becomes unusable, the only critical thing is to > change the local address of *inbound* SAs. Yes, certainly a node is likely to know better its own conditions than the other node. But I don't quite understand the last point:=20 in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel=20 header) address at all? (unless they're multicast, but that's beyond=20 IKEv2) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 6 10:59:28 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10836 for ; Mon, 6 Sep 2004 10:59:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6A864FB45B; Mon, 6 Sep 2004 10:59:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3FBEEFB455; Mon, 6 Sep 2004 10:59:28 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A91A4FB45B; Mon, 6 Sep 2004 10:59:26 -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 791F2FB452 for ; Mon, 6 Sep 2004 10:59:25 -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 i86ExML04049; Mon, 6 Sep 2004 16:59:22 +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 i86ExMSj077086; Mon, 6 Sep 2004 16:59:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409061459.i86ExMSj077086@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 17: Full connectivity In-reply-to: Your message of Mon, 06 Sep 2004 15:41:02 +0300. <125EA890549C8641A72F3809CB80DCCD178337@esebe056.ntc.nokia.com> Date: Mon, 06 Sep 2004 16:59:22 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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: Francis.Dupont@enst-bretagne.fr wrote: > In your previous mail you wrote: > > Yes, I certainly agree that we should not assume this. I > brought this up because at some point, Francis was suggesting > that each end should be responsible for only changing its own > address (e.g. 2004-07-29), but probably I misunderstood him here. > > => perhaps a SHOULD is a bit too strong here, IMHO this is only the > common/likely case. There is a known exception: when the addresses > are paired, it is better to change both addresses. > I have two arguments in favor of my opinion: > - a node has a better control on the condition of its own addresses > - when an address becomes unusable, the only critical thing is to > change the local address of *inbound* SAs. Yes, certainly a node is likely to know better its own conditions than the other node. But I don't quite understand the last point: in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel header) address at all? (unless they're multicast, but that's beyond IKEv2) => tunnel inbound IPsec SAs have a local (destination) end-point address. What I mean is the only way to fix this address is to send a message to the other end saying what address to use. BTW this is the central point of MOBIKE. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 6 14:09:33 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22379 for ; Mon, 6 Sep 2004 14:09:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 84B0AFB252; Mon, 6 Sep 2004 18:09:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6E6B9FB249; Mon, 6 Sep 2004 18:09:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 85D91FB24D; Mon, 6 Sep 2004 18:09:28 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 80D33FB248 for ; Mon, 6 Sep 2004 18:09:27 +0000 (UTC) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i86FSnT16322; Mon, 6 Sep 2004 18:28:49 +0300 (EET DST) X-Scanned: Mon, 6 Sep 2004 18:26: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 i86FQIUc009350; Mon, 6 Sep 2004 18:26:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00rjO3GS; Mon, 06 Sep 2004 18:26:17 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 i86FQGY11703; Mon, 6 Sep 2004 18:26:16 +0300 (EET DST) Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Sep 2004 18:26:16 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Sep 2004 18:26:16 +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] New issue 17: Full connectivity Date: Mon, 6 Sep 2004 18:26:16 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178338@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 17: Full connectivity Thread-Index: AcSUIjSqoGaPozLkQZqIqf4OP9TqKQAAEymA From: To: X-OriginalArrivalTime: 06 Sep 2004 15:26:16.0170 (UTC) FILETIME=[D9C84CA0:01C49425] 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: quoted-printable Francis.Dupont@enst-bretagne.fr wrote: > Yes, certainly a node is likely to know better its own conditions > than the other node. But I don't quite understand the last point:=20 > in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel=20 > header) address at all? (unless they're multicast, but=20 > that's beyond IKEv2) > =20 > =3D> tunnel inbound IPsec SAs have a local (destination)=20 > end-point address. What I mean is the only way to fix this=20 > address is to send a message to the other end saying what=20 > address to use. BTW this is the central point of MOBIKE. Err, I'm a bit confused today... I cannot find anything in 2401bis that would actually use the (outer) address in _inbound_ IPsec SAs=20 for anything when processing unicast traffic. And if it's not used, implementations don't even need to store it, and MOBIKE does not=20 need to update it, right? Or am I missing something in 2401bis that actually uses it? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 6 15:01:04 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25001 for ; Mon, 6 Sep 2004 15:01:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E5AA4FB257; Mon, 6 Sep 2004 19:01:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1C9AAFB251; Mon, 6 Sep 2004 19:01:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7CAB5FB252; Mon, 6 Sep 2004 19:01:01 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 523B9FB24F for ; Mon, 6 Sep 2004 19:01:00 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i86J0qL16940; Mon, 6 Sep 2004 21:00:52 +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 i86J0qSj077882; Mon, 6 Sep 2004 21:00:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409061900.i86J0qSj077882@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 17: Full connectivity In-reply-to: Your message of Mon, 06 Sep 2004 18:26:16 +0300. <125EA890549C8641A72F3809CB80DCCD178338@esebe056.ntc.nokia.com> Date: Mon, 06 Sep 2004 21:00:52 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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: > Yes, certainly a node is likely to know better its own conditions > than the other node. But I don't quite understand the last point: > in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel > header) address at all? (unless they're multicast, but > that's beyond IKEv2) > > => tunnel inbound IPsec SAs have a local (destination) > end-point address. What I mean is the only way to fix this > address is to send a message to the other end saying what > address to use. BTW this is the central point of MOBIKE. Err, I'm a bit confused today... I cannot find anything in 2401bis that would actually use the (outer) address in _inbound_ IPsec SAs for anything when processing unicast traffic. => the destination address of packets sent over an IPsec tunnel SA is a mandatory parameter on the sending side, in this case the other peer. And if it's not used, => it is used, here tunnel is not tunnel effect (:-). implementations don't even need to store it, => it is stored. We can argue about the source address of the encapsulating header, but the destination address is a mandatory parameter. and MOBIKE does not need to update it, right? => as this is something the local peer can't update without a signaling with the other peer, this is something which can only be managed with MOBIKE or a similar mechanism (in fact MOBIKE is the explicit mechanism, the other mechanism, the implicit one, is part of NAT traversal). Or am I missing something in 2401bis that actually uses it? => we only misunderstand ourselved (:-). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 6 19:21:51 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10342 for ; Mon, 6 Sep 2004 19:21:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 742D1FB27D; Mon, 6 Sep 2004 23:21:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A52C0FB24F; Mon, 6 Sep 2004 23:21:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 335C6FB252; Mon, 6 Sep 2004 23:21:46 +0000 (UTC) Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by machshav.com (Postfix) with ESMTP id 68E4FFB24A for ; Mon, 6 Sep 2004 23:21:45 +0000 (UTC) Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i86NMQm0016873 for ; Mon, 6 Sep 2004 16:22:26 -0700 Message-ID: <1ca501c49468$430558b0$110fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: Subject: Fw: [Mobike] New issue 17: Full connectivity Date: Mon, 6 Sep 2004 16:21:39 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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 Intoto Inc. www.intoto.com ----- Original Message ----- From: "Srinivasa Rao Addepalli" To: ; "Francis Dupont" Cc: Sent: Monday, September 06, 2004 12:27 PM Subject: Re: [Mobike] New issue 17: Full connectivity > Umm... I guess it depends on how IPSec is implemented. > > At the originitaing security gateway must know the remote peer IP address and uses > it as Destination IP address. > > On the receiving end, some implementations would only check if the destination > IP address of the received packet is its local IP address. If so, it consumes the > packet and if not, the packet is forwarded. Some implementation might go beyond > this and might even look for exact match. > > MOBIKE might need to keep both kinds of implementation in mind or make > explicit statement on the behaviour it expects from inbound processing. > > Srini > > Intoto Inc. > www.intoto.com > ----- Original Message ----- > From: "Francis Dupont" > To: > Cc: > Sent: Monday, September 06, 2004 12:00 PM > Subject: Re: [Mobike] New issue 17: Full connectivity > > > > In your previous mail you wrote: > > > > > Yes, certainly a node is likely to know better its own conditions > > > than the other node. But I don't quite understand the last point: > > > in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel > > > header) address at all? (unless they're multicast, but > > > that's beyond IKEv2) > > > > > > => tunnel inbound IPsec SAs have a local (destination) > > > end-point address. What I mean is the only way to fix this > > > address is to send a message to the other end saying what > > > address to use. BTW this is the central point of MOBIKE. > > > > Err, I'm a bit confused today... I cannot find anything in 2401bis > > that would actually use the (outer) address in _inbound_ IPsec SAs > > for anything when processing unicast traffic. > > > > => the destination address of packets sent over an IPsec tunnel SA is > > a mandatory parameter on the sending side, in this case the other peer. > > > > And if it's not used, > > > > => it is used, here tunnel is not tunnel effect (:-). > > > > implementations don't even need to store it, > > > > => it is stored. We can argue about the source address of the encapsulating > > header, but the destination address is a mandatory parameter. > > > > and MOBIKE does not need to update it, right? > > > > => as this is something the local peer can't update without a signaling > > with the other peer, this is something which can only be managed with > > MOBIKE or a similar mechanism (in fact MOBIKE is the explicit mechanism, > > the other mechanism, the implicit one, is part of NAT traversal). > > > > Or am I missing something in 2401bis that actually uses it? > > > > => we only misunderstand ourselved (:-). > > > > Regards > > > > Francis.Dupont@enst-bretagne.fr > > > > _______________________________________________ > > 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 Sep 7 02:25:08 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21610 for ; Tue, 7 Sep 2004 02:25:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B6502FB256; Tue, 7 Sep 2004 06:25:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 00827FB251; Tue, 7 Sep 2004 06:25:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1AA81FB256; Tue, 7 Sep 2004 06:25:01 +0000 (UTC) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id E15F6FB24F for ; Tue, 7 Sep 2004 06:24:59 +0000 (UTC) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i876Oq111524; Tue, 7 Sep 2004 09:24:52 +0300 (EET DST) X-Scanned: Tue, 7 Sep 2004 09:20:52 +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 i876Kq35029190; Tue, 7 Sep 2004 09:20:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00XEHAXy; Tue, 07 Sep 2004 09:20:40 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i876KYY07010; Tue, 7 Sep 2004 09:20:34 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 09:20:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 09:20:30 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 09:20:29 +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] New issue 17: Full connectivity Date: Tue, 7 Sep 2004 09:20:29 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178339@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 17: Full connectivity Thread-Index: AcSURDcwG+E+TG6jR2qAjXFHndn/mAAXMz6w From: To: , X-OriginalArrivalTime: 07 Sep 2004 06:20:29.0750 (UTC) FILETIME=[C5CEE560:01C494A2] 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 Francis.Dupont@enst-bretagne.fr wrote: > > Err, I'm a bit confused today... I cannot find anything in 2401bis > that would actually use the (outer) address in _inbound_ IPsec SAs=20 > for anything when processing unicast traffic. >=20 > =3D> the destination address of packets sent over an IPsec tunnel SA=20 > is a mandatory parameter on the sending side, in this case the=20 > other peer. Ok, now I understand where the confusion came from: we had a small mismatch in terminology (2401bis calls those SAs "outbound" :-) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 7 04:27:35 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29628 for ; Tue, 7 Sep 2004 04:27:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 71D4AFB27D; Tue, 7 Sep 2004 08:27:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B2738FB266; Tue, 7 Sep 2004 08:27:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 66DA5FB252; Mon, 6 Sep 2004 23:19:28 +0000 (UTC) Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by machshav.com (Postfix) with ESMTP id AEF01FB24A for ; Mon, 6 Sep 2004 23:19:27 +0000 (UTC) Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i86NK3lx016815; Mon, 6 Sep 2004 16:20:03 -0700 Message-ID: <1c9601c49467$edc94730$110fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: , "Francis Dupont" References: <200409061900.i86J0qSj077882@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] New issue 17: Full connectivity Date: Mon, 6 Sep 2004 12:27:02 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailman-Approved-At: Tue, 07 Sep 2004 08:27:33 +0000 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 Umm... I guess it depends on how IPSec is implemented. At the originitaing security gateway must know the remote peer IP address and uses it as Destination IP address. On the receiving end, some implementations would only check if the destination IP address of the received packet is its local IP address. If so, it consumes the packet and if not, the packet is forwarded. Some implementation might go beyond this and might even look for exact match. MOBIKE might need to keep both kinds of implementation in mind or make explicit statement on the behaviour it expects from inbound processing. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Francis Dupont" To: Cc: Sent: Monday, September 06, 2004 12:00 PM Subject: Re: [Mobike] New issue 17: Full connectivity > In your previous mail you wrote: > > > Yes, certainly a node is likely to know better its own conditions > > than the other node. But I don't quite understand the last point: > > in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel > > header) address at all? (unless they're multicast, but > > that's beyond IKEv2) > > > > => tunnel inbound IPsec SAs have a local (destination) > > end-point address. What I mean is the only way to fix this > > address is to send a message to the other end saying what > > address to use. BTW this is the central point of MOBIKE. > > Err, I'm a bit confused today... I cannot find anything in 2401bis > that would actually use the (outer) address in _inbound_ IPsec SAs > for anything when processing unicast traffic. > > => the destination address of packets sent over an IPsec tunnel SA is > a mandatory parameter on the sending side, in this case the other peer. > > And if it's not used, > > => it is used, here tunnel is not tunnel effect (:-). > > implementations don't even need to store it, > > => it is stored. We can argue about the source address of the encapsulating > header, but the destination address is a mandatory parameter. > > and MOBIKE does not need to update it, right? > > => as this is something the local peer can't update without a signaling > with the other peer, this is something which can only be managed with > MOBIKE or a similar mechanism (in fact MOBIKE is the explicit mechanism, > the other mechanism, the implicit one, is part of NAT traversal). > > Or am I missing something in 2401bis that actually uses it? > > => we only misunderstand ourselved (:-). > > Regards > > Francis.Dupont@enst-bretagne.fr > > _______________________________________________ > 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 Sep 7 05:10:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02972 for ; Tue, 7 Sep 2004 05:10:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3B379FB27F; Tue, 7 Sep 2004 09:10:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F25B7FB256; Tue, 7 Sep 2004 09:10:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3EB60FB266; Tue, 7 Sep 2004 09:10:16 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 0B902FB251 for ; Tue, 7 Sep 2004 09:10:15 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i879A6w14505; Tue, 7 Sep 2004 11:10:07 +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 i879A6Sj080072; Tue, 7 Sep 2004 11:10:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409070910.i879A6Sj080072@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Srinivasa Rao Addepalli" Subject: Re: [Mobike] New issue 17: Full connectivity In-reply-to: Your message of Mon, 06 Sep 2004 12:27:02 PDT. <1c9601c49467$edc94730$110fa8c0@SriniSony> Date: Tue, 07 Sep 2004 11:10:06 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.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: Umm... I guess it depends on how IPSec is implemented. At the originitaing security gateway must know the remote peer IP address and uses it as Destination IP address. => this is what matters. On the receiving end, some implementations would only check if the destination IP address of the received packet is its local IP address. => all implementations check if the destination address is local. If it is not the packet is dropped or forwarded. Some implementation might go beyond this and might even look for exact match. => I believe you think to the SA lookup (on the destination, protocol and SPI triple, or as it is recommended by RFC 2401bis on the SPI only for unicast. Note the last one is in fact the easier to implement). MOBIKE might need to keep both kinds of implementation in mind or make explicit statement on the behaviour it expects from inbound processing. => we already discussed about this point and the RFC 2401bis was updated to say any local address should be accepted ad the destination address of an incoming packet. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 7 09:33:35 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21271 for ; Tue, 7 Sep 2004 09:33:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 38BDDFB27D; Tue, 7 Sep 2004 13:33:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9F739FB256; Tue, 7 Sep 2004 13:33:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9F9D0FB266; Tue, 7 Sep 2004 13:33:28 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 76E61FB251 for ; Tue, 7 Sep 2004 13:33:27 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i87DXPT17571; Tue, 7 Sep 2004 16:33:25 +0300 (EET DST) X-Scanned: Tue, 7 Sep 2004 16:30:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i87DU9Xf029055; Tue, 7 Sep 2004 16:30:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00qDjcVb; Tue, 07 Sep 2004 16:30:06 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i87DTxY13887; Tue, 7 Sep 2004 16:29:59 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 08:29:59 -0500 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] New issue 18: Threat discussion Date: Tue, 7 Sep 2004 09:29:57 -0400 Message-ID: Thread-Topic: [Mobike] New issue 18: Threat discussion Thread-Index: AcSSHoqpUp2ix0AST1GCmzEeDnOtSACve2yw From: To: , , X-OriginalArrivalTime: 07 Sep 2004 13:29:59.0051 (UTC) FILETIME=[C5822DB0:01C494DE] 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 Mohan, The way I understand the pseudo-NAT problem, the attacker does modification of addresses in the IP header. The authenticated/encrypted IKE datagram does not get affected. Since the attack is on the general=20 IP header, the problem is general in nature than specific to MOBIKE. Though I agree it has relevance for MOBIKE. If a general solution is offered, it would work as much for IP traffic as for the MOBIKE traffic. The converse may not be true, i.e. a = MOBIKE-only solution may not work for the general IP case. I think Francis expressed = his non-preference for a MOBIKE-only solution, in an earlier message.=20 Atul > -----Original Message----- > From: ext Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > Sent: Friday, September 03, 2004 9:27 PM > To: Sharma Atul (Nokia-ES/Boston); Eronen Pasi (Nokia-NRC/Helsinki); > mobike@machshav.com > Subject: Re: [Mobike] New issue 18: Threat discussion >=20 >=20 > Atul, >=20 >=20 > Actually, let me rephrase: >=20 > I do not want to imply that "transient pseudo-NAT" attack has no=20 > relevance for MOBIKE. MOBIKE is all about authenticated management > of (change of) address. And "pseudo-NAT" is about malicious change > of address.=20 >=20 > So there is definite relevance there. >=20 > The issue is that problem can be manifested in several scenarios=20 > other than just IKE. It may make sense to either do a general solution > (else where?) or if we do MOBIKE-specific solution, we should let > other affected working groups be made aware of it. >=20 > mohanp> I don't understand this point. How does solving this=20 > in other protocols > mohanp> solve it for MOBIKE ? >=20 > -mohan >=20 > Atul >=20 > > -----Original Message----- > > From: mobike-bounces@machshav.com=20 > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext=20 > > Sent: Thursday, September 02, 2004 2:24 PM > > To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com > > Subject: RE: [Mobike] New issue 18: Threat discussion > >=20 > >=20 > >=20 > > Hi Pasi, > >=20 > > Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack? > > The problem is of general nature, and will impact IP, IPsec traffic > > as much as (MOB)IKE traffic.=20 > >=20 > > Any solution to this attack has to be of general nature rather than > > MOBIKE-specific solution just working for MOBIKE. > >=20 > > Just trying to understand.... > >=20 > > Best, > > Atul > >=20 > >=20 > > > -----Original Message----- > > > From: mobike-bounces@machshav.com=20 > > > [mailto:mobike-bounces@machshav.com]On > > > Behalf Of ext=20 > > > Sent: Tuesday, August 24, 2004 11:30 AM > > > To: mobike@machshav.com > > > Subject: [Mobike] New issue 18: Threat discussion > > >=20 > > >=20 > > > At the San Diego meeting I promised to create a new issue > > > about the various threats the protocol should consider. > > >=20 > > > So far, we have at least the following (notation: the IKE > > > peers are A and B; C is an innocent victim). > > >=20 > > > 1) Unauthenticated attacker directs the traffic stream > > > from B to a third party C, with the intent flooding C > > > with unwanted traffic. > > >=20 > > > 2) Authenticated peer A directs the traffic stream from B > > > to a third party C, with the intent of flooding C with > > > unwanted traffic. > > >=20 > > > 3) Unauthenticated attacker directs the traffic stream > > > from B to somewhere (perhaps to the attacker or /dev/null),=20 > > > with the intent of preventing the legitimate peers from=20 > > > communicating. > > >=20 > > > 4) Unauthenticated attacker causes the IKE_SA to be > > > closed by modifying just one or two IKE packets (if > > > attacker can modify all packets, he can of course DoS). > > >=20 > > > Do we have any other threats, assuming we don't need to=20 > > > repeat those where MOBIKE doesn't change anything in > > > normal IKEv2? Should we add some discussion about these=20 > > > to the design document and/or protocol proposals? > > >=20 > > > (BTW, a comment about terminology: Francis has quite > > > consistently called case 1 "transient pseudo-NAT attack"=20 > > > and case 2 "third party bombing". I (and several others)=20 > > > have sometimes called both 1 and 2 third party bombing.) > > >=20 > > > Cheers, > > > Pasi > > > _______________________________________________ > > > Mobike mailing list > > > Mobike@machshav.com > > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > >=20 > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > >=20 > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 7 09:48:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22344 for ; Tue, 7 Sep 2004 09:48:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 89CBAFB277; Tue, 7 Sep 2004 13:48:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D5B7FB266; Tue, 7 Sep 2004 13:48:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7DFA4FB277; Tue, 7 Sep 2004 13:48:45 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 46E20FB256 for ; Tue, 7 Sep 2004 13:48:44 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i87Dmfe05694; Tue, 7 Sep 2004 15:48:41 +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 i87DmfSj081775; Tue, 7 Sep 2004 15:48:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409071348.i87DmfSj081775@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Atul.Sharma@nokia.com Subject: Re: [Mobike] New issue 18: Threat discussion In-reply-to: Your message of Tue, 07 Sep 2004 09:29:57 EDT. Date: Tue, 07 Sep 2004 15:48:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, mohanp@sbcglobal.net, Pasi.Eronen@nokia.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: The way I understand the pseudo-NAT problem, the attacker does modification of addresses in the IP header. The authenticated/encrypted IKE datagram does not get affected. Since the attack is on the general IP header, the problem is general in nature than specific to MOBIKE. Though I agree it has relevance for MOBIKE. If a general solution is offered, => the general solution is easy: protect the addresses in the IP header. Of course it has an immediate drawback: NAT traversal is no more possible. it would work as much for IP traffic => for general IP traffic it is named AH. as for the MOBIKE traffic. => MOBIKE (and any other signaling protocol) is different because the attack has a side effect outside the MOBIKE traffic itself (this is why the attack is qualified as "transient" pseudo-NAT attack). The converse may not be true, i.e. a MOBIKE-only solution may not work for the general IP case. => I agree but this doesn't matter because the MOBIKE security target is higher, i.e., any MOBIKE mechanism should include a defense against the transient pseudo-NAT. I think Francis expressed his non-preference for a MOBIKE-only solution, in an earlier message. => my position is the attack should be in the list of attacks considered in the design phase/document. BTW it is in, and the discussion is more about the 3rd party bombing, i.e., in my terminology the attack performed by an authenticated/authorized peer (and obviously something is not right in the authentication/authorization in this case). Another point of interest is the security of NAT traversal (not in order to modify it, but in order to compare) which is of course subject to the attack but which includes its own defense (implicit update to the last seen peer address and keepalive mechanisms which narrow the window of attack effect). 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 Sep 8 22:35:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24348 for ; Wed, 8 Sep 2004 22:35:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 87990FB256; Thu, 9 Sep 2004 02:35:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A6BE2FB2B2; Thu, 9 Sep 2004 02:35:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C5665FB255; Tue, 7 Sep 2004 21:23:18 +0000 (UTC) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 4D5DCFB24D for ; Tue, 7 Sep 2004 21:23:18 +0000 (UTC) Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i87LMkjh023207; Tue, 7 Sep 2004 17:23:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <1c9601c49467$edc94730$110fa8c0@SriniSony> References: <200409061900.i86J0qSj077882@givry.rennes.enst-bretagne.fr> <1c9601c49467$edc94730$110fa8c0@SriniSony> Date: Tue, 7 Sep 2004 12:44:44 -0400 To: "Srinivasa Rao Addepalli" From: Stephen Kent Subject: Re: [Mobike] New issue 17: Full connectivity Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 At 12:27 PM -0700 9/6/04, Srinivasa Rao Addepalli wrote: >Umm... I guess it depends on how IPSec is implemented. > >At the originitaing security gateway must know the remote peer IP >address and uses >it as Destination IP address. right. >On the receiving end, some implementations would only check if the destination >IP address of the received packet is its local IP address. If so, it >consumes the >packet and if not, the packet is forwarded. Some implementation >might go beyond >this and might even look for exact match. If the destination is a security gateway, it must distinguish between IPsec traffic addressed to it and IPsec (or non-IPsec) traffic addressed to hosts behind it, and thus potentially bypassed. So, in that context, it is necessary to pay attention to the destination address! Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 8 22:36:27 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24376 for ; Wed, 8 Sep 2004 22:36:27 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0BFB7FB29F; Thu, 9 Sep 2004 02:36:29 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 53121FB2D5; Thu, 9 Sep 2004 02:35:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F28F7FB279; Wed, 8 Sep 2004 01:57:08 +0000 (UTC) Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by machshav.com (Postfix) with SMTP id 54CFFFB255 for ; Wed, 8 Sep 2004 01:57:08 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 8 Sep 2004 01:57:06 -0000 Message-ID: <013c01c49547$2239b380$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , References: <200409071348.i87DmfSj081775@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] New issue 18: Threat discussion Date: Tue, 7 Sep 2004 18:56:50 -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@machshav.com, Pasi.Eronen@nokia.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 Francis, > In your previous mail you wrote: > > The way I understand the pseudo-NAT problem, the attacker does > modification of addresses in the IP header. The authenticated/encrypted > IKE datagram does not get affected. Since the attack is on the general > IP header, the problem is general in nature than specific to MOBIKE. > Though I agree it has relevance for MOBIKE. > > If a general solution is offered, > > => the general solution is easy: protect the addresses in the IP header. > Of course it has an immediate drawback: NAT traversal is no more possible. > Agreed. > it would work as much for IP traffic > > => for general IP traffic it is named AH. > > as for the MOBIKE traffic. > > => MOBIKE (and any other signaling protocol) is different because the > attack has a side effect outside the MOBIKE traffic itself (this is why > the attack is qualified as "transient" pseudo-NAT attack). > > The converse may not be true, i.e. a MOBIKE-only > solution may not work for the general IP case. > > => I agree but this doesn't matter because the MOBIKE security target > is higher, i.e., any MOBIKE mechanism should include a defense against > the transient pseudo-NAT. > Do you mean "defense" as in detecting NAT (like NAT_PREVENTION in Pasi's draft) OR a solution that would work when moving behind NAT ? > I think Francis expressed his > non-preference for a MOBIKE-only solution, in an earlier message. > > => my position is the attack should be in the list of attacks considered > in the design phase/document. BTW it is in, and the discussion is more > about the 3rd party bombing, i.e., in my terminology the attack performed > by an authenticated/authorized peer (and obviously something is not right > in the authentication/authorization in this case). This is a bit confusing. Are you saying that the attack is 3rd party bombing if performed by authenticated peer and transient pseudo-NAT attack if done by someone else ? > Another point of interest is the security of NAT traversal (not in order to > modify it, but in order to compare) which is of course subject to the attack > but which includes its own defense (implicit update to the last seen peer > address and keepalive mechanisms which narrow the window of attack effect). > It might be useful to clarify what we mean by NAT traversal in these threads. 1) NAT traversal : As defined in IKEv2 base spec. It works only during the beginning of IKE session. 2) Behavior of MOBIKE when moving behind NAT - this is MOBIKE mechanism to support moving behind a NAT which is also NAT traversal. But this is something specific to MOBIKE and works during anytime not just during SA setup. MOBIKE may or may not end up supporing t this feature or it may support partially etc. But this is distinctly different from (1). -mohan > 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 Sep 8 22:38:12 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24503 for ; Wed, 8 Sep 2004 22:38:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7E864FB2CF; Thu, 9 Sep 2004 02:38:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C8C7EFB2DF; Thu, 9 Sep 2004 02:37:40 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 46771FB255; Wed, 8 Sep 2004 10:25:37 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 0AB88FB24A for ; Wed, 8 Sep 2004 10:25:36 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i88APWS24166; Wed, 8 Sep 2004 12:25:32 +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 i88APVSj086163; Wed, 8 Sep 2004 12:25:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409081025.i88APVSj086163@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] New issue 18: Threat discussion In-reply-to: Your message of Tue, 07 Sep 2004 18:56:50 PDT. <013c01c49547$2239b380$861167c0@adithya> Date: Wed, 08 Sep 2004 12:25:31 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Atul.Sharma@nokia.com, Pasi.Eronen@nokia.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: > => I agree but this doesn't matter because the MOBIKE security target > is higher, i.e., any MOBIKE mechanism should include a defense against > the transient pseudo-NAT. > Do you mean "defense" as in detecting NAT (like NAT_PREVENTION in Pasi's draft) OR a solution that would work when moving behind NAT ? => detecting NAT is the job of IKE. For MOBIKE itself it comes after the initial exchange so uses only protected exchanges. As soon as an address is inside an exchange (and it should be in an explicit mechanism) it is protected. > I think Francis expressed his > non-preference for a MOBIKE-only solution, in an earlier message. > > => my position is the attack should be in the list of attacks considered > in the design phase/document. BTW it is in, and the discussion is more > about the 3rd party bombing, i.e., in my terminology the attack performed > by an authenticated/authorized peer (and obviously something is not right > in the authentication/authorization in this case). This is a bit confusing. => the original message is a bit old today. Please refer to it. Are you saying that the attack is 3rd party bombing if performed by authenticated peer and transient pseudo-NAT attack if done by someone else ? => yes (the original message listed attacks and refered to my terminology.) It might be useful to clarify what we mean by NAT traversal in these threads. 1) NAT traversal : As defined in IKEv2 base spec. It works only during the beginning of IKE session. => this is the definition in the IKE context. 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 Sep 8 22:38:58 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24559 for ; Wed, 8 Sep 2004 22:38:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E3175FB280; Thu, 9 Sep 2004 02:38:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BE5BEFB277; Thu, 9 Sep 2004 02:38:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E96DAFB266; Wed, 8 Sep 2004 19:20:47 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 0F3C2FB251 for ; Wed, 8 Sep 2004 19:20:47 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i88Is1u00681; Wed, 8 Sep 2004 11:54:01 -0700 X-mProtect: <200409081854> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdA1nY7N; Wed, 08 Sep 2004 11:53:59 PDT Message-ID: <413F5DF7.2090600@iprg.nokia.com> Date: Wed, 08 Sep 2004 12:31:03 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A60227C18C@esebe023.ntc.nokia.com> <412B6628.3090900@piuha.net> In-Reply-To: <412B6628.3090900@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 Jari Arkko wrote: > > Seems like most people want to rely on some sort of > standard movement detection process outside MOBIKE > (= the local knowledge). Question: how are we going > to specify this, just as an assumption that its outside > the MOBIKE protocol, it should be outside the scope of MOBIKE protocol. Vijay or as a hard requirement to do > ? It seems that the former is the only > option, given that movement detection is somewhat of > a moving target (no pun intended). IPv4 and IPv6 have > different capabilities, several enhancements are being > worked in different places (MIP6/DHCP/DNA WGs), etc. > > --Jari > >> Those are the things Jari called "local knowledge": something in the >> mobile node knows what should be done >> ("switch to this address"), based on information >> that's "local" in the sense that it's not a result >> of an end-to-end protocol between the IKEv2 nodes. >> >> I don't think there's any disagreement about handling those: we just >> assume that there's "something" in the mobile node that triggers >> appropriate MOBIKE messages to be sent. >> >> But issue 16 is more about what to do if we know there is a problem >> (==we don't receive any replies to our IKE requests, even after >> retransmissions), but we don't know what address change would correct >> the situation (because >> the "local knowlege" is either not reliable enough, >> or the failure is in the "middle" where local knowledge >> does not reach). >> >> Here the options seem to be: (1) fail, (2) send some IKEv2 message(s), >> either new ones or the one we were retransmitting, along some other >> path, and use information >> about their delivery to help deciding what should >> be done, or (3) send some non-IKEv2 message(s) along some other path. >> >> Now, option 1 would be the right choice only if we assume that the >> "local knowledge" is reliable enough, and we do not care about >> non-local failures. (Is this >> the choice you prefer?) >> >> Option 3 means we don't have interoperability unless the >> nodes also agree what that non-IKEv2 end-to-end (between >> IKEv2 peers) protocol is. >> So my opinion is strongly something like option 2: if we don't receive >> replies to our IKEv2 request(s), try sending them along some other >> path (unless the current path is the only one acceptable to us, of >> course). >> >> Best regards, >> Pasi >> _______________________________________________ >> Mobike mailing list >> Mobike@machshav.com >> https://www.machshav.com/mailman/listinfo.cgi/mobike >> >> > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Sep 22 06:20:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20647 for ; Wed, 22 Sep 2004 06:20:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 15E5EFB284; Wed, 22 Sep 2004 06:20:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0F1CEFB27F; Wed, 22 Sep 2004 06:20:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 25A3BFB280; Wed, 22 Sep 2004 06:20:14 -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 140E9FB279 for ; Wed, 22 Sep 2004 06:20:13 -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 i8MAK3p23708 for ; Wed, 22 Sep 2004 12:20:03 +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 i8MAK3Sj057294 for ; Wed, 22 Sep 2004 12:20:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409221020.i8MAK3Sj057294@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobike@machshav.com Date: Wed, 22 Sep 2004 12:20:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobike] SPD entries too 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 Warning: the end-point addresses are not strictly in SPD entries but they are in a structure bound to SPD entries in implementations I use and there are somewhere as part of the policies in any implementation. When a peer address is updated, this should impact not only some SAD entries (end-point addresses, named "tunnel header IP source and destination address" in last RFC 2401bis, are SA parameters/data items in the SAD) but also the corresponding SPD entries (or policies). The rationale is one'd like to see peer address updates to survive to any kind of rekey/restart. Any comment (or a good terminology)? 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 Sep 22 08:50:30 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02359 for ; Wed, 22 Sep 2004 08:50:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3A2A3FB27F; Wed, 22 Sep 2004 08:50:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 286F0FB279; Wed, 22 Sep 2004 08:50:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 37592FB27C; Wed, 22 Sep 2004 08:50:28 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by machshav.com (Postfix) with ESMTP id AD0DAFB262 for ; Wed, 22 Sep 2004 08:50:27 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8MCoPbw680122 for ; Wed, 22 Sep 2004 08:50:26 -0400 Received: from d27mc101.rchland.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MCpd6D087692 for ; Wed, 22 Sep 2004 08:51:39 -0400 From: Dennis Frett To: mobike@machshav.com Message-ID: Date: Wed, 22 Sep 2004 07:50:23 -0500 X-MIMETrack: Serialize by Router on D27mc101/27/M/IBM(Release 6.5.2|June 01, 2004) at 09/22/2004 07:50:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Mobike] Dennis Frett/Rochester/IBM is out of the office. 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 I will be out of the office starting 09/12/2004 and will not return until 09/27/2004. I will respond to your message when I return. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Sep 26 13:37:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20346 for ; Sun, 26 Sep 2004 13:37:03 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A279DFB262; Sun, 26 Sep 2004 13:37:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 358CEFB24D; Sun, 26 Sep 2004 13:37:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CA853FB251; Sun, 26 Sep 2004 13:36:59 -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 88861FB24A for ; Sun, 26 Sep 2004 13:36:58 -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 i8QHaY607532 for ; Sun, 26 Sep 2004 19:36:34 +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 i8QHaXSj077621 for ; Sun, 26 Sep 2004 19:36:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409261736.i8QHaXSj077621@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobike@machshav.com Date: Sun, 26 Sep 2004 19:36:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobike] transport mode document as WG item 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 We have two weeks before the initial WG document submission cut-off so I ask the WG item status for the MOBIKE & transport mode document (currently draft-dupont-mobike-transport-00.txt). BTW I'd like to get comments about 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 Mon Sep 27 17:08:08 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08148 for ; Mon, 27 Sep 2004 17:08:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DAE29FB240; Mon, 27 Sep 2004 17:08:07 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0F35FB24A; Mon, 27 Sep 2004 17:08:04 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F14E6FB24D; Mon, 27 Sep 2004 17:08:02 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id E28BAFB240 for ; Mon, 27 Sep 2004 17:08:01 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RL7u111710; Tue, 28 Sep 2004 00:07:56 +0300 (EET DST) X-Scanned: Tue, 28 Sep 2004 00:06:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8RL60Ob008846; Tue, 28 Sep 2004 00:06:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00MS9K7Z; Tue, 28 Sep 2004 00:05:54 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RL5rY05328; Tue, 28 Sep 2004 00:05:53 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 16:05:38 -0500 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] transport mode document as WG item Date: Mon, 27 Sep 2004 17:05:37 -0400 Message-ID: Thread-Topic: [Mobike] transport mode document as WG item Thread-Index: AcSj77ikcnNQLOW/Teihr92aRwd82wA5Jtxw From: To: , X-OriginalArrivalTime: 27 Sep 2004 21:05:38.0478 (UTC) FILETIME=[BD56ACE0:01C4A4D5] 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 Francis, In the roaming laptop scenario, when the address changes, how would the mechanism needed to update the address on the remote side=20 (corporate gateway) differ whether tunnel mode or transport mode is used? That is true tunnel endpoint address in the tunnel mode is maintained just by IKE demon and localized to IKE. But even in the transport case, the peer addresses are endpoint addresses, and we change the endpoint=20 addresses maintained by IKE, just like we would change TEP in the tunnel = case. So, thinking out loud, as far as MOBIKE is concerned the mechanism should be similar whether we are using tunnel or transport mode? I was just trying to understand, what we will need to do things = differently for the transport case, as far as MOBIKE is concerned? Regards, Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Francis Dupont > Sent: Sunday, September 26, 2004 1:37 PM > To: mobike@machshav.com > Subject: [Mobike] transport mode document as WG item >=20 >=20 > We have two weeks before the initial WG document submission cut-off > so I ask the WG item status for the MOBIKE & transport mode document > (currently draft-dupont-mobike-transport-00.txt). BTW I'd like to get > comments about it. >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Sep 27 18:00:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13478 for ; Mon, 27 Sep 2004 18:00:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3C3E0FB262; Mon, 27 Sep 2004 18:00:22 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CC55BFB24A; Mon, 27 Sep 2004 18:00:18 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F2494FB251; Mon, 27 Sep 2004 18:00:15 -0400 (EDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by machshav.com (Postfix) with ESMTP id D0C8EFB240 for ; Mon, 27 Sep 2004 18:00:14 -0400 (EDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8RM0D914831; Tue, 28 Sep 2004 00:00:13 +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 i8RM0BSj083228; Tue, 28 Sep 2004 00:00:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409272200.i8RM0BSj083228@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Atul.Sharma@nokia.com Subject: Re: [Mobike] transport mode document as WG item In-reply-to: Your message of Mon, 27 Sep 2004 17:05:37 EDT. Date: Tue, 28 Sep 2004 00:00:11 +0200 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: In the roaming laptop scenario, when the address changes, how would the mechanism needed to update the address on the remote side (corporate gateway) differ whether tunnel mode or transport mode is used? => these addresses have a very different role: in tunnel mode they are the endpoint addresses, in transport mode they are the traffic selectors. That is true tunnel endpoint address in the tunnel mode is maintained just by IKE demon and localized to IKE. But even in the transport case, the peer addresses are endpoint addresses, and we change the endpoint addresses maintained by IKE, just like we would change TEP in the tunnel case. So, thinking out loud, as far as MOBIKE is concerned the mechanism should be similar whether we are using tunnel or transport mode? => no, changing an address in transport mode implies far more than in tunnel mode: MOBIKE must be integrated into the whole IPsec architecture. We can specify something specific for transport mode, my proposal is to put transport mode outside the scope of MOBIKE for the moment. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 28 10:25:21 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25632 for ; Tue, 28 Sep 2004 10:25:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 87BCAFB255; Tue, 28 Sep 2004 10:25:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0ECC0FB255; Tue, 28 Sep 2004 10:25:19 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 44B7FFB262; Tue, 28 Sep 2004 10:25:17 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 2E907FB252 for ; Tue, 28 Sep 2004 10:25:16 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SEP7g13748; Tue, 28 Sep 2004 17:25:07 +0300 (EET DST) X-Scanned: Tue, 28 Sep 2004 17:22:57 +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 i8SEMvCW004402; Tue, 28 Sep 2004 17:22:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00NQ5kOP; Tue, 28 Sep 2004 17:22:56 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SEMiS18309; Tue, 28 Sep 2004 17:22:45 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Sep 2004 09:22:15 -0500 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] transport mode document as WG item Date: Tue, 28 Sep 2004 10:22:14 -0400 Message-ID: Thread-Topic: [Mobike] transport mode document as WG item Thread-Index: AcSk3cRKPUQWCoavTce0N1Su41WG/QAiB9RA From: To: X-OriginalArrivalTime: 28 Sep 2004 14:22:15.0728 (UTC) FILETIME=[8DC9DB00:01C4A566] 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: quoted-printable Hi Francis, Yes. I agree that an implication of handling the transport case would be a more integrated MOBIKE (with IPsec Architecture).=20 Best Regards, Atul > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, September 27, 2004 6:00 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: mobike@machshav.com > Subject: Re: [Mobike] transport mode document as WG item=20 >=20 > case. So, thinking out loud, as far as MOBIKE is concerned=20 > the mechanism > should be similar whether we are using tunnel or transport mode? > =20 > =3D> no, changing an address in transport mode implies far more than > in tunnel mode: MOBIKE must be integrated into the whole=20 > IPsec architecture. > We can specify something specific for transport mode, my=20 > proposal is to > put transport mode outside the scope of MOBIKE for the moment. >=20 =20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Sep 28 13:29:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06495 for ; Tue, 28 Sep 2004 13:29:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ED357FB255; Tue, 28 Sep 2004 13:29:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D6743FB254; Tue, 28 Sep 2004 13:29:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D3AE9FB255; Tue, 28 Sep 2004 13:29:08 -0400 (EDT) Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by machshav.com (Postfix) with SMTP id 5BAFFFB252 for ; Tue, 28 Sep 2004 13:29:08 -0400 (EDT) Message-ID: <20040928172907.41295.qmail@web41206.mail.yahoo.com> Received: from [67.122.117.214] by web41206.mail.yahoo.com via HTTP; Tue, 28 Sep 2004 10:29:07 PDT Date: Tue, 28 Sep 2004 10:29:07 -0700 (PDT) From: Tarique Mustafa Subject: RE: [Mobike] transport mode document as WG item To: Atul.Sharma@nokia.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: MIME-Version: 1.0 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: , Content-Type: multipart/mixed; boundary="===============1205054210==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============1205054210== Content-Type: multipart/alternative; boundary="0-441993031-1096392547=:41053" --0-441993031-1096392547=:41053 Content-Type: text/plain; charset=us-ascii Hi Francis & Atul, As a new-comer I have been silently following this particular trail of discussions. I absolutely agree that the implications of address change are far deeper - even may be bit more complicated - in Transport mode than in Tunnel mode. As such, it may need a better re-conciliation with IPSec architecture. Regards, -Tarique Mustafa Atul.Sharma@nokia.com wrote: Hi Francis, Yes. I agree that an implication of handling the transport case would be a more integrated MOBIKE (with IPsec Architecture). Best Regards, Atul > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, September 27, 2004 6:00 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: mobike@machshav.com > Subject: Re: [Mobike] transport mode document as WG item > > case. So, thinking out loud, as far as MOBIKE is concerned > the mechanism > should be similar whether we are using tunnel or transport mode? > > => no, changing an address in transport mode implies far more than > in tunnel mode: MOBIKE must be integrated into the whole > IPsec architecture. > We can specify something specific for transport mode, my > proposal is to > put transport mode outside the scope of MOBIKE for the moment. > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! --0-441993031-1096392547=:41053 Content-Type: text/html; charset=us-ascii
Hi Francis & Atul,
 
As a new-comer I have been silently following this particular trail of discussions.
 
I absolutely agree that the implications of address change are far deeper - even may be bit more complicated - in Transport mode than in Tunnel mode. As such, it may need a better re-conciliation with IPSec architecture.
 
 
Regards,
 
-Tarique Mustafa


Atul.Sharma@nokia.com wrote:
Hi Francis,

Yes. I agree that an implication of handling the transport case would
be a more integrated MOBIKE (with IPsec Architecture).

Best Regards,
Atul

> -----Original Message-----
> From: Francis.Dupont@enst-bretagne.fr
> [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Monday, September 27, 2004 6:00 PM
> To: Sharma Atul (Nokia-ES/Boston)
> Cc: mobike@machshav.com
> Subject: Re: [Mobike] transport mode document as WG item
>
> case. So, thinking out loud, as far as MOBIKE is concerned
> the mechanism
> should be similar whether we are using tunnel or transport mode?
>
> => no, changing an address in transport mode implies far more than
> in tunnel mode: MOBIKE must be integrated into the whole
> IPsec architecture.
> We can specify something spe cific for transport mode, my
> proposal is to
> put transport mode outside the scope of MOBIKE for the moment.
>

_______________________________________________
Mobike mailing list
Mobike@machshav.com
https://www.machshav.com/mailman/listinfo.cgi/mobike

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage! --0-441993031-1096392547=:41053-- --===============1205054210== 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 --===============1205054210==-- From mobike-bounces@machshav.com Tue Sep 28 14:44:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11153 for ; Tue, 28 Sep 2004 14:44:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BE801FB277; Tue, 28 Sep 2004 14:44:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0B527FB254; Tue, 28 Sep 2004 14:44:40 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3140FFB255; Tue, 28 Sep 2004 14:44:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id ED44EFB252 for ; Tue, 28 Sep 2004 14:44:37 -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 i8SIiS604659; Tue, 28 Sep 2004 21:44:28 +0300 (EET DST) X-Scanned: Tue, 28 Sep 2004 21:43:37 +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 i8SIhbrx020657; Tue, 28 Sep 2004 21:43:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003kpMY6; Tue, 28 Sep 2004 21:43:26 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SIhPS28834; Tue, 28 Sep 2004 21:43:25 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Sep 2004 13:43:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mobike] transport mode document as WG item Date: Tue, 28 Sep 2004 14:43:21 -0400 Message-ID: Thread-Topic: [Mobike] transport mode document as WG item Thread-Index: AcSlgOASvc2PECfyS7et6KIq2zGqjwACVXOg From: To: , X-OriginalArrivalTime: 28 Sep 2004 18:43:22.0977 (UTC) FILETIME=[08325510:01C4A58B] 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: , Content-Type: multipart/mixed; boundary="===============1792753141==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is a multi-part message in MIME format. --===============1792753141== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A58B.0734AC3C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A58B.0734AC3C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Tarique, =20 Do you want transport mode document as MOBIKE WG item? The question = originally posed by Francis.=20 =20 I did not see a whole lot of traffic on the list on this issue. =20 Atul =20 -----Original Message----- From: ext Tarique Mustafa [mailto:tarique_mustafa2000@yahoo.com] Sent: Tuesday, September 28, 2004 1:29 PM To: Sharma Atul (Nokia-ES/Boston); Francis.Dupont@enst-bretagne.fr Cc: mobike@machshav.com Subject: RE: [Mobike] transport mode document as WG item=20 Hi Francis & Atul, =20 As a new-comer I have been silently following this particular trail of = discussions. =20 I absolutely agree that the implications of address change are far = deeper - even may be bit more complicated - in Transport mode than in = Tunnel mode. As such, it may need a better re-conciliation with IPSec = architecture. =20 =20 Regards, =20 -Tarique Mustafa Atul.Sharma@nokia.com wrote: Hi Francis, Yes. I agree that an implication of handling the transport case would be a more integrated MOBIKE (with IPsec Architecture).=20 Best Regards, Atul > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, September 27, 2004 6:00 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: mobike@machshav.com > Subject: Re: [Mobike] transport mode document as WG item=20 >=20 > case. So, thinking out loud, as far as MOBIKE is concerned=20 > the mechanism > should be similar whether we are using tunnel or transport mode? >=20 > =3D> no, changing an address in transport mode implies far more than > in tunnel mode: MOBIKE must be integrated into the whole=20 > IPsec architecture. > We can specify something sp! ecific for transport mode, my=20 > proposal is to > put transport mode outside the scope of MOBIKE for the moment. >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _____ =20 Do you Yahoo!? New = and Improved Yahoo! Mail - 100MB free = storage! ------_=_NextPart_001_01C4A58B.0734AC3C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 Tarique,
 
Do you=20 want transport mode document as MOBIKE WG item? The question=20 originally
posed=20 by Francis.
 
I did=20 not see a whole lot of traffic on the list on this=20 issue.
 
Atul
 
-----Original Message-----
From: ext Tarique = Mustafa=20 [mailto:tarique_mustafa2000@yahoo.com]
Sent: Tuesday, = September 28,=20 2004 1:29 PM
To: Sharma Atul (Nokia-ES/Boston);=20 Francis.Dupont@enst-bretagne.fr
Cc:=20 mobike@machshav.com
Subject: RE: [Mobike] transport mode = document as=20 WG item

Hi Francis & Atul,
 
As a new-comer I have been silently following this particular = trail of=20 discussions.
 
I absolutely agree that the implications of address change are = far deeper=20 - even may be bit more complicated - in Transport mode than in Tunnel = mode. As=20 such, it may need a better re-conciliation with IPSec = architecture.
 
 
Regards,
 
-Tarique Mustafa


Atul.Sharma@nokia.com wrote:
Hi=20 Francis,

Yes. I agree that an implication of handling the = transport=20 case would
be a more integrated MOBIKE (with IPsec Architecture). =

Best Regards,
Atul

> -----Original = Message-----
>=20 From: Francis.Dupont@enst-bretagne.fr
>=20 [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Monday, = September 27,=20 2004 6:00 PM
> To: Sharma Atul (Nokia-ES/Boston)
> Cc:=20 mobike@machshav.com
> Subject: Re: [Mobike] transport mode = document as=20 WG item
>
> case. So, thinking out loud, as far as = MOBIKE is=20 concerned
> the mechanism
> should be similar whether = we are=20 using tunnel or transport mode?
>
> =3D> no, = changing an=20 address in transport mode implies far more than
> in tunnel = mode:=20 MOBIKE must be integrated into the whole
> IPsec=20 architecture.
> We can specify something sp! ecific for = transport=20 mode, my
> proposal is to
> put transport mode outside = the=20 scope of MOBIKE for the moment.
>=20

_______________________________________________
Mobike = mailing=20 = list
Mobike@machshav.com
https://www.machshav.com/mailman/listinfo.= cgi/mobike

Do you Yahoo!?
New=20 and Improved Yahoo! Mail - 100MB free = storage! ------_=_NextPart_001_01C4A58B.0734AC3C-- --===============1792753141== 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 --===============1792753141==-- From mobike-bounces@machshav.com Tue Sep 28 19:50:51 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05754 for ; Tue, 28 Sep 2004 19:50:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6ED4BFB279; Tue, 28 Sep 2004 19:50:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0EF6FB255; Tue, 28 Sep 2004 19:50:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DF583FB262; Tue, 28 Sep 2004 19:50:46 -0400 (EDT) Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by machshav.com (Postfix) with SMTP id 4B9EFFB254 for ; Tue, 28 Sep 2004 19:50:46 -0400 (EDT) Message-ID: <20040928235045.16105.qmail@web41214.mail.yahoo.com> Received: from [67.122.117.214] by web41214.mail.yahoo.com via HTTP; Tue, 28 Sep 2004 16:50:45 PDT Date: Tue, 28 Sep 2004 16:50:45 -0700 (PDT) From: Tarique Mustafa Subject: RE: [Mobike] transport mode document as WG item To: Atul.Sharma@nokia.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: MIME-Version: 1.0 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: , Content-Type: multipart/mixed; boundary="===============1383463890==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============1383463890== Content-Type: multipart/alternative; boundary="0-1363193918-1096415445=:15632" --0-1363193918-1096415445=:15632 Content-Type: text/plain; charset=us-ascii Hi Atul, My suggestion would be to keep transport mode out for the time being. Transport mode is an important scenario with issues of its own. Some time in the near future it will have to be tackled anyways. Regards, -Tarique Mustafa Atul.Sharma@nokia.com wrote: Hello Tarique, Do you want transport mode document as MOBIKE WG item? The question originally posed by Francis. I did not see a whole lot of traffic on the list on this issue. Atul -----Original Message----- From: ext Tarique Mustafa [mailto:tarique_mustafa2000@yahoo.com] Sent: Tuesday, September 28, 2004 1:29 PM To: Sharma Atul (Nokia-ES/Boston); Francis.Dupont@enst-bretagne.fr Cc: mobike@machshav.com Subject: RE: [Mobike] transport mode document as WG item Hi Francis & Atul, As a new-comer I have been silently following this particular trail of discussions. I absolutely agree that the implications of address change are far deeper - even may be bit more complicated - in Transport mode than in Tunnel mode. As such, it may need a better re-conciliation with IPSec architecture. Regards, -Tarique Mustafa Atul.Sharma@nokia.com wrote: Hi Francis, Yes. I agree that an implication of handling the transport case would be a more integrated MOBIKE (with IPsec Architecture). Best Regards, Atul > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, September 27, 2004 6:00 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: mobike@machshav.com > Subject: Re: [Mobike] transport mode document as WG item > > case. So, thinking out loud, as far as MOBIKE is concerned > the mechanism > should be similar whether we are using tunnel or transport mode? > > => no, changing an address in transport mode implies far more than > in tunnel mode: MOBIKE must be integrated into the whole > IPsec architecture. > We can specify something sp! ecific for transport mode, my > proposal is to > put transport mode outside the scope of MOBIKE for the moment. > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! --------------------------------- Do you Yahoo!? vote.yahoo.com - Register online to vote today! --0-1363193918-1096415445=:15632 Content-Type: text/html; charset=us-ascii
Hi Atul,
My suggestion would be to keep transport mode out for the time being.
 
Transport mode is an important scenario with issues of its own. Some time in the near future it will have to be tackled anyways.
 
Regards,
-Tarique Mustafa


Atul.Sharma@nokia.com wrote:
Hello Tarique,
 
Do you want transport mode document as MOBIKE WG item? The question originally
posed by Francis.
 
I did not see a whole lot of traffic on the list on this issue.
 
Atul
 
-----Original Message-----
From: ext Tarique Mustafa [mailto:tarique_mustafa2000@yahoo.com]
Sent: Tuesday, September 28, 2004 1:29 PM
To: Sharma Atul (Nokia-ES/Boston); Francis.Dupont@enst-bretagne.fr
Cc: mobike@machshav.com
Subject: RE: [Mobike] transport mode document as WG item

Hi Francis & Atul,
 
As a new-comer I have been silently following this particular trail of discussions.
 
I absolutely agree that the implications of address change are far deeper - even may be bit more complicated - in Transport mode than in Tunnel mode. As such, it may need a better re-conciliation with IPSec architecture.
 
 
Regards,
 
-Tarique Mustafa


Atul.Sharma@nokia.com wrote:
Hi Francis,

Yes. I agree that an implication of handling the transport case would
be a more integrated MOBIKE (with IPsec Architecture).

Best Regards,
Atul

> -----Original Message-----
> From: Francis.Dupont@enst-bretagne.fr
> [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Monday, September 27, 2004 6:00 PM
> To: Sharma Atul (Nokia-ES/Boston)
> Cc: mobike@machshav.com
> Subject: Re: [Mobike] transport mode document as WG item
>
> case. So, thinking out loud, as far as MOBIKE is concerned
> the mechanism
> should be similar whether we are using tunnel or transport mode?
>
> => no, changing an address in transport mode implies far more than
> in tunnel mode: MOBIKE must be integrated into the whole
> IPsec architecture.
> We can specify something sp! ecific for transport mode, my
> proposal is to
> put transport mode outside the scope of MOBIKE for the moment.
>

_______________________________________________
Mobike mailing list
Mobike@machshav.com
https://www.machshav.com/mailman/listinfo.cgi/mobike

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

Do you Yahoo!?
vote.yahoo.com - Register online to vote today! --0-1363193918-1096415445=:15632-- --===============1383463890== 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 --===============1383463890==-- From mobike-bounces@machshav.com Wed Sep 29 04:33:15 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06937 for ; Wed, 29 Sep 2004 04:33:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3B510FB283; Wed, 29 Sep 2004 04:33:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B5412FB277; Wed, 29 Sep 2004 04:33:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A8579FB279; Wed, 29 Sep 2004 04:33:10 -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 4ECC9FB257 for ; Wed, 29 Sep 2004 04:33:09 -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 i8T8WtH17948; Wed, 29 Sep 2004 10:32:55 +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 i8T8WsSj089644; Wed, 29 Sep 2004 10:32:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409290832.i8T8WsSj089644@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tarique Mustafa Subject: Re: [Mobike] transport mode document as WG item In-reply-to: Your message of Tue, 28 Sep 2004 16:50:45 PDT. <20040928235045.16105.qmail@web41214.mail.yahoo.com> Date: Wed, 29 Sep 2004 10:32:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Atul.Sharma@nokia.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: My suggestion would be to keep transport mode out for the time being. => this is exactly what I propose in my draft... Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike