Subject: [Mip4] RE: Request for text proposal for your scenario

From: Gopal Dommety <[email-masked]>
Date: Thu, 11 Sep 2003 12:51:09 -0700

Hello Farid, Henrick and Jayashree,

the scenario I was referring to  is as followis:

MN---------|VPN/FA|-----------------[VPN2]---------HA

VPN1 Provides Encryption/decryption for the link and access to the visiting 
domain.
VPN 2 is optional for remote access. In fact, I would say let us omit this 
VPN2.

Thanks
Gopal

At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote:

>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:[email-masked]>mailto:[email-masked]]
> > Sent: Wednesday, September 10, 2003 4:32 PM
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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:[email-masked]>mailto:[email-masked]]
> > Sent: Wednesday, September 10, 2003 12:15 PM
> > To: Adrangi, Farid
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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:[email-masked]>mailto:[email-masked]]
> > > Sent: Wednesday, September 03, 2003 7:54 PM
> > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > 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:[email-masked]>mailto:[email-masked]]
> > > Sent: Wednesday, August 06, 2003 12:13 PM
> > > To: Adrangi, Farid
> > > Cc: [email-masked]
> > > Subject: RE: Comments on VPN Problem Statement Draft
> > >
> > > Hello Farid,
> > >
> > > Please see my reply below.
> > >
> > > Thanks,
> > > Jayshree
> > > -----Original Message-----
> > > From: Adrangi, Farid 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > > Sent: Sunday, August 03, 2003 11:50 PM
> > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > Cc: [email-masked]
> > > 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:[email-masked]>mailto:[email-masked]]
> > > Sent: Thursday, July 31, 2003 1:44 PM
> > > To: Adrangi, Farid
> > > Cc: [email-masked]'
> > > 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:[email-masked]>mailto:[email-masked]]
> > > Sent: Monday, April 07, 2003 2:58 PM
> > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > Cc: [email-masked]'
> > > 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:[email-masked]>mailto:[email-masked]],
> > > Sent: Friday, April 04, 2003 3:14 PM
> > > To: [email-masked]'
> > > Cc: [email-masked]'
> > > 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
> > >
> > >
> >

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 11 Sep 2003 13:50:22 -0700

Hi Gopal,

Ok.  As per my understanding of your scenario, I infer a few things from
it:

1) MN may be several hops away from the VPN/FA
2) FA advertisement is done inside the IPsec tunnel established between
the MN and VPN/FA.
3) MN roaming in a foreign network cannot be place behind a FA.  For
example, the following picture is not possible:

MN ---FA----one or hops----FA/VPN1

4) VPN1/FA could also be your remote access VPN.  So, the picture can be
simplified as follows

MN ----one or more hops -----FA/VPN ---Intranet

Note: I get frighten when I see nested IPsec tunnels, in particular
established by different IPsec client software running on the client
device!!!

So, since the scenario does not support #3 above, then the only problem
that we have is with SA refreshes when the MN changes its point of
attachment.  Do I have a correct understanding of your scenario?

BR,
FArid

-----Original Message-----
From: Gopal Dommety [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 10:58 AM
To: Jayshree Bharatia; Adrangi, Farid
Cc: [email-masked]; [email-masked]
Subject: RE: Request for text proposal for your scenario

VPN1 Provides Encryption/decryption for the link and access to the
visiting 
domain.
VPN 2 is optional for remote access.

Thanks
Gopal

> >      .                  .             .
.
> >      .  |    |  | GW  | .           |    |
.
> >      .                  .             .        |  CN   |  | MNs   |
.
> >                                       .        +-------+  +-------+
.
> >                                       .
.
,

---

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 11 Sep 2003 13:51:41 -0700

-----Original Message-----
From: Adrangi, Farid 
Sent: Thursday, September 11, 2003 10:38 AM
To: 'Jayshree Bharatia'
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Thursday, September 11, 2003 8:52 AM
To: Adrangi, Farid
Cc: [email-masked]; [email-masked]; [email-masked]
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 
> From: Adrangi, Farid [mailto:[email-masked]] 
> From: Jayshree Bharatia [mailto:[email-masked]] 

> > From: Adrangi, Farid [mailto:[email-masked]] 
> > From: Jayshree Bharatia [mailto:[email-masked]] 
> > From: Adrangi, Farid [mailto:[email-masked]] 
> > From: Jayshree Bharatia [mailto:[email-masked]] 
> > From: Adrangi, Farid [mailto:[email-masked]] 
> > From: Jayshree Bharatia [mailto:[email-masked]],

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 11 Sep 2003 17:22:09 -0500

Farid,
 
As I have mentioned in my earlier email addressed to Gopal, we can focus on
the scenario where we have IPSec tunnel between the MN and the VPN gateway.
My proposed text was wrt the VPN GW of the VPN domain. My thoughts were that
if we have FA in the picture (roaming scenario), it is always safe to assume
that it is a remote scenario. 
 
We can logically assume one VPN entity (co-existed with the FA) and describe
the scenario which is fine with me as well. I am open to the suggestion. So
let's look at Gopal's proposal and make changes accordingly in the text for
this scenario.
 
Thanks,
Jayshree

-----Original Message-----
From: Adrangi, Farid [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 3:52 PM
To: [email-masked]
Subject: [Mip4] Re: Request for text proposal for your scenario

-----Original Message-----
From: Adrangi, Farid 
Sent: Thursday, September 11, 2003 10:38 AM
To: 'Jayshree Bharatia'
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Thursday, September 11, 2003 8:52 AM
To: Adrangi, Farid
Cc: [email-masked]; [email-masked]; [email-masked]
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 
> From: Adrangi, Farid [mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: Jayshree Bharatia [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Adrangi, Farid [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Jayshree Bharatia [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Adrangi, Farid [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Jayshree Bharatia [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Adrangi, Farid [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Jayshree Bharatia [mailto:[email-masked]
<mailto:[email-masked]> ],

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 24 Sep 2003 12:03:52 -0500

Hi Farid,

Please see my response inline.

Regards,
Jayshree

> Sent: Wednesday, September 24, 2003 8:25 AM
> To: Gopal Dommety; Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Thanks Gopal. IMO, the scenario lacks some details.  For example, 
> 
> 1) does this scenario allow MN to work in non-colocated mode? That is,
> 
> MN ---FA---VPN/FA ---Intranet
[JB] If VPN/FA are co-located, that node can have role of Mobile IP FA as
well as VPN. You can configure this node however you like but our interest
here is for the case where both these roles are active.
> 
> 2) What is the role of FA on the VPN gateway?  In other 
> words, what is the difference between 
> 
> MN -----VPN/FA ------Intranet  (your scenario) 
[JB] Functionality of the VPN and the FA are provided through same physical
node.
> And
> MN -------VPN -------Intranet 
[JB} Not sure what this scenario is but looks like you have FA somewhere
else.
> 
> However, if others are okay with the text as it is, then I'll 
> go ahead and add it.
> 
> BR,
> Farid 
> 
> 
> Sent: Tuesday, September 23, 2003 6:01 PM
> To: Adrangi, Farid; Jayshree Bharatia
> Cc: [email-masked]; [email-masked]; [email-masked]
> The text Jayshree sent looks good. I just made minor edits. 
> Here is the 
> text below:
> 
> 
>       ..Foreign Network............VPN Domain..(Intranet).....
>       .                         .                            .
>       .  +----+              +-----+    +-------+  +-------+ .
>       .  |MNs |              | FA  |    | Router|  | HAs   | .
>       .  |away|<============>| +   |    | 1..n  |  |       | .
>       .  |    |              | VPN |    +-------+  +-------+ .
>       .  |    |              | GW  |                         .
>       .  +----+              +-----+   +-------+  +-------+  .
>       .                         .      |  CN   |  | MNs   |  .
>       .                         .      | 1..n  |  | home  |  .
>       .                         .      +-------+  +-------+  .
>       .                         .                            .
>       ........................................................
> 
> In this scenario, the mipv4 tunnel is running inside the 
> IPSec-ESP between the MN and the FA/VPN Gateway.This scenario
>   IPsec being used to protect the data over the wireless network.
> 
> For end-to-end security model, the VPN
> Gateway
> 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 for
> the
> real-time applications due to the performance implications.
> 
> 
> Thanks
> Gopal
> 
> 
> 
> 
> 
> At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote:
> >Any update on this?  What should we do next?
> >--Farid
> >
> >Sent: Tuesday, September 16, 2003 11:02 AM
> >To: 'Gopal Dommety'
> >Cc: [email-masked]'; [email-masked]'; Adrangi, Farid
> >Gopal,
> >Appreciate if you can make appropriate changes to the proposed text:
> >
> >Thanks,
> >Jayshree
> >
> >-------------
> >Proposed text:
> >
> >      ..Foreign Network............VPN Domain..(Intranet).....
> >      .                         .                            .
> >      .  +----+              +-----+    +-------+  +-------+ .
> >      .  |MNs |              | FA  |    | Router|  | HAs   | .
> >      .  |away|<============>| +   |    | 1..n  |  |       | .
> >      .  |    |              | VPN |    +-------+  +-------+ .
> >      .  |    |              | GW  |                         .
> >      .  +----+              +-----+   +-------+  +-------+  .
> >      .                         .      |  CN   |  | MNs   |  .
> >      .                         .      | 1..n  |  | home  |  .
> >      .                         .      +-------+  +-------+  .
> >      .                         .                            .
> >      ........................................................
> >
> >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP 
> >between the
> >MN and the FA/VPN Gateway. For end-to-end security model, the VPN
> >Gateway
> >must
> >protect the IP traffic originating at the MN. Since the point of
> >attachment
> >VPN
> >tunnel security association must be refreshed after each IP subnet
> >handoff.
> >Hence, this scenario is not practical where the mobility is involved
> for
> >the
> >real-time applications due to the performance implications.
> >
> >
> > > From: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > Sent: Monday, September 15, 2003 4:39 PM
> > > To: 'Gopal Dommety'; Adrangi, Farid
> > > Gopal,
> > > I was in the impression that you will modify the text. Anyway, I 
> > > won't able to do much today but let me try tomorrow and 
> send you the 
> > > text...
> > >
> > > Regards,
> > > Jayshree
> > >
> > > > Sent: Monday, September 15, 2003 2:03 PM
> > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > > Jayshree,
> > > > Can you massage the text that you sent to fit what I was
> > > referring to.
> > > >
> > > > -Gopal
> > > >
> > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote:
> > > >
> > > > >Hi Gopal,
> > > > >Ok.  I guess my interpretation of your scenario was 
> not accurate! 
> > > > >Maybe the best thing is that you and Jayshree propose 
> a text that
> > > > >*clearly* articulates the scenario and its problems.
> > > Would that be
> > > > >possible? Thanks a bunch. BR,
> > > > >Farid
> > > > >
> > > > >Sent: Thursday, September 11, 2003 3:43 PM
> > > > >To: Adrangi, Farid; Jayshree Bharatia
> > > > >I am not suggesting a solution. I am confused by your 
> > > > >inferences...comments inline to the best of my confusion.
> > > > >
> > > > >
> > > > >I was talking about one hop away. the multiple hops is
> > > > interesting. The
> > > > >deployment scenarios of one hop and multiple hop 
> solutions could
> be
> > > > >very
> > > > >
> > > > >different.
> > > > >
> > > > >
> > > > > >2) FA advertisement is done inside the IPsec tunnel 
> established 
> > > > > >between the MN and VPN/FA.
> > > > >
> > > > >It is possible.. but then we are going into solution space.
> > > > >
> > > > > >4) VPN1/FA could also be your remote access VPN.  So, the
> > > > picture can
> > > > >be
> > > > > >simplified as follows
> > > > > >
> > > > > >So, since the scenario does not support #3 above, 
> then the only 
> > > > > >problem that we have is with SA refreshes when the MN
> > > changes its
> > > > > >point of attachment.  Is my understanding correct?
> > > > > >
> > > > > >BR,
> > > > > >FArid
> > > > > >
> > > > > >
> > > > > >
> > > > > >visiting domain.
> > > > > > >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
> > > > > > > > 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
> questions/comments
> > > > > > > > based on your answers.  Thanks for the text and
> > > > hopefully we can
> > > > > > > > wrap this up this week. BR, Farid
> > > > > > > >
> > > > > > > >
> >[<mailto:[email-masked]>mailto:[email-masked]
> > > > > >om
> > > > >]
> > > > > > > > The following is my proposed text for the co-located
> > > > FA-VPN GW
> > > > > > > > scenario.
> > > > > > > >
> > > > > > > >
> > > > > > > > Reagrds,
> > > > > > > > Jayshree
> > > > > > > > ---------------------
> > > > > > > >
> > > > > > > > MIPv4 FA and the VPN Gateway are running on the
> > > same physical
> > > > > >machine.
> > > > > > > >
> > > > > > > >
> > > > > > > >      .  +----+  +-----+ .           +----+     +-------+
> > > > >+-------+
> > > > > >.
> > > > > > > >      .  |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.
> > > > > > > >
> > > > > > > > > Could you please propose a text for the scenario
> > > > that you want
> > > > > > > > > to be added to the problem-statement draft? BR, Farid
> > > > > > > > >
> >[<mailto:[email-masked]>mailto:[email-masked]
> > > > > >om
> > > > >]
> > > > > > > > > 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 
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> >[<mailto:[email-masked]>mailto:[email-masked]
> > > > > >om
> > > > >]
> > > > > > > > > But again, this is a problem statement draft.
> > > > Hence, I believe
> > > > > > > > > that this is the appropriate document for mentioning
> this
> > > > > > > > > scenario.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Jayshree
> > > > > > > > >
> 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
> > > > >[<mailto:[email-masked]>>
> > > > >mailto:[email-masked]
> > > > > >om
> > > > >]
> > > > > >,
> > > > > > > > > This draft
> > > > (draft-ietf-mobileip-vpn-problem-statement-req-01)

---

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 29 Sep 2003 00:34:57 -0700

-----Original Message-----
From: Gopal Dommety [mailto:[email-masked]] 
Sent: Wednesday, September 24, 2003 10:58 AM
To: Adrangi, Farid; Jayshree Bharatia
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Mip4] RE: Request for text proposal for your scenario

>MN ---FA---VPN/FA ---Intranet

yes...But the figure you drew is not correct...It could be as follows..

MN -----VPN/FA ---Intranet

Farid> The figure that I drew makes sense if you assume that MN can be
attached to the Internet.  Actually, I should've drawn like this:

MN---FA---Internet---VPN/FA ---Intranet

But, reading other mails, I guess your scenario covers only corporate
networks so you should make that very clear in your proposed text.

>2) What is the role of FA on the VPN gateway?  In other words, what is
>the difference between
>

FA can be optionally used for Mobility (I think you left out HA in your
figure)

Farid> Ok, I left out HA in the above diagram.  But, the question is
that how does FA help with mobility here?   

>However, if others are okay with the text as it is, then I'll go ahead
>and add it.
>
>BR,
>Farid
>
>
>The text Jayshree sent looks good. I just made minor edits. Here is the
>text below:
>
>
>MN and the FA/VPN Gateway.This scenario
> >between
> > > I was in the impression that you will modify the text.
> > > Anyway, I won't able to do much today but let me try tomorrow
> > > and send you the text...
> > >
> > > Regards,
> > > Jayshree
> > >
> > > > >Ok.  I guess my interpretation of your scenario was not
accurate!
> > > > >Maybe the best thing is that you and Jayshree propose a text
that
> > > > >deployment scenarios of one hop and multiple hop solutions
could
established
> > > > > >So, since the scenario does not support #3 above, then the
only
> > > > > > >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
> > > > > > > > Gateway within the VPN Domain must protect the IP
traffic
> > > > > > > > > if we derived any conclusion on whether or not we
should
> > > > > > > > > this up! At the time of writing these scenarios, we
(the
> > > > > > > > > design team) actually discussed this and concluded
this