From mailman-bounces@machshav.com Tue Feb 1 00:02:21 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22521 for ; Tue, 1 Feb 2005 00:02:21 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 68799FB2E2; Tue, 1 Feb 2005 05:02:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 31A16FB2ED for ; Tue, 1 Feb 2005 05:01:15 +0000 (UTC) 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: Tue, 01 Feb 2005 05:00:10 +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 Feb 3 04:45:25 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04347 for ; Thu, 3 Feb 2005 04:45:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 49B30FB284; Thu, 3 Feb 2005 09:45:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DE399FB27F; Thu, 3 Feb 2005 09:45:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AE881FB282; Thu, 3 Feb 2005 09:45:21 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id 9DC70FB27D for ; Thu, 3 Feb 2005 09:45:20 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j139jIJ21230 for ; Thu, 3 Feb 2005 11:45:18 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 11:41:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j139fii0019535 for ; Thu, 3 Feb 2005 11:41:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00A2qOlW; Thu, 03 Feb 2005 11:40:13 EET 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 j139eCx22825 for ; Thu, 3 Feb 2005 11:40:12 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 11:40:06 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 11:16:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2005 11:16:35 +0200 Message-ID: Thread-Topic: New issue 19: Same addresses for both directions? Thread-Index: AcUJ0Q7MQTlpPfyVT2Ws8h5XRmcAeQ== From: To: X-OriginalArrivalTime: 03 Feb 2005 09:16:35.0594 (UTC) FILETIME=[0F177EA0:01C509D1] Subject: [Mobike] New issue 19: Same addresses for both directions? 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, The discussion about terminology in the design draft brought=20 up a (somewhat) new issue about whether IPsec traffic in both directions should use the same pair of addresses (in stable situations), or whether each peer makes the selection for its outbound traffic independently. By "stable situations", I mean long periods of time when=20 nothing MOBIKE-related is happening (it's clear that when=20 traffic is being moved from one pair of addresses to another,=20 the peers aren't necessarily synchronized all the time). Some thoughts about this (more welcome, this is very preliminary): - Each peer can have some preferences about, e.g., on=20 which address it wants to receive traffic from the=20 other peer. - Some information about these preferences can be sent to=20 the other peer in MOBIKE payloads. Current proposals have=20 an ordered list of addresses. - Each peer thus has its own preferences, and some limited information about the other's preferences. But the choice is also constrained by what paths happen to work currently. - It seems that this does not yet uniquely determine the pair of addresses that gets used. For instance, assume that peer A prefers address A1 to A2, and peer B prefers address B1 to B2. If, however, the combination A1,B1 does not work, but all others do, A could choose A1,B2 and B could choose B1,A2. - One way to force the same addresses is that one of the peers=20 makes the decision, and tells the other (in MOPO-IKE, it's=20 always the initiator; presumably, some more complex protocol=20 could, e.g., try to negotiate it in the beginning, or choose=20 randomly.) - Another way would be to specify the decision making=20 algorithm in the protocol specification. This would mean that=20 the decision is always based on whatever limited preferences=20 information can be encoded to the payloads (while if one party=20 always makes the decision, it can utilize more information=20 about its own preferences). - More ways to ensure that the same address pair gets chosen=20 might be possible... - But a good question is whether this is necessary at all. My =20 understanding of SCTP is that address selection is left as a=20 policy issue, and since both ends have their own policy, they=20 can end up using different addresses. - In "mobile client connected to VPN gateway" situations,=20 I think it would make sense that the client's preferences (e.g. whether to use WLAN or GPRS) are followed whenever=20 possible. Comments are welcome! (Hannes: perhaps something about this could be added to the design draft as well?) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 3 10:17:07 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01470 for ; Thu, 3 Feb 2005 10:17:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9C62EFB289; Thu, 3 Feb 2005 15:17:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9190AFB282; Thu, 3 Feb 2005 15:17:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1C910FB284; Thu, 3 Feb 2005 15:17:04 +0000 (UTC) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id EDBC1FB27F for ; Thu, 3 Feb 2005 15:17:02 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13FGwJ28765 for ; Thu, 3 Feb 2005 17:17:01 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 17:23:16 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j13FNGMF005396 for ; Thu, 3 Feb 2005 17:23:16 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00QFfGxP; Thu, 03 Feb 2005 17:21:18 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13FANx28192 for ; Thu, 3 Feb 2005 17:10:24 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 09:08:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] New issue 19: Same addresses for both directions? Date: Thu, 3 Feb 2005 10:08:37 -0500 Message-ID: Thread-Topic: New issue 19: Same addresses for both directions? Thread-Index: AcUJ0Q7MQTlpPfyVT2Ws8h5XRmcAeQAK+QJA From: To: , X-OriginalArrivalTime: 03 Feb 2005 15:08:39.0143 (UTC) FILETIME=[3DB54770:01C50A02] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable I think this is interaction of two issues here. I tried to raise this scenario a couple of days ago to Hannes: * Simultaneous change of addresses * Different IKE address pair in the two directions (Asymmetry) My thoughts on these are: * If we have prior knowledge of addresses at the other end, some kind of simultaneous change of addresses can be supported. * For asymmetry, clearly initial IKE negotiations can not support it. (Does it?) In your scenario, at some point in time A1-B1 (or other symmetric pair) IKE negotiations should=20 have succeeded. Question is once IKE has succeeded can MOBIKE, allow such an asymmetry? For how long (at next renegotiations=20 such an asymmetry may not be allowed)? Also, the issue is of more general nature than just restricted to MOBIKE. I have been meaning to raise this issue of asymmetry=20 for sometime to get a new BoF. But am not familiar with the BoF=20 procedure. What do folks on this list think: a new BoF could be requested=20 to handle IKE asymmetry? Clearly issue has more broader implications. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext=20 > Sent: Thursday, February 03, 2005 4:17 AM > To: mobike@machshav.com > Subject: [Mobike] New issue 19: Same addresses for both directions? >=20 >=20 > Hi, >=20 > The discussion about terminology in the design draft brought=20 > up a (somewhat) new issue about whether IPsec traffic in both > directions should use the same pair of addresses (in stable > situations), or whether each peer makes the selection for its > outbound traffic independently. >=20 > By "stable situations", I mean long periods of time when=20 > nothing MOBIKE-related is happening (it's clear that when=20 > traffic is being moved from one pair of addresses to another,=20 > the peers aren't necessarily synchronized all the time). >=20 > Some thoughts about this (more welcome, this is very > preliminary): >=20 > - Each peer can have some preferences about, e.g., on=20 > which address it wants to receive traffic from the=20 > other peer. >=20 > - Some information about these preferences can be sent to=20 > the other peer in MOBIKE payloads. Current proposals have=20 > an ordered list of addresses. >=20 > - Each peer thus has its own preferences, and some limited > information about the other's preferences. But the choice > is also constrained by what paths happen to work currently. >=20 > - It seems that this does not yet uniquely determine the pair of > addresses that gets used. For instance, assume that peer A > prefers address A1 to A2, and peer B prefers address B1 to B2. > If, however, the combination A1,B1 does not work, but all > others do, A could choose A1,B2 and B could choose B1,A2. >=20 > - One way to force the same addresses is that one of the peers=20 > makes the decision, and tells the other (in MOPO-IKE, it's=20 > always the initiator; presumably, some more complex protocol=20 > could, e.g., try to negotiate it in the beginning, or choose=20 > randomly.) >=20 > - Another way would be to specify the decision making=20 > algorithm in the protocol specification. This would mean that=20 > the decision is always based on whatever limited preferences=20 > information can be encoded to the payloads (while if one party=20 > always makes the decision, it can utilize more information=20 > about its own preferences). >=20 > - More ways to ensure that the same address pair gets chosen=20 > might be possible... >=20 > - But a good question is whether this is necessary at all. My =20 > understanding of SCTP is that address selection is left as a=20 > policy issue, and since both ends have their own policy, they=20 > can end up using different addresses. >=20 > - In "mobile client connected to VPN gateway" situations,=20 > I think it would make sense that the client's preferences > (e.g. whether to use WLAN or GPRS) are followed whenever=20 > possible. >=20 > Comments are welcome! >=20 > (Hannes: perhaps something about this could be added to the > design draft as well?) >=20 > Best regards, > 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 Feb 3 11:04:02 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09038 for ; Thu, 3 Feb 2005 11:04:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8EAF7FB285; Thu, 3 Feb 2005 16:04:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3D3AAFB282; Thu, 3 Feb 2005 16:04:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8D2C8FB284; Thu, 3 Feb 2005 16:03:59 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 8AA06FB27F for ; Thu, 3 Feb 2005 16:03:58 +0000 (UTC) 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 j13G3uc12785 for ; Thu, 3 Feb 2005 18:03:56 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 18:01:51 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j13G1pNX022724 for ; Thu, 3 Feb 2005 18:01:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00I89C5v; Thu, 03 Feb 2005 18:01:50 EET 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 j13G17U09351 for ; Thu, 3 Feb 2005 18:01:07 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 17:44:05 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 17:44:06 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 17:44:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] New issue 19: Same addresses for both directions? Date: Thu, 3 Feb 2005 17:44:05 +0200 Message-ID: Thread-Topic: New issue 19: Same addresses for both directions? Thread-Index: AcUJ0Q7MQTlpPfyVT2Ws8h5XRmcAeQAK+QJAAAGxVLA= From: To: , X-OriginalArrivalTime: 03 Feb 2005 15:44:06.0345 (UTC) FILETIME=[319E8B90:01C50A07] 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 Atul Sharma writes: >=20 > I think this is interaction of two issues here. I tried > to raise this scenario a couple of days ago to Hannes: > > * Simultaneous change of addresses > * Different IKE address pair in the two directions (Asymmetry) >=20 > My thoughts on these are: >=20 > * If we have prior knowledge of addresses at the other end, > some kind of simultaneous change of addresses can be=20 > supported. It was already decided a while ago that simultaneous change of addresses will be supported (see issues #13 and #17). > * For asymmetry, clearly initial IKE negotiations can not > support it. (Does it?) In your scenario, at some point in > time A1-B1 (or other symmetric pair) IKE negotiations should=20 > have succeeded. Question is once IKE has succeeded can MOBIKE, > allow such an asymmetry? For how long (at next renegotiations=20 > such an asymmetry may not be allowed)? Hmm... issue 19 is about asymmetry for IPsec traffic (ESP/AH), not IKEv2/MOBIKE messages (I don't think anyone is proposing=20 breaking the rule that IKE responses are sent to the same=20 address the request came from). If the MOBIKE protocol ends up sending all addresses of both parties in the initial IKE negotiations (IKE_SA_INIT/IKE_AUTH), and each peer selects the addresses for outbound IPsec SAs independently, then conceivably asymmetry could happen=20 even at that point. > Also, the issue is of more general nature than just=20 > restricted to MOBIKE. I have been meaning to raise this=20 > issue of asymmetry for sometime to get a new BoF. But am=20 > not familiar with the BoF procedure. >=20 > What do folks on this list think: a new BoF could be=20 > requested to handle IKE asymmetry? Clearly issue has=20 > more broader implications. The BoF procedure is explained in RFC 2418. But I don't=20 quite see why a BoF would be better place than MOBIKE WG to discuss this? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 3 11:57:02 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14943 for ; Thu, 3 Feb 2005 11:57:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B81CAFB28B; Thu, 3 Feb 2005 16:56:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5B033FB286; Thu, 3 Feb 2005 16:56:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AE6C5FB289; Thu, 3 Feb 2005 16:56:47 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 9BFC3FB282 for ; Thu, 3 Feb 2005 16:56:46 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13Gufc20199 for ; Thu, 3 Feb 2005 18:56:43 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 19:03:20 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j13H3KeU001408 for ; Thu, 3 Feb 2005 19:03:20 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00yGVTBg; Thu, 03 Feb 2005 18:32:31 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13GKNU01853 for ; Thu, 3 Feb 2005 18:20:24 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 10:15:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] New issue 19: Same addresses for both directions? Date: Thu, 3 Feb 2005 11:15:07 -0500 Message-ID: Thread-Topic: New issue 19: Same addresses for both directions? Thread-Index: AcUJ0Q7MQTlpPfyVT2Ws8h5XRmcAeQAK+QJAAAGxVLAAAY9jsA== From: To: , X-OriginalArrivalTime: 03 Feb 2005 16:15:09.0133 (UTC) FILETIME=[87ED6FD0:01C50A0B] 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, Response inline. Best, Atul > -----Original Message----- > From: Eronen Pasi (Nokia-NRC/Helsinki)=20 > Sent: Thursday, February 03, 2005 10:44 AM > To: Sharma Atul (Nokia-ES/Boston); mobike@machshav.com > Subject: RE: [Mobike] New issue 19: Same addresses for both=20 > directions? >=20 >=20 > Atul Sharma writes: > >=20 > > I think this is interaction of two issues here. I tried > > to raise this scenario a couple of days ago to Hannes: > > > > * Simultaneous change of addresses > > * Different IKE address pair in the two directions (Asymmetry) > >=20 > > My thoughts on these are: > >=20 > > * If we have prior knowledge of addresses at the other end, > > some kind of simultaneous change of addresses can be=20 > > supported. >=20 > It was already decided a while ago that simultaneous change > of addresses will be supported (see issues #13 and #17). I agree. I was referring that this scenario is result of two issues. Not that issue of simultaneous address change has not been agreed upon. > > * For asymmetry, clearly initial IKE negotiations can not > > support it. (Does it?) In your scenario, at some point in > > time A1-B1 (or other symmetric pair) IKE negotiations should=20 > > have succeeded. Question is once IKE has succeeded can MOBIKE, > > allow such an asymmetry? For how long (at next renegotiations=20 > > such an asymmetry may not be allowed)? >=20 > Hmm... issue 19 is about asymmetry for IPsec traffic (ESP/AH), > not IKEv2/MOBIKE messages (I don't think anyone is proposing=20 > breaking the rule that IKE responses are sent to the same=20 > address the request came from). >=20 > If the MOBIKE protocol ends up sending all addresses of both > parties in the initial IKE negotiations (IKE_SA_INIT/IKE_AUTH), > and each peer selects the addresses for outbound IPsec SAs > independently, then conceivably asymmetry could happen=20 > even at that point. That would mean in SAD the incoming and outgoing SAs of the same SA pair can have different tunnel endpoints. Now that in the=20 incoming direction a variation of src,dst addresses can be used for searching an SA, we may have to match the src,dst of the IPsec traffic in both direction. I do not know if such an asymmetry is allowed on IPsec traffic (we agree it is not allowed on IKE/MOBIKE traffic). > > Also, the issue is of more general nature than just=20 > > restricted to MOBIKE. I have been meaning to raise this=20 > > issue of asymmetry for sometime to get a new BoF. But am=20 > > not familiar with the BoF procedure. > >=20 > > What do folks on this list think: a new BoF could be=20 > > requested to handle IKE asymmetry? Clearly issue has=20 > > more broader implications. >=20 > The BoF procedure is explained in RFC 2418. But I don't=20 > quite see why a BoF would be better place than MOBIKE WG > to discuss this? Because it has implications for other scenarios as well, for example a Mobile IP End-to-End Asymmetric Security. > Best regards, > Pasi >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Feb 4 04:17:34 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05105 for ; Fri, 4 Feb 2005 04:17:34 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5158AFB289; Fri, 4 Feb 2005 09:17:27 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 19399FB27F; Fri, 4 Feb 2005 09:17:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B7EA8FB282; Fri, 4 Feb 2005 09:17:23 +0000 (UTC) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 894CDFB27D for ; Fri, 4 Feb 2005 09:17:22 +0000 (UTC) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j149HIO06100 for ; Fri, 4 Feb 2005 11:17:18 +0200 (EET) X-Scanned: Fri, 4 Feb 2005 11:15:09 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j149F969014780 for ; Fri, 4 Feb 2005 11:15:09 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00vmdU6L; Fri, 04 Feb 2005 11:11:49 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j149Bmx11908 for ; Fri, 4 Feb 2005 11:11:48 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Feb 2005 11:10:47 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Feb 2005 11:00:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] New issue 19: Same addresses for both directions? Date: Fri, 4 Feb 2005 11:00:44 +0200 Message-ID: Thread-Topic: New issue 19: Same addresses for both directions? Thread-Index: AcUJ0Q7MQTlpPfyVT2Ws8h5XRmcAeQAK+QJAAAGxVLAAAY9jsAAi57Lg From: To: , X-OriginalArrivalTime: 04 Feb 2005 09:00:45.0466 (UTC) FILETIME=[032F37A0:01C50A98] 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 Atul Sharma wrote: > > > Hmm... issue 19 is about asymmetry for IPsec traffic (ESP/AH), > > not IKEv2/MOBIKE messages (I don't think anyone is proposing=20 > > breaking the rule that IKE responses are sent to the same=20 > > address the request came from). > >=20 > > If the MOBIKE protocol ends up sending all addresses of both > > parties in the initial IKE negotiations (IKE_SA_INIT/IKE_AUTH), > > and each peer selects the addresses for outbound IPsec SAs > > independently, then conceivably asymmetry could happen=20 > > even at that point. >=20 > That would mean in SAD the incoming and outgoing SAs of the > same SA pair can have different tunnel endpoints. Now that in > the incoming direction a variation of src,dst addresses can be > used for searching an SA, we may have to match the src,dst of > the IPsec traffic in both direction. I do not know if such an > asymmetry is allowed on IPsec traffic (we agree it is not > allowed on IKE/MOBIKE traffic). Hmm... when searching the right SA for inbound (encrypted) packets, the (outer) src/dst addresses are normally not used=20 in rfc2401bis (unless we have SAs where they're multicast addresses, but that's not possible with IKEv2). So I don't think there's any fundamental problem in the asymmetry (but IMHO trying to keep it symmetric probably will be simpler). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Feb 6 10:46:30 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01848 for ; Sun, 6 Feb 2005 10:46:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E39F1FB28A; Sun, 6 Feb 2005 15:46:29 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 02ED2FB27C; Sun, 6 Feb 2005 15:46:24 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 76F92FB27D; Sun, 6 Feb 2005 15:46:23 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id F1E60FB262 for ; Sun, 6 Feb 2005 15:46:21 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j16FkIJH022849; Sun, 6 Feb 2005 16:46:20 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j16FkIiQ024683; Sun, 6 Feb 2005 16:46:18 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1ATGFTD0>; Sun, 6 Feb 2005 16:46:18 +0100 Message-ID: From: Tschofenig Hannes To: "'Pasi.Eronen@nokia.com'" , mobike@machshav.com Subject: AW: [Mobike] intermediate mobike design draft update Date: Sun, 6 Feb 2005 16:45:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com hi pasi, thanks for your comments. please see my response below: > hannes.tschofenig@siemens.com writes: > > > > hi pasi, > > > > thanks for your feedback. let me give you some comments below: > > > >> Hi, > >> > >> I have some comments and suggestions about the terminology about > >> addresses/pairs/paths in mobike-design-02. > >> > >> 1) > >> > >> Currently the definition of "preferred address pair" is quite > >> imprecise, since it unnecessarily mixes what is preferred with > >> what is actually happening. Also, it's not quite clear what's > >> the difference between "preferred address pair" and "primary > >> path". > >> > >> I'd suggest we replace both of them with a new term, say > >> "current path" (or "current address pair"), that means the > >> addresses that are currently used by the peer as the tunnel > >> header addresses of IPsec packets (of IPsec SAs associated > >> with this IKE SA). > > > > i tried to prevent reinventing new terms here and used the > > term 'preferred address' from > > > > it is true that the definition of preferred address pair and > > primary path point to the same concept. > > > > i have replaced the term "preferred address pair" with > > "primary path". > > Hmm... I think they _don't_ actually point to the same concept... > > "Preferred address" is about preferences, and "preferred address > pair" is just the combination of A's and B's preferred address. > But this is not necessarily always the src/dst address that is > actually put to outbound packets. > > To give a concrete example, suppose that A and B have addresses > A1,A2,B1,B2; A prefers A1 and B prefers B1, and both parties > have "current path" A1,B1. > > Now, suppose that A does dead peer detection and does not get > a response (even after retransmissions). But if A notices that > A2,B2 works, it sounds very reasonable to change the current > path to that (and then do whatever MOBIKE signaling is necessary). > > So, if the "preferred address pair" and "current path" are the > same concept, that seems to imply that one party can change the > other one's preferred address? (But this is not in line with the > current definition of "preferred address"... so I think we have > two different concepts here) > it is true that a) node A cannot force node B to change its preferred address b) we need some terminology to differentiate the different cases. to continue your example above it is necessary for node A to communicate to node B that the preferred address B1 is not operational anymore (node B might have noticed it already). node B certainly needs to switch its preferred address as well, for example to B2. as such you might want to interpret the message transmitted by node A towards node B as a hint to switch its preferred address (if node B hasn't found it out already by some other means). hence, i am not sure whether we should introduce separate terminology for the case where a) node A and node B have synchronized state b) node A and node B do not have synchronized state ideally, the duration of missing state synchronization should be short. hence, we switch from one preferred address pair to another. > > > >> Both peers A and B have their own current path, and they're not > >> always equal (they are never equal if NATs are involved, and > >> even if no NATs are involved, they are different for at least > >> short periods of time when something MOBIKE-related is > >> happening). > > > > it is true that each peer has it's own view of the world and > > there might be an inconsistency of the established state > > information. ideally, the state of the two peers should be > > synchronized. > > I'm not so sure... This is not really a synchronization problem, > but a preference combination problem. Both A and B have their > own preferences, and some information about the other's > preferences. But this does not guarantee that they end up > with the same "current path". before the problem in your example started node A and node B knew that they are reachable at a certain address. additionally the knew that there are some additional addresses that they can used for communication. suddenly node A recognized that a certain path is non-operational anymore. node B might have also recognized it and executes connectivity tests on the available address combinations. after some mobike messages between node A and node B they should both have the same state information again, namely node A and node B are reachable at a certain address pair. i don't know whether the term 'synchronization problem' or 'preference combination problem' is the better term for it. > > For instance, if A prefers A1 to A2, and B prefers B1 to B2; > A1,B1 doesn't work, but both A1,B2 and A2,B1 do, which one > should be the single synchronized "current path"? if a1,b1 does not work then it certainly not be the preferred address pair. the step from the preferred address of each node is not just picking each node's preferred address and to put them together. i think we should make this more explicit in the document. the choice of a preferred address selected by a node might be based on the available bandwidth of the link, cost of the link, etc., or even arbitrarily selected. the choice of a preferred address pair is certainly impacted by the question whether a particular path is operational. > > It seems that if we want both parties to have the same "current > path" (in stable situations), either one party has to make the > decision (like in MOPO-IKE), or the we have to severely restrict > the kinds of preferences that can be used, and give the decision > algorithm in the spec (so that both parties always end up with > the same path). > > (It's of course a good question whether having the same "current > path" in stable situations is necessary or not. I think it > simplifies things, and that's why in MOPO-IKE the initiator's > choice is used in stable situations.) > > > > > > It's a separate question whether the current paths should be > > > equal in stable situations (where NATs are not present). In > > > MOPO-IKE, they are (the responder uses the path selected by the > > > initiator). In SCTP, they're not (each peer makes its selection > > > independently). I'm not sure which is the case for > > > draft-dupont-ikev2-addrmgmt (Francis, could you clarify this?) > > > > regarding sctp there is very little text on how addresses are > > selected (at least i haven't found the text paragraphs). it > > is just a policy issue. since we are concerned about nat > > handling we should talk about bidirectionally operational > > address pairs. > > Yes, I think SCTP leaves address selection as a policy > issue. And since both ends have their own policy, they can end > up using different addresses (even if all address pairs work in > both directions). true. ciao hannes > > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Feb 6 10:47:23 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01923 for ; Sun, 6 Feb 2005 10:47:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 70626FB28F; Sun, 6 Feb 2005 15:47:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8B41AFB27C; Sun, 6 Feb 2005 15:47:19 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BFA2FFB27D; Sun, 6 Feb 2005 15:47:17 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 8B5E0FB262 for ; Sun, 6 Feb 2005 15:47:16 +0000 (UTC) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j16FkDaA021664; Sun, 6 Feb 2005 16:46:13 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j16FkDiQ024670; Sun, 6 Feb 2005 16:46:13 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1ATGFTD8>; Sun, 6 Feb 2005 16:46:13 +0100 Message-ID: From: Tschofenig Hannes To: "'Bora Akyol'" , mobike@machshav.com Subject: AW: [Mobike] latest draft snapshot Date: Sun, 6 Feb 2005 16:44:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com hi bora, please see my comments inline: > Hi > > I also have a few comments on this draft (sorry I am behind > by a few weeks), > and I will classify them into two categories (by the way, the > Jan 29 version > is much better than 01): > > (SG : security gateway) > > 1) Editorial: > > I think in section (3) scenarios, if we had previously > reached consensus > that at a given time only one address pair will be used, then > I recommend > trimming this section down to: > -- Break-before-make address transition > -- Make-before-break address transition: (the bottom two are really > examples of MBB address transition) you mean instead of the differentiation between the three scenarios? 3.1 Mobility Scenario 3.2 Multihoming Scenario 3.3 Multihomed Laptop Scenario or do you want to further differentiate the mobility scenario into sub-sections that provide more details on the break-before-make vs. make-before-break scenario? > > Figure 3: Framework (while being really a nice figure) does > not capture many > implementations and scenarios that are deployed in various > devices today. So > I would consider this figure as an example of a UNIX-centric host > implementation as opposed to > what may end up being deployed in a security gateway. I > suggest (and I can > help with this), replacing this figure with something > considerably simpler > that has basic building blocks. if you have a suggestion for a better figure please let me know. i am probaly not the best ascii art designer. > > PF_KEY API while being used in the text does not seem to have a direct > reference (quite possibly I missed this). fixed. > > In general, I think rename this draft to be "Framework for > MOBIKE." Then do > a requirements draft that has as little text as possible. i hope that we do not need a requirements draft since we already came quite far and are hopefully finished with the work in mobike. making progress would be a good thing. > > 2) Substantive: > > I disagree strongly with the need to be able to "test > connectivity along a > path > and thereby detect an outage situation" other than what we do > in IKEv2 DPD > today. i have only tried to use a different name for the actual concept used by a particular solution specification. as you have there is the possbility to reuse the dead peer detection mechanism (or a slightly modified version of it). there is nothing more behind this connectivity test - no fancy new mechanism. > With mobile users expected to be in the 1,000,000 range per security > gateway, the amount of state and processing that needs to be > performed is > significant when the SG tries to detect > path changes other than what we do with DPD. If the client > decides to do > this, then it is fine. However, even with DPD, then the SG > needs to try > several IP addresses to see which ones work is a significant > burden on the > SG. Therefore, I would suggest that we clarify > what functionality is required on a client vs security > gateway (yes, this > focuses mostly on the VPN scenario, but that is the main push > for MOBIKE as > far as I understand). i fully understand your concern. based on my clarification above do you see the need for a clarification somewhere in the draft? > > Fundamentally, I think we have three problems that we need to solve: > > 1) Identify a peer regardless of the IP address it chooses to use. > (Not-mutable Peer Identity) yes, but this is an issue for ikev2 or rather for the network architects/users to decide which identity they want to use for authentication. > 2) Change the IP address pairs associated with IPSEC and IKE > SAs while not > impacting the data path significantly. certainly, the address update aims to be efficient. > 3) Clean up resources on both ends of the connection(s) so > that neither end > (but especially the SG is not susceptible to resource outages) which resources do you want to clean up? do you mean when a peer crashes it must be ensured that no orphan states are left behind? > > > I think the framework does a good job of identifying these problems. yes, the working group has done a good job of discussing the various design issues that effect a solution. ciao hannes > > Regards, > > Bora > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Feb 7 13:38:10 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27953 for ; Mon, 7 Feb 2005 13:38:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E368DFB27D; Mon, 7 Feb 2005 18:38:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CDDF7FB24A; Mon, 7 Feb 2005 18:38:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94C8BFB262; Mon, 7 Feb 2005 18:38:04 +0000 (UTC) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by machshav.com (Postfix) with ESMTP id B4328FB246 for ; Mon, 7 Feb 2005 18:38:03 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2005 10:46:23 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j17Ibwq8003913; Mon, 7 Feb 2005 10:37:59 -0800 (PST) Received: from boraw2k05 (dhcp-128-107-176-57.cisco.com [128.107.176.57]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWF78179; Mon, 7 Feb 2005 10:38:00 -0800 (PST) Message-Id: <200502071838.AWF78179@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Tschofenig Hannes'" , Subject: RE: [Mobike] latest draft snapshot Date: Mon, 7 Feb 2005 10:38:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUMYyRJn1CRHfftRv6rOTR9K7xf7wA4CJRQ 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 > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Sunday, February 06, 2005 7:45 AM > To: 'Bora Akyol'; mobike@machshav.com > Subject: AW: [Mobike] latest draft snapshot > > > 1) Editorial: > > > > I think in section (3) scenarios, if we had previously reached > > consensus that at a given time only one address pair will be used, > > then I recommend trimming this section down to: > > -- Break-before-make address transition > > -- Make-before-break address transition: (the bottom two > are really > > examples of MBB address transition) > > you mean instead of the differentiation between the three scenarios? > 3.1 Mobility Scenario > 3.2 Multihoming Scenario > 3.3 Multihomed Laptop Scenario > > or do you want to further differentiate the mobility scenario > into sub-sections that provide more details on the > break-before-make vs. > make-before-break scenario? No actually, I think you should have just two scenarios: break-before-make AND make-before-break these are the root scenarios for MOBIKE from what I can understand. > > > > Figure 3: Framework (while being really a nice figure) does not > > capture many implementations and scenarios that are deployed in > > various devices today. So I would consider this figure as > an example > > of a UNIX-centric host implementation as opposed to what may end up > > being deployed in a security gateway. I suggest (and I can > help with > > this), replacing this figure with something considerably > simpler that > > has basic building blocks. > > if you have a suggestion for a better figure please let me know. > i am probaly not the best ascii art designer. There is nothing wrong with the drawing of the figure, what is wrong with it is that it takes a UNIX centric view of how IPSEC/IKE implementations work. This is what I was trying to point out. > > > > > In general, I think rename this draft to be "Framework for MOBIKE." > > Then do a requirements draft that has as little text as possible. > > i hope that we do not need a requirements draft since we > already came quite far and are hopefully finished with the > work in mobike. making progress would be a good thing. Well, I think the WG has a choice on this, I think this document is suitable as a framework document, for requirements, I think we need a more terse and succint document just pointing out what the implementation needs to do. That is of course my opinion. > > > > > 2) Substantive: > > > > I disagree strongly with the need to be able to "test connectivity > > along a path and thereby detect an outage situation" other > than what > > we do in IKEv2 DPD today. > > i have only tried to use a different name for the actual > concept used by a particular solution specification. as you > have there is the possbility to reuse the dead peer detection > mechanism (or a slightly modified version of it). > > there is nothing more behind this connectivity test - no > fancy new mechanism. Right, but why is this a requirement of __any__ implementation? At best it should remain as an __optional__ capability. > > With mobile users expected to be in the 1,000,000 range per > security > > gateway, the amount of state and processing that needs to > be performed > > is significant when the SG tries to detect path changes other than > > what we do with DPD. If the client decides to do this, then it is > > fine. However, even with DPD, then the SG needs to try several IP > > addresses to see which ones work is a significant burden on the SG. > > Therefore, I would suggest that we clarify what functionality is > > required on a client vs security gateway (yes, this focuses > mostly on > > the VPN scenario, but that is the main push for MOBIKE as far as I > > understand). > > i fully understand your concern. > > based on my clarification above do you see the need for a > clarification somewhere in the draft? > Yes, I think we should point out that for the SG, this capability is optional. > > > > Fundamentally, I think we have three problems that we need to solve: > > > > 1) Identify a peer regardless of the IP address it chooses to use. > > (Not-mutable Peer Identity) > > yes, but this is an issue for ikev2 or rather for the network > architects/users to decide which identity they want to use > for authentication. Regardless of whether this is an IKEv2 issue or not, without this capability, we can not do MOBIKE, right? > > 2) Change the IP address pairs associated with IPSEC and > IKE SAs while > > not impacting the data path significantly. > > certainly, the address update aims to be efficient. > > > 3) Clean up resources on both ends of the connection(s) so that > > neither end (but especially the SG is not susceptible to resource > > outages) > > which resources do you want to clean up? do you mean when a > peer crashes it must be ensured that no orphan states are > left behind? > > > > > > > I think the framework does a good job of identifying these problems. > > yes, the working group has done a good job of discussing the > various design issues that effect a solution. > Thanks Bora _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 10 16:17:16 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12256 for ; Thu, 10 Feb 2005 16:17:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C2589FB284; Thu, 10 Feb 2005 16:17:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A3899FB27C; Thu, 10 Feb 2005 16:17:09 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F18A0FB280; Thu, 10 Feb 2005 16:17:07 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 1F190FB266 for ; Thu, 10 Feb 2005 16:17:06 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j1ALH4aA009526; Thu, 10 Feb 2005 22:17:04 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1ALH4iQ029604; Thu, 10 Feb 2005 22:17:04 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1ATG2B1Y>; Thu, 10 Feb 2005 22:17:03 +0100 Message-ID: From: Tschofenig Hannes To: "'Pasi.Eronen@nokia.com'" , mobike@machshav.com Subject: AW: [Mobike] New issue 19: Same addresses for both directions? Date: Thu, 10 Feb 2005 22:15:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com # hi pasi # thanks for raising this issue. please find my comments inline: Hi, The discussion about terminology in the design draft brought up a (somewhat) new issue about whether IPsec traffic in both directions should use the same pair of addresses (in stable situations), or whether each peer makes the selection for its outbound traffic independently. # this is related to the terms 'Bidirectionally operational address pair' and 'Undirectionally operational address pair' introduced in # this means that we assumed so far that we will mainly focus on bidirectionally operational address pairs since we assumed the possible placement of nats and firewalls along the path. this means two nodes, a and b, communicating with each other communicate in the following fashion: node a node b source ip=a1, destination ip=b1 ------------------------------> source ip=b1 destination ip=a1 <------------------------------ the alternative would be to allow the following communication: node a node b source ip=a1, destination ip=b1 ------------------------------> source ip=b2 destination ip=a3 <------------------------------ # there might not only be an impact with regard to nats and firewalls but also with regard to congestion and path characteristics since routing asymmetry will be quite high if you use different ip addresses (which might belong to different interfaces). By "stable situations", I mean long periods of time when nothing MOBIKE-related is happening (it's clear that when traffic is being moved from one pair of addresses to another, the peers aren't necessarily synchronized all the time). Some thoughts about this (more welcome, this is very preliminary): - Each peer can have some preferences about, e.g., on which address it wants to receive traffic from the other peer. # and each peer will have a preference on the address used for outgoing traffic (because of costs). - Some information about these preferences can be sent to the other peer in MOBIKE payloads. Current proposals have an ordered list of addresses. # yes. - Each peer thus has its own preferences, and some limited information about the other's preferences. But the choice is also constrained by what paths happen to work currently. # yes. - It seems that this does not yet uniquely determine the pair of addresses that gets used. # yes. this was also one of the conclusions of jari's presentation at the last ietf with regard to For instance, assume that peer A prefers address A1 to A2, and peer B prefers address B1 to B2. If, however, the combination A1,B1 does not work, but all others do, A could choose A1,B2 and B could choose B1,A2. # certainly. - One way to force the same addresses is that one of the peers makes the decision, and tells the other (in MOPO-IKE, it's always the initiator; presumably, some more complex protocol could, e.g., try to negotiate it in the beginning, or choose randomly.) # i think it is not uncommon to return an ip packet to the place where it came from. # do you really need to force something? i think it is more likely that you will be able to return a packet when you just send it back to the address where it came from rather than sending it to another address. - Another way would be to specify the decision making algorithm in the protocol specification. This would mean that the decision is always based on whatever limited preferences information can be encoded to the payloads (while if one party always makes the decision, it can utilize more information about its own preferences). # i think that this is not necessary. - More ways to ensure that the same address pair gets chosen might be possible... - But a good question is whether this is necessary at all. My understanding of SCTP is that address selection is left as a policy issue, and since both ends have their own policy, they can end up using different addresses. # that's certainly true. sctp does not care about nats and firewalls. i am not so sure about their security as well. - In "mobile client connected to VPN gateway" situations, I think it would make sense that the client's preferences (e.g. whether to use WLAN or GPRS) are followed whenever possible. # certainly. if we think of a regular scenario then we have the mobile node starting with the communication. the mn will contact the security gateway using the basic ikev2/mobike exchange. as a result the the address pair used by them is already chosen. # now, if the mobile node changes its address then some protocol interactions are necessary. #if the mn has only one interface then the protocol interactions are roughly clear. we can only hope that the security gateway does not remove its state too quickly (e.g, because of the dead peer detection mechanism) to give the mn some chance to complete the network attachment procedures. Comments are welcome! (Hannes: perhaps something about this could be added to the design draft as well?) # i think we should! thanks for the issue. # ciao # hannes 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 Thu Feb 10 16:18:38 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12357 for ; Thu, 10 Feb 2005 16:18:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 57F4CFB282; Thu, 10 Feb 2005 16:18:39 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C6895FB27C; Thu, 10 Feb 2005 16:18:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CBBC3FB280; Thu, 10 Feb 2005 16:18:32 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 24938FB266 for ; Thu, 10 Feb 2005 16:18:31 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j1ALIUJH027271; Thu, 10 Feb 2005 22:18:30 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1ALIUiQ030375; Thu, 10 Feb 2005 22:18:30 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1ATG2B18>; Thu, 10 Feb 2005 22:18:29 +0100 Message-ID: From: Tschofenig Hannes To: "'Atul.Sharma@nokia.com'" , Pasi.Eronen@nokia.com, mobike@machshav.com Subject: AW: [Mobike] New issue 19: Same addresses for both directions? Date: Thu, 10 Feb 2005 22:17:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com # hi atul, I think this is interaction of two issues here. I tried to raise this scenario a couple of days ago to Hannes: * Simultaneous change of addresses # i think we clarified this issue. we came to the conclusion that - if both peers only have one address (or only one address communicated to the other end) then you cannot support a simultaneous address change (without a third party). - in the case where they each peer has more addresses and communicates them to the other peer then a simultaneous address change (without involvement of a third party). # this issue is independent from the issue discussed below. * Different IKE address pair in the two directions (Asymmetry) My thoughts on these are: * If we have prior knowledge of addresses at the other end, some kind of simultaneous change of addresses can be supported. # yes but independent from the aspect of 'bidirectionally operational address pair' and 'undirectionally operational address pair'. * For asymmetry, clearly initial IKE negotiations can not support it. (Does it?) In your scenario, at some point in time A1-B1 (or other symmetric pair) IKE negotiations should have succeeded. Question is once IKE has succeeded can MOBIKE, allow such an asymmetry? For how long (at next renegotiations such an asymmetry may not be allowed)? # ike responds to the address where the request came from. additionally only a single address is supported. hence, there this issue does not appear. Also, the issue is of more general nature than just restricted to MOBIKE. I have been meaning to raise this issue of asymmetry for sometime to get a new BoF. But am not familiar with the BoF procedure. What do folks on this list think: a new BoF could be requested to handle IKE asymmetry? Clearly issue has more broader implications. # i would say 'no'. we cannot make a bof on every issue. # ciao # hannes Atul > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext > Sent: Thursday, February 03, 2005 4:17 AM > To: mobike@machshav.com > Subject: [Mobike] New issue 19: Same addresses for both directions? > > > Hi, > > The discussion about terminology in the design draft brought > up a (somewhat) new issue about whether IPsec traffic in both > directions should use the same pair of addresses (in stable > situations), or whether each peer makes the selection for its > outbound traffic independently. > > By "stable situations", I mean long periods of time when > nothing MOBIKE-related is happening (it's clear that when > traffic is being moved from one pair of addresses to another, > the peers aren't necessarily synchronized all the time). > > Some thoughts about this (more welcome, this is very > preliminary): > > - Each peer can have some preferences about, e.g., on > which address it wants to receive traffic from the > other peer. > > - Some information about these preferences can be sent to > the other peer in MOBIKE payloads. Current proposals have > an ordered list of addresses. > > - Each peer thus has its own preferences, and some limited > information about the other's preferences. But the choice > is also constrained by what paths happen to work currently. > > - It seems that this does not yet uniquely determine the pair of > addresses that gets used. For instance, assume that peer A > prefers address A1 to A2, and peer B prefers address B1 to B2. > If, however, the combination A1,B1 does not work, but all > others do, A could choose A1,B2 and B could choose B1,A2. > > - One way to force the same addresses is that one of the peers > makes the decision, and tells the other (in MOPO-IKE, it's > always the initiator; presumably, some more complex protocol > could, e.g., try to negotiate it in the beginning, or choose > randomly.) > > - Another way would be to specify the decision making > algorithm in the protocol specification. This would mean that > the decision is always based on whatever limited preferences > information can be encoded to the payloads (while if one party > always makes the decision, it can utilize more information > about its own preferences). > > - More ways to ensure that the same address pair gets chosen > might be possible... > > - But a good question is whether this is necessary at all. My > understanding of SCTP is that address selection is left as a > policy issue, and since both ends have their own policy, they > can end up using different addresses. > > - In "mobile client connected to VPN gateway" situations, > I think it would make sense that the client's preferences > (e.g. whether to use WLAN or GPRS) are followed whenever > possible. > > Comments are welcome! > > (Hannes: perhaps something about this could be added to the > design draft as well?) > > 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 Thu Feb 10 16:19:13 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12423 for ; Thu, 10 Feb 2005 16:19:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A2B44FB28B; Thu, 10 Feb 2005 16:19:13 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 665AFFB286; Thu, 10 Feb 2005 16:19:08 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AB944FB286; Thu, 10 Feb 2005 16:19:06 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id B379EFB266 for ; Thu, 10 Feb 2005 16:19:04 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j1ALIqJH027424; Thu, 10 Feb 2005 22:18:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1ALIqiQ030582; Thu, 10 Feb 2005 22:18:52 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1ATG2BFA>; Thu, 10 Feb 2005 22:18:51 +0100 Message-ID: From: Tschofenig Hannes To: "'Bora Akyol'" , mobike@machshav.com Subject: AW: [Mobike] latest draft snapshot Date: Thu, 10 Feb 2005 22:17:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com # hi bora, # please see my comments below; > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Sunday, February 06, 2005 7:45 AM > To: 'Bora Akyol'; mobike@machshav.com > Subject: AW: [Mobike] latest draft snapshot > > > 1) Editorial: > > > > I think in section (3) scenarios, if we had previously reached > > consensus that at a given time only one address pair will be used, > > then I recommend trimming this section down to: > > -- Break-before-make address transition > > -- Make-before-break address transition: (the bottom two > are really > > examples of MBB address transition) > > you mean instead of the differentiation between the three scenarios? > 3.1 Mobility Scenario > 3.2 Multihoming Scenario > 3.3 Multihomed Laptop Scenario > > or do you want to further differentiate the mobility scenario > into sub-sections that provide more details on the > break-before-make vs. > make-before-break scenario? No actually, I think you should have just two scenarios: break-before-make AND make-before-break these are the root scenarios for MOBIKE from what I can understand. # i am not quite sure. in a multi-homing environment there is no notion of break-before-make or make-before-break. hence, why don't we stay with the original scenarios where we have multi-homing, mobility and the combination of both? > > > > Figure 3: Framework (while being really a nice figure) does not > > capture many implementations and scenarios that are deployed in > > various devices today. So I would consider this figure as > an example > > of a UNIX-centric host implementation as opposed to what may end up > > being deployed in a security gateway. I suggest (and I can > help with > > this), replacing this figure with something considerably > simpler that > > has basic building blocks. > > if you have a suggestion for a better figure please let me know. > i am probaly not the best ascii art designer. There is nothing wrong with the drawing of the figure, what is wrong with it is that it takes a UNIX centric view of how IPSEC/IKE implementations work. This is what I was trying to point out. # do you think we would be fine if we write a sentence below the figure? something like: "this figure is only one way of implementing mobike in a system. it serves illustrative purposes only." # i don't want to redraw the figure - ascii drawing takes such a long time... > > > > > In general, I think rename this draft to be "Framework for MOBIKE." > > Then do a requirements draft that has as little text as possible. > > i hope that we do not need a requirements draft since we > already came quite far and are hopefully finished with the > work in mobike. making progress would be a good thing. Well, I think the WG has a choice on this, I think this document is suitable as a framework document, for requirements, I think we need a more terse and succint document just pointing out what the implementation needs to do. That is of course my opinion. # i would like to make some progress in the working group. we are already spend far too long on the existing work. # if there are some requirements which we haven't discussed then they should be included in the current document. # regarding the implementation requirements: the specs should provide information on what is MUST, SHOULD or MAY. > > > > > 2) Substantive: > > > > I disagree strongly with the need to be able to "test connectivity > > along a path and thereby detect an outage situation" other > than what > > we do in IKEv2 DPD today. > > i have only tried to use a different name for the actual > concept used by a particular solution specification. as you > have there is the possbility to reuse the dead peer detection > mechanism (or a slightly modified version of it). > > there is nothing more behind this connectivity test - no > fancy new mechanism. Right, but why is this a requirement of __any__ implementation? At best it should remain as an __optional__ capability. # i think that dead peer detection is already a mandatory implementation feature in ikev2. # if we use this approach (or a slightly modified version) then i don't really see a big problem. # what do you fear? the implementation overhead - not really? > > With mobile users expected to be in the 1,000,000 range per > security > > gateway, the amount of state and processing that needs to > be performed > > is significant when the SG tries to detect path changes other than > > what we do with DPD. If the client decides to do this, then it is > > fine. However, even with DPD, then the SG needs to try several IP > > addresses to see which ones work is a significant burden on the SG. > > Therefore, I would suggest that we clarify what functionality is > > required on a client vs security gateway (yes, this focuses > mostly on > > the VPN scenario, but that is the main push for MOBIKE as far as I > > understand). > > i fully understand your concern. > > based on my clarification above do you see the need for a > clarification somewhere in the draft? > Yes, I think we should point out that for the SG, this capability is optional. # a connectivity test does not work if only one entity supports it. # furthermore, you can already use dead peer detection or other messages that perform the same function already today. # what is the problem? > > > > Fundamentally, I think we have three problems that we need to solve: > > > > 1) Identify a peer regardless of the IP address it chooses to use. > > (Not-mutable Peer Identity) > > yes, but this is an issue for ikev2 or rather for the network > architects/users to decide which identity they want to use > for authentication. Regardless of whether this is an IKEv2 issue or not, without this capability, we can not do MOBIKE, right? # that's true and it is true for all mobility protocol (mobile ip, for example). > > 2) Change the IP address pairs associated with IPSEC and > IKE SAs while > > not impacting the data path significantly. > > certainly, the address update aims to be efficient. > > > 3) Clean up resources on both ends of the connection(s) so that > > neither end (but especially the SG is not susceptible to resource > > outages) > > which resources do you want to clean up? do you mean when a > peer crashes it must be ensured that no orphan states are > left behind? > > > > > > > I think the framework does a good job of identifying these problems. > > yes, the working group has done a good job of discussing the > various design issues that effect a solution. > # ciao # hannes Thanks Bora _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 10 17:49:41 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01473 for ; Thu, 10 Feb 2005 17:49:41 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 500B8FB286; Thu, 10 Feb 2005 17:49:42 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2818FFB27C; Thu, 10 Feb 2005 17:49:36 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BE7DAFB280; Thu, 10 Feb 2005 17:49:33 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by machshav.com (Postfix) with ESMTP id C6B59FB266 for ; Thu, 10 Feb 2005 17:49:31 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 10 Feb 2005 15:00:11 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,193,1102320000"; d="scan'208"; a="613724385:sNHT29327320" Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1AMnQuC002256; Thu, 10 Feb 2005 14:49:27 -0800 (PST) Received: from boraw2k05 ([10.32.241.199]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWJ10912; Thu, 10 Feb 2005 14:49:27 -0800 (PST) Message-Id: <200502102249.AWJ10912@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Tschofenig Hannes'" , Subject: RE: [Mobike] latest draft snapshot Date: Thu, 10 Feb 2005 14:49:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUPtjLCVGv4hfR5RMiCJsxPWXDRlgAC8Egw In-Reply-To: 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 See inline: > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, February 10, 2005 1:18 PM > To: 'Bora Akyol'; mobike@machshav.com > Subject: AW: [Mobike] latest draft snapshot > > > # hi bora, > > # please see my comments below; > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Sunday, February 06, 2005 7:45 AM > > To: 'Bora Akyol'; mobike@machshav.com > > Subject: AW: [Mobike] latest draft snapshot > > > > > > 1) Editorial: > > > > > > I think in section (3) scenarios, if we had previously reached > > > consensus that at a given time only one address pair will > be used, > > > then I recommend trimming this section down to: > > > -- Break-before-make address transition > > > -- Make-before-break address transition: (the bottom two > > are really > > > examples of MBB address transition) > > > > you mean instead of the differentiation between the three scenarios? > > 3.1 Mobility Scenario > > 3.2 Multihoming Scenario > > 3.3 Multihomed Laptop Scenario > > > > or do you want to further differentiate the mobility scenario into > > sub-sections that provide more details on the break-before-make vs. > > make-before-break scenario? > > No actually, I think you should have just two scenarios: > > break-before-make AND > make-before-break > > these are the root scenarios for MOBIKE from what I can understand. > > # i am not quite sure. in a multi-homing environment there is > no notion of break-before-make or make-before-break. > hence, why don't we stay with the original scenarios where we > have multi-homing, mobility and the combination of both? Bora: From a functionality perspective, there really are two cases IMHO you either do MBB or BBM, are there any other. If I were writing software for this, I will code functionality which is two. > > > > > > > Figure 3: Framework (while being really a nice figure) does not > > > capture many implementations and scenarios that are deployed in > > > various devices today. So I would consider this figure as > > an example > > > of a UNIX-centric host implementation as opposed to what > may end up > > > being deployed in a security gateway. I suggest (and I can > > help with > > > this), replacing this figure with something considerably > > simpler that > > > has basic building blocks. > > > > if you have a suggestion for a better figure please let me know. > > i am probaly not the best ascii art designer. > > There is nothing wrong with the drawing of the figure, what > is wrong with it is that it takes a UNIX centric view of how > IPSEC/IKE implementations work. > > This is what I was trying to point out. > > # do you think we would be fine if we write a sentence below > the figure? > something like: > "this figure is only one way of implementing mobike in a > system. it serves illustrative purposes only." Bora: Sounds good to me > > # i don't want to redraw the figure - ascii drawing takes > such a long time... ;-) > > > > > > > > > In general, I think rename this draft to be "Framework > for MOBIKE." > > > Then do a requirements draft that has as little text as possible. > > > > i hope that we do not need a requirements draft since we > already came > > quite far and are hopefully finished with the work in > mobike. making > > progress would be a good thing. > > Well, I think the WG has a choice on this, I think this > document is suitable as a framework document, for > requirements, I think we need a more terse and succint > document just pointing out what the implementation needs to > do. That is of course my opinion. > > # i would like to make some progress in the working group. we > are already spend far too long on the existing work. > # if there are some requirements which we haven't discussed > then they should be included in the current document. > # regarding the implementation requirements: the specs should > provide information on what is MUST, SHOULD or MAY. > OK > > > > > > > > 2) Substantive: > > > > > > I disagree strongly with the need to be able to "test > connectivity > > > along a path and thereby detect an outage situation" other > > than what > > > we do in IKEv2 DPD today. > > > > i have only tried to use a different name for the actual > concept used > > by a particular solution specification. as you have there is the > > possbility to reuse the dead peer detection mechanism (or a > slightly > > modified version of it). > > > > there is nothing more behind this connectivity test - no fancy new > > mechanism. > > Right, but why is this a requirement of __any__ implementation? > At best it should remain as an __optional__ capability. > > # i think that dead peer detection is already a mandatory > implementation feature in ikev2. Yes > # if we use this approach (or a slightly modified version) > then i don't really see a big problem. The problem is not doing DPD, but doing DPD as a way of deciding which path to follow for each user, this is an unnecessary burden on the security gateway esp. one that supports on the order of 500,000 or more users. Simple rule: If a client wants to keep their session up, they need to notify the gw, otherwise, the gateway will not actively probe for alternate paths, IP addr, etc. > # what do you fear? the implementation overhead - not really? Scalability. > > > > With mobile users expected to be in the 1,000,000 range per > > security > > > gateway, the amount of state and processing that needs to > > be performed > > > is significant when the SG tries to detect path changes > other than > > > what we do with DPD. If the client decides to do this, then it is > > > fine. However, even with DPD, then the SG needs to try several IP > > > addresses to see which ones work is a significant burden > on the SG. > > > Therefore, I would suggest that we clarify what functionality is > > > required on a client vs security gateway (yes, this focuses > > mostly on > > > the VPN scenario, but that is the main push for MOBIKE as > far as I > > > understand). > > > > i fully understand your concern. > > > > based on my clarification above do you see the need for a > > clarification somewhere in the draft? > > > > Yes, I think we should point out that for the SG, this > capability is optional. > > # a connectivity test does not work if only one entity supports it. > # furthermore, you can already use dead peer detection or > other messages that perform the same function already today. > # what is the problem? The problem is not DPD, that works, the problem is for a gateway to be responsible for tracking clients, trying alternate IP addresses etc. This does not scale, it makes the standards cumbersome. I would rather have the client be responsible for notifications. > > > > > > > Fundamentally, I think we have three problems that we > need to solve: > > > > > > 1) Identify a peer regardless of the IP address it chooses to use. > > > (Not-mutable Peer Identity) > > > > yes, but this is an issue for ikev2 or rather for the network > > architects/users to decide which identity they want to use for > > authentication. > > Regardless of whether this is an IKEv2 issue or not, without > this capability, we can not do MOBIKE, right? > > # that's true and it is true for all mobility protocol > (mobile ip, for example). Mobile IP does not rely on IKE. It actually has an IP address that never changes in its home IP address. Mobike does not have that luxury. > > > 2) Change the IP address pairs associated with IPSEC and > > IKE SAs while > > > not impacting the data path significantly. > > > > certainly, the address update aims to be efficient. > > > > > 3) Clean up resources on both ends of the connection(s) so that > > > neither end (but especially the SG is not susceptible to resource > > > outages) > > > > which resources do you want to clean up? do you mean when a peer > > crashes it must be ensured that no orphan states are left behind? > > > > > > > > > > > I think the framework does a good job of identifying > these problems. > > > > yes, the working group has done a good job of discussing > the various > > design issues that effect a solution. > > > > # ciao > # hannes > > > Thanks > > Bora > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Feb 11 09:50:33 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02624 for ; Fri, 11 Feb 2005 09:50:32 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6114EFB280; Fri, 11 Feb 2005 09:50:31 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4D81FB24A; Fri, 11 Feb 2005 09:50:25 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A78FEFB277; Fri, 11 Feb 2005 09:50:23 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 26E00FB246 for ; Fri, 11 Feb 2005 09:50:22 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1BEoJc05734; Fri, 11 Feb 2005 16:50:19 +0200 (EET) X-Scanned: Fri, 11 Feb 2005 16:48:56 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1BEmuNL019344; Fri, 11 Feb 2005 16:48:56 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00snorBB; Fri, 11 Feb 2005 16:48:39 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1BEmOM09490; Fri, 11 Feb 2005 16:48:25 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Feb 2005 08:47:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] New issue 19: Same addresses for both directions? Date: Fri, 11 Feb 2005 09:47:35 -0500 Message-ID: Thread-Topic: [Mobike] New issue 19: Same addresses for both directions? Thread-Index: AcUPtoza6ywJYenvRaKOxfjwfKNDEQAkQurA From: To: , , X-OriginalArrivalTime: 11 Feb 2005 14:47:36.0780 (UTC) FILETIME=[A095F8C0:01C51048] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Hannes, Comments inline. Atul > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, February 10, 2005 4:17 PM > To: Sharma Atul (Nokia-ES/Boston); Eronen Pasi (Nokia-NRC/Helsinki); > mobike@machshav.com > Subject: AW: [Mobike] New issue 19: Same addresses for both=20 > directions? >=20 >=20 > # hi atul,=20 >=20 > I think this is interaction of two issues here. I tried > to raise this scenario a couple of days ago to Hannes: > * Simultaneous change of addresses >=20 > # i think we clarified this issue. we came to the conclusion that > - if both peers only have one address (or only one address=20 > communicated to > the other end) then you cannot support a simultaneous address change > (without a third party).=20 > - in the case where they each peer has more addresses and=20 > communicates them > to the other peer then a simultaneous address change (without=20 > involvement of > a third party). =20 >=20 > # this issue is independent from the issue discussed below.=20 The issues are independent. But the scenario Pasi was talking about involved interaction of two issues: (1) Simultaneous change in addresses and (2) ASYMMETRICALLY doing (1) This is all I was refering to. > * Different IKE address pair in the two directions (Asymmetry) >=20 > My thoughts on these are: >=20 > * If we have prior knowledge of addresses at the other end, > some kind of simultaneous change of addresses can be=20 > supported. >=20 > # yes but independent from the aspect of 'bidirectionally operational > address pair' and=20 > 'undirectionally operational address pair'.=20 >=20 > * For asymmetry, clearly initial IKE negotiations can not > support it. (Does it?) In your scenario, at some point in > time A1-B1 (or other symmetric pair) IKE negotiations should=20 > have succeeded. Question is once IKE has succeeded can MOBIKE, > allow such an asymmetry? For how long (at next renegotiations=20 > such an asymmetry may not be allowed)? >=20 > # ike responds to the address where the request came from.=20 > additionally only > a single address is supported. hence, there this issue does=20 > not appear.=20 > =20 >=20 > Also, the issue is of more general nature than just restricted > to MOBIKE. I have been meaning to raise this issue of=20 > asymmetry=20 > for sometime to get a new BoF. But am not familiar=20 > with the BoF=20 > procedure. >=20 > What do folks on this list think: a new BoF could be=20 > requested=20 > to handle IKE asymmetry? Clearly issue has more broader > implications. > # i would say 'no'. we cannot make a bof on every issue.=20 The issue is a major one, namely that of "Asymmetric Security". = Asymmetry could be in tunnel endpoint addresses (like discussed here); or = asymmetry could be in the tunnels (not discussed here); or asymmetry in the = gateways participating in secure transmission (not discussed here). > # ciao > # hannes >=20 >=20 > Atul >=20 > > -----Original Message----- > > From: mobike-bounces@machshav.com=20 > > [mailto:mobike-bounces@machshav.com]On > > Behalf Of ext=20 > > Sent: Thursday, February 03, 2005 4:17 AM > > To: mobike@machshav.com > > Subject: [Mobike] New issue 19: Same addresses for both directions? > >=20 > >=20 > > Hi, > >=20 > > The discussion about terminology in the design draft brought=20 > > up a (somewhat) new issue about whether IPsec traffic in both > > directions should use the same pair of addresses (in stable > > situations), or whether each peer makes the selection for its > > outbound traffic independently. > >=20 > > By "stable situations", I mean long periods of time when=20 > > nothing MOBIKE-related is happening (it's clear that when=20 > > traffic is being moved from one pair of addresses to another,=20 > > the peers aren't necessarily synchronized all the time). > >=20 > > Some thoughts about this (more welcome, this is very > > preliminary): > >=20 > > - Each peer can have some preferences about, e.g., on=20 > > which address it wants to receive traffic from the=20 > > other peer. > >=20 > > - Some information about these preferences can be sent to=20 > > the other peer in MOBIKE payloads. Current proposals have=20 > > an ordered list of addresses. > >=20 > > - Each peer thus has its own preferences, and some limited > > information about the other's preferences. But the choice > > is also constrained by what paths happen to work currently. > >=20 > > - It seems that this does not yet uniquely determine the pair of > > addresses that gets used. For instance, assume that peer A > > prefers address A1 to A2, and peer B prefers address B1 to B2. > > If, however, the combination A1,B1 does not work, but all > > others do, A could choose A1,B2 and B could choose B1,A2. > >=20 > > - One way to force the same addresses is that one of the peers=20 > > makes the decision, and tells the other (in MOPO-IKE, it's=20 > > always the initiator; presumably, some more complex protocol=20 > > could, e.g., try to negotiate it in the beginning, or choose=20 > > randomly.) > >=20 > > - Another way would be to specify the decision making=20 > > algorithm in the protocol specification. This would mean that=20 > > the decision is always based on whatever limited preferences=20 > > information can be encoded to the payloads (while if one party=20 > > always makes the decision, it can utilize more information=20 > > about its own preferences). > >=20 > > - More ways to ensure that the same address pair gets chosen=20 > > might be possible... > >=20 > > - But a good question is whether this is necessary at all. My =20 > > understanding of SCTP is that address selection is left as a=20 > > policy issue, and since both ends have their own policy, they=20 > > can end up using different addresses. > >=20 > > - In "mobile client connected to VPN gateway" situations,=20 > > I think it would make sense that the client's preferences > > (e.g. whether to use WLAN or GPRS) are followed whenever=20 > > possible. > >=20 > > Comments are welcome! > >=20 > > (Hannes: perhaps something about this could be added to the > > design draft as well?) > >=20 > > Best regards, > > 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 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Feb 11 10:36:54 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08503 for ; Fri, 11 Feb 2005 10:36:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 31894FB281; Fri, 11 Feb 2005 10:36:55 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 529A7FB24A; Fri, 11 Feb 2005 10:36:52 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EA498FB277; Fri, 11 Feb 2005 10:36:49 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id D5288FB246 for ; Fri, 11 Feb 2005 10:36:48 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1BFaic16638; Fri, 11 Feb 2005 17:36:44 +0200 (EET) X-Scanned: Fri, 11 Feb 2005 17:44:19 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1BFiJdY032446; Fri, 11 Feb 2005 17:44:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00BRiSQc; Fri, 11 Feb 2005 17:44:18 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1BFWNM29739; Fri, 11 Feb 2005 17:32:23 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Feb 2005 09:30:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2005 10:30:22 -0500 Message-ID: Thread-Topic: Asymmetric Security Thread-Index: AcUQTpnUEz8hOuQbS/i127voUDpGJA== From: To: , X-OriginalArrivalTime: 11 Feb 2005 15:30:24.0061 (UTC) FILETIME=[9ACDF6D0:01C5104E] Subject: [Mobike] Asymmetric Security 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 All, I wanted to start a discussion on Asymmetric Security. Asymmetry can show up in different ways in a secure transmission. For = example: * we can have asymmetry in the gateways involved in secure = transmission.=20 * we can have asymmetry in the tunnels between two possible multihomed=20 gateways * we can have asymmetry in the tunnel endpoints of the a tunnel (1) Asymmetry in Gateways:=20 Let us say there are three gateways A, B, C. In the forward direction = secure traffic=20 flows from Gateway A to Gateway B. In the reverse direction traffic = flows from=20 Gateway C to Gateway A. A Mobile IP End-to-End Security between a=20 correspondent node and a mobile node will be an example scenario here. IKE negotiations between A and B can setup a tunnel and IKE negotiations between C and A can set up the tunnels. Both the tunnels shall still = protect the same hosts/addresses. [Since IKE negotiations do not allow asymmetry we = will have to have two separate IKE negotiations] (2) Asymmetry in Tunnels: Let us say there are two multihomed Gateways. These gateways negotiate = TWO=20 tunnels, each with different tunnel endpoints (corresponding to = multihomed addresses). But both the tunnels still protecting the same hosts/addresses. This can = be a real life scenario to acheive redundancy/high availability (3) Asymmetry in Tunnel Endpoints Let us say there are two multihome Gateways. These gateways negotiate = ONE tunnel, but with different tunnel endpoints in forward and reverse direction. = Something recently discussed in MOBIKE mailing list. I wanted to ask folks if current efforts (standards, or to-be-standards) = solve all the=20 Asymmetry needs of Security? Does it make sense to start new efforts to = deal=20 Asymmetry in Security (ASEC )?=20 Should we have a BoF, when we can, to discuss the Asymmetric needs of = Security? Atul _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Feb 14 09:15:15 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06268 for ; Mon, 14 Feb 2005 09:15:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4D3E3FB27C; Mon, 14 Feb 2005 09:15:15 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 899F0FB24A; Mon, 14 Feb 2005 09:15:11 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5D690FB262; Mon, 14 Feb 2005 09:15:10 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 0C6E7FB240 for ; Mon, 14 Feb 2005 09:15:09 -0500 (EST) 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 j1EEExI21557; Mon, 14 Feb 2005 16:14:59 +0200 (EET) X-Scanned: Mon, 14 Feb 2005 16:10:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1EEAicM009093; Mon, 14 Feb 2005 16:10:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00DzgTTF; Mon, 14 Feb 2005 16:10:42 EET 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 j1EEAgJ26400; Mon, 14 Feb 2005 16:10:42 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Feb 2005 08:10:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2005 09:10:39 -0500 Message-ID: Thread-Topic: [Ipsec] Asymmetric Security Thread-Index: AcUSkKcexLIMXeD8QkaY9xqDGvaHzwADEjsQ From: To: X-OriginalArrivalTime: 14 Feb 2005 14:10:41.0684 (UTC) FILETIME=[F7866540:01C5129E] Cc: ipsec@ietf.org, mobike@machshav.com Subject: [Mobike] RE: [Ipsec] Asymmetric Security X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Thanks Yoav, for bringing another scenario needing Asymmetric support. More such scenarios we can bring the better. The question is whether IKEv2 and 2401bis are sufficient to handle the Asymmetric Security needs or do we need something extra? Things like:=20 Do we allow different tunnel endpoints in the two direction of a tunnel?=20 Do we allow IKE negotiations to be asymmetric? OR Anyhting needed to support the Asymmetric Scenarios brought up? Could members on the MOBIKE and IPsec lists comment on the Asymmetric support in current efforts? And need for a possible new Asymmetric=20 Security efforts? Do we need to seek input from other WG lists? Atul > -----Original Message----- > From: ext Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Monday, February 14, 2005 7:25 AM > To: Sharma Atul (Nokia-ES/Boston) > Cc: mobike@machshav.com; ipsec@ietf.org > Subject: Re: [Ipsec] Asymmetric Security >=20 >=20 > I would add a fourth scenario, which is actually a variation. >=20 > (4) Asymmetry in clustered gateways > Let us say that there are several gateways (call them A1 and A2) that=20 > appear to be a single gateway (i.e, have one identifier, one=20 > certificate, one IP address) with some load-sharing=20 > clustering hardware=20 > or software. Any peer (call it C) must never see anything=20 > other than a=20 > single gateway (call it A). The problem is that due to performance=20 > constraints, the two gateways cannot synchronize their state after=20 > every packet, and because of the retransmission counter of ESP, they=20 > need to have two SAs, one for A1 and one for A2. In IKEv1 this was a=20 > problem, because IKE implementations were not required to support=20 > multiple redundant SAs (and to C, it looks like the two SAs are=20 > redundant). Such implementations always deleted one of the SAs. In=20 > IKEv2 C is required to support multiple redundant SAs. >=20 > On Feb 11, 2005, at 5:30 PM, Atul.Sharma@nokia.com wrote: >=20 > > Hi All, > > > > I wanted to start a discussion on Asymmetric Security. > > > > Asymmetry can show up in different ways in a secure=20 > transmission. For=20 > > example: > > * we can have asymmetry in the gateways involved in secure=20 > > transmission. > > * we can have asymmetry in the tunnels between two=20 > possible multihomed > > gateways > > * we can have asymmetry in the tunnel endpoints of the a tunnel > > > > > > (1) Asymmetry in Gateways: > > Let us say there are three gateways A, B, C. In the forward=20 > direction=20 > > secure traffic > > flows from Gateway A to Gateway B. In the reverse direction traffic=20 > > flows from > > Gateway C to Gateway A. A Mobile IP End-to-End Security between a > > correspondent node and a mobile node will be an example=20 > scenario here. > > IKE negotiations between A and B can setup a tunnel and IKE=20 > > negotiations > > between C and A can set up the tunnels. Both the tunnels=20 > shall still=20 > > protect the > > same hosts/addresses. [Since IKE negotiations do not allow=20 > asymmetry=20 > > we will > > have to have two separate IKE negotiations] > > > > (2) Asymmetry in Tunnels: > > Let us say there are two multihomed Gateways. These=20 > gateways negotiate=20 > > TWO > > tunnels, each with different tunnel endpoints (corresponding to=20 > > multihomed addresses). > > But both the tunnels still protecting the same=20 > hosts/addresses. This=20 > > can be a real > > life scenario to acheive redundancy/high availability > > > > (3) Asymmetry in Tunnel Endpoints > > Let us say there are two multihome Gateways. These gateways=20 > negotiate=20 > > ONE tunnel, > > but with different tunnel endpoints in forward and reverse=20 > direction.=20 > > Something recently > > discussed in MOBIKE mailing list. > > > > > > I wanted to ask folks if current efforts (standards, or=20 > > to-be-standards) solve all the > > Asymmetry needs of Security? Does it make sense to start=20 > new efforts=20 > > to deal > > Asymmetry in Security (ASEC )? > > > > Should we have a BoF, when we can, to discuss the=20 > Asymmetric needs of=20 > > Security? > > > > > > Atul > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec >=20 >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Feb 14 14:38:23 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05739 for ; Mon, 14 Feb 2005 14:38:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 12B87FB262; Mon, 14 Feb 2005 14:38:23 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3F27AFB24A; Mon, 14 Feb 2005 14:38:17 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6AE97FB262; Mon, 14 Feb 2005 07:24:48 -0500 (EST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by machshav.com (Postfix) with ESMTP id B5F33FB240 for ; Mon, 14 Feb 2005 07:24:46 -0500 (EST) Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j1ECOi202960; Mon, 14 Feb 2005 14:24:44 +0200 (IST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Date: Mon, 14 Feb 2005 14:24:43 +0200 To: Atul.Sharma@nokia.com X-Mailer: Apple Mail (2.619.2) X-Mailman-Approved-At: Mon, 14 Feb 2005 14:38:15 -0500 Cc: ipsec@ietf.org, mobike@machshav.com Subject: [Mobike] Re: [Ipsec] Asymmetric Security X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I would add a fourth scenario, which is actually a variation. (4) Asymmetry in clustered gateways Let us say that there are several gateways (call them A1 and A2) that appear to be a single gateway (i.e, have one identifier, one certificate, one IP address) with some load-sharing clustering hardware or software. Any peer (call it C) must never see anything other than a single gateway (call it A). The problem is that due to performance constraints, the two gateways cannot synchronize their state after every packet, and because of the retransmission counter of ESP, they need to have two SAs, one for A1 and one for A2. In IKEv1 this was a problem, because IKE implementations were not required to support multiple redundant SAs (and to C, it looks like the two SAs are redundant). Such implementations always deleted one of the SAs. In IKEv2 C is required to support multiple redundant SAs. On Feb 11, 2005, at 5:30 PM, Atul.Sharma@nokia.com wrote: > Hi All, > > I wanted to start a discussion on Asymmetric Security. > > Asymmetry can show up in different ways in a secure transmission. For > example: > * we can have asymmetry in the gateways involved in secure > transmission. > * we can have asymmetry in the tunnels between two possible multihomed > gateways > * we can have asymmetry in the tunnel endpoints of the a tunnel > > > (1) Asymmetry in Gateways: > Let us say there are three gateways A, B, C. In the forward direction > secure traffic > flows from Gateway A to Gateway B. In the reverse direction traffic > flows from > Gateway C to Gateway A. A Mobile IP End-to-End Security between a > correspondent node and a mobile node will be an example scenario here. > IKE negotiations between A and B can setup a tunnel and IKE > negotiations > between C and A can set up the tunnels. Both the tunnels shall still > protect the > same hosts/addresses. [Since IKE negotiations do not allow asymmetry > we will > have to have two separate IKE negotiations] > > (2) Asymmetry in Tunnels: > Let us say there are two multihomed Gateways. These gateways negotiate > TWO > tunnels, each with different tunnel endpoints (corresponding to > multihomed addresses). > But both the tunnels still protecting the same hosts/addresses. This > can be a real > life scenario to acheive redundancy/high availability > > (3) Asymmetry in Tunnel Endpoints > Let us say there are two multihome Gateways. These gateways negotiate > ONE tunnel, > but with different tunnel endpoints in forward and reverse direction. > Something recently > discussed in MOBIKE mailing list. > > > I wanted to ask folks if current efforts (standards, or > to-be-standards) solve all the > Asymmetry needs of Security? Does it make sense to start new efforts > to deal > Asymmetry in Security (ASEC )? > > Should we have a BoF, when we can, to discuss the Asymmetric needs of > Security? > > > Atul > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 00:05:45 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27505 for ; Tue, 15 Feb 2005 00:05:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AA3F2FB282; Tue, 15 Feb 2005 00:05:45 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 70E93FB266; Tue, 15 Feb 2005 00:05:42 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E3022FB277; Tue, 15 Feb 2005 00:05:40 -0500 (EST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 5FD13FB240 for ; Tue, 15 Feb 2005 00:05:39 -0500 (EST) Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1F54pkJ019687; Tue, 15 Feb 2005 00:04:52 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Feb 2005 23:54:40 -0500 To: Yoav Nir From: Stephen Kent Subject: [Mobike] Re: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: ipsec@ietf.org, 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 At 2:24 PM +0200 2/14/05, Yoav Nir wrote: >I would add a fourth scenario, which is actually a variation. > >(4) Asymmetry in clustered gateways >Let us say that there are several gateways (call them A1 and A2) >that appear to be a single gateway (i.e, have one identifier, one >certificate, one IP address) with some load-sharing clustering >hardware or software. Any peer (call it C) must never see anything >other than a single gateway (call it A). The problem is that due to >performance constraints, the two gateways cannot synchronize their >state after every packet, and because of the retransmission counter >of ESP, they need to have two SAs, one for A1 and one for A2. In >IKEv1 this was a problem, because IKE implementations were not >required to support multiple redundant SAs (and to C, it looks like >the two SAs are redundant). Such implementations always deleted one >of the SAs. In IKEv2 C is required to support multiple redundant >SAs. As you noted, it is not generally feasible for two devices to appear to be one device, due to sequence number management constraints. Also, there is this small matter of synchronizing the keys generated for the SAs between the two devices, in a secure fashion. So, a solution today is to create distinct SAs to each device, and recognize that they represent parallel SGs and don't try to make them look like one SG. What would you want IPsec to do differently, and what implications have you discovered as a result of any proposed changes? Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 00:05:55 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27587 for ; Tue, 15 Feb 2005 00:05:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 20202FB28D; Tue, 15 Feb 2005 00:05:55 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8E850FB27F; Tue, 15 Feb 2005 00:05:45 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3C12CFB27F; Tue, 15 Feb 2005 00:05:43 -0500 (EST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 620AFFB246 for ; Tue, 15 Feb 2005 00:05:39 -0500 (EST) Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1F552kJ019699; Tue, 15 Feb 2005 00:05:03 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 00:04:56 -0500 To: Atul.Sharma@nokia.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: ipsec@ietf.org, mobike@machshav.com Subject: [Mobike] Re: [Ipsec] Asymmetric Security 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 10:30 AM -0500 2/11/05, Atul.Sharma@nokia.com wrote: >Hi All, > >I wanted to start a discussion on Asymmetric Security. > >Asymmetry can show up in different ways in a secure transmission. For example: > * we can have asymmetry in the gateways involved in secure >transmission. > * we can have asymmetry in the tunnels between two possible multihomed > gateways > * we can have asymmetry in the tunnel endpoints of the a tunnel > > >(1) Asymmetry in Gateways: >Let us say there are three gateways A, B, C. In the forward >direction secure traffic >flows from Gateway A to Gateway B. In the reverse direction traffic flows from >Gateway C to Gateway A. A Mobile IP End-to-End Security between a >correspondent node and a mobile node will be an example scenario here. >IKE negotiations between A and B can setup a tunnel and IKE negotiations >between C and A can set up the tunnels. Both the tunnels shall still >protect the >same hosts/addresses. [Since IKE negotiations do not allow asymmetry we will >have to have two separate IKE negotiations] so, what's the problem? you have separate SAs because you have different endpoints. we decided long ago to create SAs in pairs. are you concerned that the state maintained for the unused SAs is a unacceptable burden? > >(2) Asymmetry in Tunnels: >Let us say there are two multihomed Gateways. These gateways negotiate TWO >tunnels, each with different tunnel endpoints (corresponding to >multihomed addresses). >But both the tunnels still protecting the same hosts/addresses. This >can be a real >life scenario to acheive redundancy/high availability again, what is the problem here? >(3) Asymmetry in Tunnel Endpoints >Let us say there are two multihome Gateways. These gateways >negotiate ONE tunnel, >but with different tunnel endpoints in forward and reverse >direction. Something recently >discussed in MOBIKE mailing list. as I noted in a separate response, this scenario needs a better description, given the use of terms above. >I wanted to ask folks if current efforts (standards, or >to-be-standards) solve all the >Asymmetry needs of Security? Does it make sense to start new efforts to deal >Asymmetry in Security (ASEC )? > >Should we have a BoF, when we can, to discuss the Asymmetric needs >of Security? I think you have a long way to go before you establish the need for a BoF. Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 00:05:59 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27605 for ; Tue, 15 Feb 2005 00:05:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 25352FB290; Tue, 15 Feb 2005 00:06:00 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AD700FB27C; Tue, 15 Feb 2005 00:05:53 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AC707FB284; Tue, 15 Feb 2005 00:05:47 -0500 (EST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 00922FB262 for ; Tue, 15 Feb 2005 00:05:40 -0500 (EST) Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1F54pkL019687; Tue, 15 Feb 2005 00:04:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Feb 2005 23:54:54 -0500 To: From: Stephen Kent Subject: [Mobike] RE: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: ipsec@ietf.org, mobike@machshav.com, ynir@checkpoint.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 9:10 AM -0500 2/14/05, wrote: >Thanks Yoav, for bringing another scenario needing Asymmetric support. >More such scenarios we can bring the better. > >The question is whether IKEv2 and 2401bis are sufficient to handle >the Asymmetric Security needs or do we need something extra? Things >like: > Do we allow different tunnel endpoints in the two direction of > a tunnel? this is not a well-formed question; a tunnel is composed of two SAs. what do you mean to ask here? > Do we allow IKE negotiations to be asymmetric? again, not well-formed. are you referring to anything other than S/D addresses? how about ports? Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 06:25:17 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19416 for ; Tue, 15 Feb 2005 06:25:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 942C3FB27C; Tue, 15 Feb 2005 06:25:17 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 473DEFB246; Tue, 15 Feb 2005 06:25:15 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D2A0FB262; Tue, 15 Feb 2005 06:25:13 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id ED5FEFB240 for ; Tue, 15 Feb 2005 06:25:12 -0500 (EST) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3913889883; Tue, 15 Feb 2005 13:25:11 +0200 (EET) Message-ID: <4211DBC0.3090100@piuha.net> Date: Tue, 15 Feb 2005 13:23:44 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent , Yoav Nir , Atul.Sharma@nokia.com Subject: Re: [Mobike] Re: [Ipsec] Asymmetric Security References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I think asymmetric scenarios can be interesting in some cases. But I would recommend discussing the specific problems in the context that they came up. For instance, we are discussing in MOBIKE WG on whether the two peers must always use the same pair of addresses or if they can end up using different addresses due to failures or movements. The answer to this question has a lot to do with the complexity of the failure detection and address pair decision algorithms; this is quite specific to MOBIKE. I have seen Yoav's cluster scenario pop up several times, so it looks like a valid requirement. But exactly how that should be solved (separate gateways or not) and whether current specifications need some enhancement for this is something that the IPsec WG should discuss. (There's perhaps a meta-issue of how IPsec architecture and IKE maintenance will happen in the future, if the IPsec WG is shut down as predicted. But that's a general procedural issue, and not specific to asymmetry.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 09:24:02 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04199 for ; Tue, 15 Feb 2005 09:24:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7F300FB277; Tue, 15 Feb 2005 09:24:02 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BA6F4FB240; Tue, 15 Feb 2005 09:23:58 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A53D0FB246; Tue, 15 Feb 2005 09:23:56 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 64E70FB23C for ; Tue, 15 Feb 2005 09:23:54 -0500 (EST) 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 j1FENbc12043; Tue, 15 Feb 2005 16:23:42 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 16:19:02 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1FEJ2Zi009593; Tue, 15 Feb 2005 16:19:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00nmy3kt; Tue, 15 Feb 2005 16:14:46 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FEDuM06006; Tue, 15 Feb 2005 16:13:57 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 08:12:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 09:12:50 -0500 Message-ID: Thread-Topic: [Ipsec] Asymmetric Security Thread-Index: AcUTHB67SyBEKeXgSoemmvS91FiwtQASrNTg From: To: X-OriginalArrivalTime: 15 Feb 2005 14:12:52.0646 (UTC) FILETIME=[6FFF5C60:01C51368] Cc: ipsec@ietf.org, mobike@machshav.com Subject: [Mobike] RE: [Ipsec] Asymmetric Security 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 Steve, Some comments/clarifications inline. Best, Atul > -----Original Message----- > From: ext Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, February 15, 2005 12:05 AM > To: Sharma Atul (Nokia-ES/Boston) > Cc: ipsec@ietf.org; mobike@machshav.com > Subject: Re: [Ipsec] Asymmetric Security >=20 >=20 > At 10:30 AM -0500 2/11/05, Atul.Sharma@nokia.com wrote: > >Hi All, > > > >I wanted to start a discussion on Asymmetric Security. > > > >Asymmetry can show up in different ways in a secure=20 > transmission. For example: > > * we can have asymmetry in the gateways involved in secure=20 > >transmission. > > * we can have asymmetry in the tunnels between two=20 > possible multihomed > > gateways > > * we can have asymmetry in the tunnel endpoints of the a tunnel > > > > > >(1) Asymmetry in Gateways: > >Let us say there are three gateways A, B, C. In the forward=20 > >direction secure traffic > >flows from Gateway A to Gateway B. In the reverse direction=20 > traffic flows from > >Gateway C to Gateway A. A Mobile IP End-to-End Security between a > >correspondent node and a mobile node will be an example=20 > scenario here. > >IKE negotiations between A and B can setup a tunnel and IKE=20 > negotiations > >between C and A can set up the tunnels. Both the tunnels shall still=20 > >protect the > >same hosts/addresses. [Since IKE negotiations do not allow=20 > asymmetry we will > >have to have two separate IKE negotiations] >=20 > so, what's the problem? you have separate SAs because you have=20 > different endpoints. we decided long ago to create SAs in pairs. are=20 > you concerned that the state maintained for the unused SAs is a=20 > unacceptable burden? Only that there is no unused SAs or rather no unused SA pairs. There = will be two SA pairs negotiated each with different tunnel endpoints. In the first SA pair only the forward SA will be used, in the second SA pair = only the reverse SA will be used. Is something like this already allowed? One SA in each pair shall be unused, which need not even be maintained. A related question: Do we allow IKE negotiations to be asymmetric, i.e. = IKE message goes to an address, but the response comes back from a different address? > >(2) Asymmetry in Tunnels: > >Let us say there are two multihomed Gateways. These gateways=20 > negotiate TWO > >tunnels, each with different tunnel endpoints (corresponding to=20 > >multihomed addresses). > >But both the tunnels still protecting the same hosts/addresses. This=20 > >can be a real > >life scenario to acheive redundancy/high availability >=20 > again, what is the problem here? Allowing two tunnels protecting the same addresses/hosts, but with = differnt tunnel endpoints. Is this something allowed now? _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 09:39:37 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05563 for ; Tue, 15 Feb 2005 09:39:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7F6A0FB277; Tue, 15 Feb 2005 09:39:36 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D1877FB240; Tue, 15 Feb 2005 09:39:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AE8C7FB246; Tue, 15 Feb 2005 09:39:33 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 95EA3FB23C for ; Tue, 15 Feb 2005 09:39:32 -0500 (EST) 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 j1FEdA902996; Tue, 15 Feb 2005 16:39:10 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 16:37:30 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1FEbUbB025065; Tue, 15 Feb 2005 16:37:30 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00FN0Jvk; Tue, 15 Feb 2005 16:36:58 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FEavJ28733; Tue, 15 Feb 2005 16:36:57 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 08:35:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] RE: [Ipsec] Asymmetric Security Date: Tue, 15 Feb 2005 09:35:27 -0500 Message-ID: Thread-Topic: [Mobike] RE: [Ipsec] Asymmetric Security Thread-Index: AcUTHEbI8or/25ciSnathlTUveKjjAAThXJg From: To: X-OriginalArrivalTime: 15 Feb 2005 14:35:28.0990 (UTC) FILETIME=[987107E0:01C5136B] Cc: ipsec@ietf.org, ynir@checkpoint.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 Content-Transfer-Encoding: quoted-printable Hi Steve, Response inline. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Stephen Kent > Sent: Monday, February 14, 2005 11:55 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: ipsec@ietf.org; mobike@machshav.com; ynir@checkpoint.com > Subject: [Mobike] RE: [Ipsec] Asymmetric Security >=20 >=20 > At 9:10 AM -0500 2/14/05, wrote: > >Thanks Yoav, for bringing another scenario needing=20 > Asymmetric support. > >More such scenarios we can bring the better. > > > >The question is whether IKEv2 and 2401bis are sufficient to handle > >the Asymmetric Security needs or do we need something extra? Things > >like: > > Do we allow different tunnel endpoints in the two direction of > > a tunnel? >=20 > this is not a well-formed question; a tunnel is composed of two SAs.=20 > what do you mean to ask here? I will make it more explicit, with one example scenario: So let us say SA pair has the SAs: SA1, SA2. The gateways X and Y. For the sake of simplicity let us just have Y multihomed with addresses Y1 and Y2. So for SA1 tunnel endpoints are X and Y1, for SA2 tunnel endpoints are Y2 and X. Is something like this allowed now? > > Do we allow IKE negotiations to be asymmetric? >=20 > again, not well-formed. are you referring to anything other than S/D=20 > addresses? how about ports? In the above example, IKE in forward direction go X->Y1, but comeback=20 Y2->X.=20 Is that allowed? As far as I know, it is not allowed. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 11:01:58 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23735 for ; Tue, 15 Feb 2005 11:01:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9FF52FB277; Tue, 15 Feb 2005 11:01:58 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3C508FB246; Tue, 15 Feb 2005 11:01:55 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 46D8EFB24A; Tue, 15 Feb 2005 11:01:53 -0500 (EST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 152E4FB240 for ; Tue, 15 Feb 2005 11:01:52 -0500 (EST) Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FG12kN009870; Tue, 15 Feb 2005 11:01:08 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 10:51:10 -0500 To: From: Stephen Kent Subject: [Mobike] RE: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: ipsec@ietf.org, 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 Atul, > > > > >> >(1) Asymmetry in Gateways: >> >Let us say there are three gateways A, B, C. In the forward >> >direction secure traffic >> >flows from Gateway A to Gateway B. In the reverse direction >> traffic flows from >> >Gateway C to Gateway A. A Mobile IP End-to-End Security between a >> >correspondent node and a mobile node will be an example >> scenario here. >> >IKE negotiations between A and B can setup a tunnel and IKE >> negotiations >> >between C and A can set up the tunnels. Both the tunnels shall still >> >protect the >> >same hosts/addresses. [Since IKE negotiations do not allow >> asymmetry we will >> >have to have two separate IKE negotiations] >> >> so, what's the problem? you have separate SAs because you have >> different endpoints. we decided long ago to create SAs in pairs. are >> you concerned that the state maintained for the unused SAs is a >> unacceptable burden? > >Only that there is no unused SAs or rather no unused SA pairs. There will >be two SA pairs negotiated each with different tunnel endpoints. In the >first SA pair only the forward SA will be used, in the second SA pair only >the reverse SA will be used. Is something like this already allowed? It is allowed, and the only possible problem I might see is if DPD mechanisms were confused by the lack of traffic one one of the SAs in each peer. >One SA in each pair shall be unused, which need not even be maintained. true in principle, but unless an implementation suffers from maintaining this extraneous state, it's not a big deal. >A related question: Do we allow IKE negotiations to be asymmetric, i.e. IKE >message goes to an address, but the response comes back from a different >address? That's an IKE question, ask Charlie. > >> >(2) Asymmetry in Tunnels: >> >Let us say there are two multihomed Gateways. These gateways >> negotiate TWO >> >tunnels, each with different tunnel endpoints (corresponding to >> >multihomed addresses). >> >But both the tunnels still protecting the same hosts/addresses. This >> >can be a real >> >life scenario to acheive redundancy/high availability >> >> again, what is the problem here? > >Allowing two tunnels protecting the same addresses/hosts, but with differnt >tunnel endpoints. Is this something allowed now? I think the right question here is how one would cause these different tunnels to be created in the first place. 2401bis is not explicit about how one determines the address for an SG, given the address of a host behind the SG. We note that this is a problem for which we do not have general answers. The new text on the PAD does address this a bit, but it is not comprehensive. My guess is that this is usually manually con figured into an implementation. In your case the question is whether an implementation allows for multiple SG addresses, and whether it causes a tunnel to be created to each of them when an SPD entry triggers SA creation. Currently this is largely outside the scope of 2401bis, i.e., it is up to vendors. One could add a sentence to the PAD text to say that support for creation of more than one tunnel mode SA at a time is OK (i.e., a MAY) just to clarify the issue. Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 11:02:09 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23814 for ; Tue, 15 Feb 2005 11:02:08 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4060BFB27D; Tue, 15 Feb 2005 11:02:10 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 12BE1FB262; Tue, 15 Feb 2005 11:02:06 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 78C41FB280; Tue, 15 Feb 2005 11:02:03 -0500 (EST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 2E446FB246 for ; Tue, 15 Feb 2005 11:02:01 -0500 (EST) Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FG12kP009870; Tue, 15 Feb 2005 11:01:20 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 10:59:52 -0500 To: From: Stephen Kent Subject: RE: [Mobike] RE: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: ipsec@ietf.org, mobike@machshav.com, ynir@checkpoint.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 9:35 AM -0500 2/15/05, wrote: >Hi Steve, > >Response inline. > >Atul > > >> -----Original Message----- >> From: mobike-bounces@machshav.com >> [mailto:mobike-bounces@machshav.com]On >> Behalf Of ext Stephen Kent >> Sent: Monday, February 14, 2005 11:55 PM >> To: Sharma Atul (Nokia-ES/Boston) >> Cc: ipsec@ietf.org; mobike@machshav.com; ynir@checkpoint.com >> Subject: [Mobike] RE: [Ipsec] Asymmetric Security >> >> >> At 9:10 AM -0500 2/14/05, wrote: >> >Thanks Yoav, for bringing another scenario needing >> Asymmetric support. >> >More such scenarios we can bring the better. >> > >> >The question is whether IKEv2 and 2401bis are sufficient to handle >> >the Asymmetric Security needs or do we need something extra? Things >> >like: >> > Do we allow different tunnel endpoints in the two direction of >> > a tunnel? >> >> this is not a well-formed question; a tunnel is composed of two SAs. >> what do you mean to ask here? > >I will make it more explicit, with one example scenario: > So let us say SA pair has the SAs: SA1, SA2. The gateways X and Y. > For the sake of simplicity let us just have Y multihomed with addresses > Y1 and Y2. So for SA1 tunnel endpoints are X and Y1, for SA2 tunnel > endpoints are Y2 and X. > >Is something like this allowed now? I think my other message addressed this question, but frankly the text above is very unclear. try explaining it again. > >> > Do we allow IKE negotiations to be asymmetric? >> >> again, not well-formed. are you referring to anything other than S/D >> addresses? how about ports? > >In the above example, IKE in forward direction go X->Y1, but comeback >Y2->X. > >Is that allowed? As far as I know, it is not allowed. so, if I understand your question, it is whether a multi-homed SG can accept IKE packets on one interface and send them back via the other interface, labelled with the source address of the second interface. My guess is that IKE would not react well to this. Note that IKE SAs do not share all the features of ESP or AH SAs. In ESP or AH, we tolerate the situation in which the source address for an inbound packet either is irrelevant to processing (for the outer address in tunnel mode) or we can accommodate multiple valid source addresses (for transport mode or the inner address in tunnel mode, if configured in the SPD). Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Feb 15 22:55:07 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11271 for ; Tue, 15 Feb 2005 22:55:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 97283FB277; Tue, 15 Feb 2005 22:55:07 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 82A71FB246; Tue, 15 Feb 2005 22:55:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1DF1CFB24A; Tue, 15 Feb 2005 22:55:03 -0500 (EST) Received: from smtp.intoto.com (unknown [207.145.48.18]) by machshav.com (Postfix) with SMTP id 1E8CDFB240 for ; Tue, 15 Feb 2005 22:55:02 -0500 (EST) Received: from angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005021519543226966 ; Tue, 15 Feb 2005 19:54:32 -0800 Received: from SriniSony (dhcp-109.intoto.com [10.1.5.109]) (authenticated bits=0) by angel.intoto.com (8.13.1/8.13.1) with ESMTP id j1G3srst008013; Tue, 15 Feb 2005 19:54:56 -0800 Message-Id: <200502160354.j1G3srst008013@angel.intoto.com> From: "Srinivasa Rao Addepalli" To: , Subject: RE: [Mobike] RE: [Ipsec] Asymmetric Security Date: Tue, 15 Feb 2005 19:54:52 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUTHB67SyBEKeXgSoemmvS91FiwtQASrNTgAByVpgA= Cc: ipsec@ietf.org, 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 Hi Atul, > >(1) Asymmetry in Gateways: > >Let us say there are three gateways A, B, C. In the forward > >direction secure traffic > >flows from Gateway A to Gateway B. In the reverse direction > traffic flows from > >Gateway C to Gateway A. A Mobile IP End-to-End Security between a > >correspondent node and a mobile node will be an example > scenario here. > >IKE negotiations between A and B can setup a tunnel and IKE > negotiations > >between C and A can set up the tunnels. Both the tunnels shall still > >protect the > >same hosts/addresses. [Since IKE negotiations do not allow > asymmetry we will > >have to have two separate IKE negotiations] > > so, what's the problem? you have separate SAs because you have > different endpoints. we decided long ago to create SAs in pairs. are > you concerned that the state maintained for the unused SAs is a > unacceptable burden? Only that there is no unused SAs or rather no unused SA pairs. There will be two SA pairs negotiated each with different tunnel endpoints. In the first SA pair only the forward SA will be used, in the second SA pair only the reverse SA will be used. Is something like this already allowed? SRINI> This scenario happens even in cases where each peer having only one IP address. Think of a scenario, where both parties re-key IPsec (phase2) keys at the same time. So, IMO the scenario you described would work with existing implementations. One SA in each pair shall be unused, which need not even be maintained. A related question: Do we allow IKE negotiations to be asymmetric, i.e. IKE message goes to an address, but the response comes back from a different address? SRINI> In my view, this may not be problem with IKE implementations. But, we observed this problem, when there is symmetric firewall in between IKE peers. It is a good practice that IKE implementations send the reverse/response IKE packets with source IP address as the landed IP address of the received IKE packet. So, I consider the problem you indicated is more of implementation problem than the specification limitation. > >(2) Asymmetry in Tunnels: > >Let us say there are two multihomed Gateways. These gateways > negotiate TWO > >tunnels, each with different tunnel endpoints (corresponding to > >multihomed addresses). > >But both the tunnels still protecting the same hosts/addresses. This > >can be a real > >life scenario to acheive redundancy/high availability > > again, what is the problem here? Allowing two tunnels protecting the same addresses/hosts, but with differnt tunnel endpoints. Is this something allowed now? SRINI> Yes, specifications don't prohibit this behavior. It is already put to use, in implementations, to achieve load sharing of the data across multiple SAs to pass secured traffic through multiple WAN links. _______________________________________________ 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 Mon Feb 21 15:31:15 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11727 for ; Mon, 21 Feb 2005 15:31:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C74B2FB282; Mon, 21 Feb 2005 15:31:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42B9DFB27D; Mon, 21 Feb 2005 15:31:12 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 26FE2FB280; Mon, 21 Feb 2005 15:31:10 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by machshav.com (Postfix) with ESMTP id 1BFC1FB240 for ; Mon, 21 Feb 2005 15:31:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11688; Mon, 21 Feb 2005 15:31:06 -0500 (EST) Message-Id: <200502212031.PAA11688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:31:06 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-02.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : Design of the MOBIKE protocol Author(s) : T. Kivinen, H. Tschofenig Filename : draft-ietf-mobike-design-02.txt Pages : 35 Date : 2005-2-21 The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing protocol extensions to the Internet Key Exchange Protocol version 2 (IKEv2) to enable its use in the context where there are multiple IP addresses per host or where IP addresses of an IPsec host change over time (for example due to mobility). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-design-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-design-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21151402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151402.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart--