[Mip4] Re: Request for text proposal for your scenario
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mip4] Re: Request for text proposal for your scenario
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:gdommety@cisco.com]
Sent: Thursday, September 11, 2003 10:58 AM
To: Jayshree Bharatia; Adrangi, Farid
Cc: mccap@lucent.com; henrik@levkowetz.com
Subject: RE: Request for text proposal for your scenario
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.
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:farid.adrangi@intel.com>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>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>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>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>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>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>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>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
> > >
> > >
> >
_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.