[Mip4] Re: Request for text proposal for your scenario

"Adrangi, Farid" <farid.adrangi@intel.com> Thu, 11 September 2003 21:10 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14059 for <mip4-archive@odin.ietf.org>; Thu, 11 Sep 2003 17:10:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYi1-0008Ne-TI for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 17:10:34 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BLAXlZ032208 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 17:10:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYi1-0008NP-En for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 17:10:33 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14039 for <mip4-web-archive@ietf.org>; Thu, 11 Sep 2003 17:10:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYhV-0008LB-RU; Thu, 11 Sep 2003 17:10:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYQS-0007eP-Gc for mip4@optimus.ietf.org; Thu, 11 Sep 2003 16:52:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13385 for <mip4@ietf.org>; Thu, 11 Sep 2003 16:52:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xYQP-0006D6-00 for mip4@ietf.org; Thu, 11 Sep 2003 16:52:21 -0400
Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 19xYQL-0006CI-00 for mip4@ietf.org; Thu, 11 Sep 2003 16:52:17 -0400
Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc, v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8BKkxh26761 for <mip4@ietf.org>; Thu, 11 Sep 2003 20:46:59 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.11.6p2/8.11.6/d: inner.mc, v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8BKpQs00414 for <mip4@ietf.org>; Thu, 11 Sep 2003 20:51:26 GMT
Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091113514218882 for <mip4@ietf.org>; Thu, 11 Sep 2003 13:51:42 -0700
Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Sep 2003 13:51:42 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C378A6.80D28634"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Thu, 11 Sep 2003 13:51:41 -0700
Message-ID: <A95D547FCC54AB47BC55E104D424339BF11F1B@orsmsx407.jf.intel.com>
Thread-Topic: Re: Request for text proposal for your scenario
Thread-Index: AcN4fLFZI7PZJJlUREy/QBYpSsH/ngADEMAgAAdaX/A=
From: "Adrangi, Farid" <farid.adrangi@intel.com>
To: mip4@ietf.org
X-OriginalArrivalTime: 11 Sep 2003 20:51:42.0253 (UTC) FILETIME=[811C5DD0:01C378A6]
Subject: [Mip4] Re: Request for text proposal for your scenario
Sender: mip4-admin@ietf.org
Errors-To: mip4-admin@ietf.org
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>

 

 

-----Original Message-----
From: Adrangi, Farid 
Sent: Thursday, September 11, 2003 10:38 AM
To: 'Jayshree Bharatia'
Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
Subject: RE: Request for text proposal for your scenario

 

Thanks Jayshree.  Ok, let me be more specific by putting inline comments
in your text below.  Thanks.

BR,

Farid

 

Jayshree wrote:

"In this scenario, two VPN gateways are involved where the FA is
considered to be the trusted entity. The mipv4 tunnel is running inside
the IPSec-ESP (Farid> established between the two VPN gateways). For
end-to-end security model, the VPN Gateway within the VPN Domain must
protect the IP traffic originating at the MN (Farid> currently your
scenario does not provide end-2-end security as the traffic between the
MN and the FA is in clear - so are you implying that there should be
another IPsec tunnel between the MN and the VPN GW protecting the
Intranet?), . Since the point of attachment changes corresponding to the
movement of the MN, it is essential that the VPN tunnel security
association must be refreshed after each IP subnet handoff (Farid> in
your scenario, the MN is not the IPsec tunnel end-point.  So, when the
changes its point of attachment, it does not have to worry about
refreshing SAs!). Hence, this scenario is not practical where the
mobility is involved due to performance implications for the real-time
applications."  

 

 

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] 
Sent: Thursday, September 11, 2003 8:52 AM
To: Adrangi, Farid
Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
Subject: RE: Request for text proposal for your scenario

 

Hello Farid, 

I would think that there may or may not be IPSec tunnel between the MN
and the FA/VPN. If there is, than it will have similar issue as
discussed in the proposed text. If there is no IPSec, the traffic will
be unprotected between these two entities.

Regards, 
Jayshree 
> -----Original Message----- 
> From: Adrangi, Farid [mailto:farid.adrangi@intel.com] 
> Sent: Wednesday, September 10, 2003 4:32 PM 
> To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com 
> Subject: RE: Request for text proposal for your scenario 
> 
> 
> Thanks Jayshree.  Couple of clarifications: 
> 
> From your description, it is my understanding that there is 
> only one IPsec tunnel, and that is between the FA/VPN in the 
> foreign and the VPN GW in the VPN domain.  In other words, No 
> IPsec tunnel between the MN and the VPN GW in VPN domain and 
> hence data traffic between the MN and the FA is not 
> protected.  Is my understanding correct?  I will have more 
> questions/comments based on your answers.  Thanks for the 
> text and hopefully we can wrap this up this week. BR, Farid 
> 
> 
> -----Original Message----- 
> From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] 
> Sent: Wednesday, September 10, 2003 12:15 PM 
> To: Adrangi, Farid 
> Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com 
> Subject: RE: Request for text proposal for your scenario 
> 
> Hi Farid, 
> 
> The following is my proposed text for the co-located FA-VPN 
> GW scenario. 
> 
> 
> Reagrds, 
> Jayshree 
> --------------------- 
> 
> 2.6 Combined VPN Gateway and MIPv4 FA 
> 
> MIPv4 FA and the VPN Gateway are running on the same physical machine.

> 
> 
>      ..Foreign Network...             .....VPN Domain..(Intranet).... 
>      .                  .             .                             . 
>      .  +----+  +-----+ .           +----+     +-------+  +-------+ . 
>      .  |MNs |  | FA  | .           | VPN|     | Router|  | HAs   | . 
>      .  |away|  | +   | .<=========>| GW |     | 1..n  |  |       | . 
>      .  |    |  | VPN | .           |    |     +-------+  +-------+ . 
>      .  |    |  | GW  | .           |    |                          . 
>      .  +----+  +-----+ .           +----+     +-------+  +-------+ . 
>      .                  .             .        |  CN   |  | MNs   | . 
>      ....................             .        | 1..n  |  | home  | . 
>                                       .        +-------+  +-------+ . 
>                                       .                             . 
>                                       ............................... 
> 
> 
> In this scenario, two VPN gateways are involved where the FA 
> is considered to be the trusted entity. The mipv4 tunnel is 
> running inside the IPSec-ESP. For end-to-end security model, 
> the VPN Gateway within the VPN Domain must protect the IP 
> traffic originating at the MN. Since the point of attachment 
> changes corresponding to the movement of the MN, it is 
> essential that the VPN tunnel security association must be 
> refreshed after each IP subnet handoff. Hence, this scenario 
> is not practical where the mobility is involved due to performance 
> implications for the real-time applications. 
> 
> > -----Original Message----- 
> > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] 
> > Sent: Wednesday, September 03, 2003 7:54 PM 
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com 
> > Subject: Request for text proposal for your scenario 
> > 
> > 
> > 
> > Hello Jayshree, 
> > Could you please propose a text for the scenario that you 
> > want to be added to the problem-statement draft? 
> > BR, 
> > Farid 
> > 
> > -----Original Message----- 
> > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] 
> > Sent: Wednesday, August 06, 2003 12:13 PM 
> > To: Adrangi, Farid 
> > Cc: mip4@ietf.org 
> > Subject: RE: Comments on VPN Problem Statement Draft 
> > 
> > Hello Farid, 
> > 
> > Please see my reply below. 
> > 
> > Thanks, 
> > Jayshree 
> > -----Original Message----- 
> > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] 
> > Sent: Sunday, August 03, 2003 11:50 PM 
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> > Cc: mip4@ietf.org 
> > Subject: RE: Comments on VPN Problem Statement Draft 
> > 
> > 
> > Hello Jayshree, 
> > Thanks for following up on this.  You, Gopal, and I had a 
> > very brief conversation on this during IETF-57 - but I am not 
> > sure if we derived any conclusion on whether or not we should 
> > include this scenario.  To be frank, I don't quite understand 
> > the point behind adding this scenario because, 
> > -          It seems to present a solution to a specific 
> > deployment model 
> > rather than a deployment scenario 
> > [JB] My understanding is different from yours so please 
> > elaborate what you mean by deployment model vs deployment 
> > scenario in this particular context. 
> > 
> > -          I don't quite see the advantages of  a combined 
> > VPN+FA if it 
> > does 
> > not support FA traversal and it does not avoid IPsec 
> > renegotiation when MN moves from one subnet to another - 
> > perhaps you can elaborate on this? [JB] I think regardless 
> > this scenario has any advantages or not, it is one of the 
> > probable scenario which has potential issues (as you have 
> > indicated earlier). 
> > 
> > -          Furthermore, Scenarios in section 2 of the problem 
> > statement 
> > draft represents combinations of MIPv4 HA and VPN gateway 
> > placement - adding this scenario is going to change semantics 
> > of the section 2. [JB] I am not sure what you mean by 
> > semantics change here. Do you think documenting this in new 
> > subsection (2.6) is a problem? 
> > 
> > I have no problem adding this scenario to the draft - I just 
> > wanted to make sure that we clearly understand the reasons 
> > for adding this scenario to the problem statement draft.  
> > Design team members and interested individuals are welcome to 
> > express their opinion on this.  
> > 
> > Best regards, 
> > Farid 
> > 
> > 
> > 
> >  
> >  
> >  The   following   sub-sections   introduce   five   representative 
> >    combinations of MIPv4 HA and VPN gateway placement. 
> > 
> > -----Original Message----- 
> > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] 
> > Sent: Thursday, July 31, 2003 1:44 PM 
> > To: Adrangi, Farid 
> > Cc: 'mip4@ietf.org' 
> > Subject: RE: Comments on VPN Problem Statement Draft 
> > 
> > Hello Farid, 
> > 
> > As per our earlier discussion during IETF-57, my 
> > understanding is that you will include the scenario of 
> > co-existed FA with the VPN gateway in the VPN Problem 
> Statement draft. 
> > 
> > I agree that this particular scenario has problems and it 
> > won't work if the MN is behind an FA in the foreign subnet. 
> > But again, this is a problem statement draft. Hence, I 
> > believe that this is the appropriate document for mentioning 
> > this scenario. 
> > 
> > Thanks, 
> > Jayshree 
> > 
> > -----Original Message----- 
> > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] 
> > Sent: Monday, April 07, 2003 2:58 PM 
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> > Cc: 'mobile-ip@sunroof.eng.sun.com' 
> > Subject: RE: Comments on VPN Problem Statement Draft 
> > Hello Jayshree 
> > This is a good point - I knew someone was to bring this up!  
> > At the time of writing these scenarios, we (the design team) 
> > actually discussed this and concluded this scenario would 
> > fall into a solution space.  Maybe we did not make the right 
> > decision and we should rethink this.  But, before we take 
> > this discussion further please allow me to ask you a few 
> > questions about the details of the scenario (VPN+FA) that you 
> > have in mind .  Are you thinking to broadcast FA 
> > advertisements through the IPsec tunnel to the MN?  If so, 
> > how will this work if MN is already behind an FA in the 
> > foreign subnet? Or, If you had something different in mind, 
> > perhaps you can elaborate on that. Best regards, Farid 
> > 
> > 
> > -----Original Message----- 
> > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], 
> > Sent: Friday, April 04, 2003 3:14 PM 
> > To: 'farid.adrangi@intel.com' 
> > Cc: 'mobile-ip@sunroof.eng.sun.com' 
> > Subject: Comments on VPN Problem Statement Draft 
> > 
> > Hello Farid, 
> > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) 
> > currently misses one scenario were the FA is co-existed with 
> > the VPN Gateway. I would think that there are no technical 
> > issues supporting this scenario. It will be good if you can 
> > add this scenario in the draft (perhaps as section 
> > 2.6?) 
> > for completeness. 
> > Thanks, 
> > Jayshree 
> > 
> > 
>