Subject: RE: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn- problem-statemen t-00

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 4 Jun 2002 11:08:23 -0700

Hello Serge
Thanks for reading the draft, and providing feedback. Please
see my reply below (marked by Farid Writes>).
Best regards,
Farid

-----Original Message-----
From: Tessier, Serge [mailto:[email-masked]]
Sent: Friday, May 31, 2002 7:41 AM
To: [email-masked]
Subject: [mobile-ip] [mobile-IP]: Comments on
draft-ietf-mobileip-vpn-problem-statemen t-00

This draft appears to be a product of the working group so I address my
comments (minor -maybe very personnal- and major -technical- ones) to the
authors through the mailing list.

a. Abstract & Introduction:
 When VPN is mentionned I think it should be precised L3-based VPN or even
IPSec-based VPN since in the rest of the document IPSec is mentioned but
never L2 tunneling mechanisms.  

Somehow, the following limited scope should be stated : "The scenarios
described here assume that the VPN solution is based on L3 mechansims" or
alternatively: "The scenarios described here excludes any L2-based VPN
realisation".

It could even be justified that for the sake of coherence since for
interaction purposes (triggerring event notification) mobility and security
may need to be put on the 'same level' i.e. network layer (maybe too much
implementation specific). It is also an obvious benefit to maintain the
well-known Mobile IP link layer independancy through the exclusion of L2TP
solution.

Farid Writes > Agree.  We will make changes to both abstract and
introduction sections
to make it clear that the scenarios assume an IPsec-based VPN solution.

a'.
 There may be a lack of 'motivation' chapter (see also d.). In such a
chapter it would be the place to mention that for example one could extend
already deployed VPN solutions through the offer of 'mobility services' as a
VPN add-on feature.

Farid Writes > The draft's intent is to not suggest any solutions at all,
but simply
descibe a problem.  And I think the VPN extension that you are talking about
falls into
the solution space.

b.
 In all the figures the terms 'GW' is missing in each boxes containing the
text 'IPSec-based VPN'

Farid Writes> Yes. Easy to fix!

c.
 Also some typos (ASCII conversion) in the text...

Farid Writes > Good catch!  Somehow, we missed that!

d. Page 4. After figure 4.0b: 
 This motivation is very important and should be put IMO at the beginning of
the document (abstract). Even if it is mentioned in the introduction I think
it comes too late, it is too vague (on the contrary, the references to EDGE,
GPRS, UMTS do not bring IMO any motivation per se). Sorry, I do not propose
anything better.

Farid Writes>  We can make changes to the abstract to bring out that
the motivation part (through some usage scenarios) comes in later 
sections.  Do you think that would help?

e. Page 5:
 "Dr. Joe needs to establish an IPsec tunnel to the VPN gateway first so
that he can register with the home agent while roaming outside the home
network. This implies that the MIPv4 traffic destined to the home network
has to run inside an IPsec tunnel."

Here I am a bit puzzle: It is indeed a bit hard to state that spontaneously
without any introduction/motivation about the fact that the tunnels should
be put in that order.

Farid Writes >  The fact is that the home network is not directly
reachable by the MN, therefore, the MN has to run MIP traffic inside
the IPsec tunnel.  Perhaps, the text should be modified to make this more 
clear -- so, how about the following?

"Dr. Joe needs  has to establish an IPsec tunnel to the VPN gateway first so
that he
can register with the home agent while roaming outside the home network.
This also implies
that the MIPv4 traffic destined to the home network has to run inside an
IPsec tunnel,
as the home network will not directly be reachable."

I am not sure we (at least I) have reached an exhaustive understanding and I
would be happy to have discussion for clarifying these issues
(draft-ietf-mobileip-ipsec-use-00.txt is maybe a starting point (?), not the
proposal itself but the general philosophy especially the requirements, but
it expired in 1998. There are other studies about that topic).
There was also a thread on the mobileip-nat-vpn mailing list..

Why not including a section describing tunneling order, listing at least the
alternatives and the pros/cons or, at the minimum, letting the door open for
issues that are IMHO not understood? With a statement like:
"It has still to be investigated in a further version of this document
weather the Mobile IP tunnel should be put within the IPSec tunnel or the
other way around. In this document we do not make any assumption regarding
the tunnelling order."

Farid Writes > In my mind, the draft should not suggest any tunneling order
-
this falls into the solution space.  Agree/Disagre?

f. Page 5. Section 5.2:
 If the imaginary mobile user Dr. Joe is introduced, then why not using him
here?
This document should be about usage scenario so it could be helpfull to
state that in the case 1, Dr. Joe visit a 'branch office' (e.g. surgery
dept.) outside the hospital's main building.

Farid Writes > Agree.  Will fix it.

Anyway, more important here:
"The FA is trusted, i.e. an SA has been established a priori between the FA
and the home VPN gateway."
Wouldn't it be more generic to state that there is a GW-to-GW security
scheme between a VPN GW located at the edge of the Foreign Network and the
'IPSec-based VPN (GW)' at the edge of the home network?
IMHO it would more fit in existing usage scenario, at least the ones I can
foreseen.

Farid Writes>  Maybe we should mention both cases.  So, how about the
following?

"The FA is trusted, i.e. an SA has been established a priori between the FA
and the home VPN gateway, or a GW-to-GW security scheme exists between a VPN
GW located at the edge of the Foreign Network and the
 'IPSec-based VPN (GW)' at the edge of the home network"

g. Page 7. Figure 6.1b:
 "Figure 6.1b u Shows IPsec tunnel endpoints, MN-CoA and the VPN External IP
address, in co-located mode"
It is here abruptly stated that the MN-CoA is the tunnelling end point of
the IPSec tunnel.
It is a consequence of page 5 sections.
I know some other possible combination, which I do not pretend to be better.
Wouldn't it be possible to write 'for example' in the previous statement,
once again not to preclude any solution?
Please also see my comment e.

FArid Write> Here again, we are not suggesting any tunneling order or
solutions. 
The diagram shows how a node (from outside) communicates to its home network
(protected by a VPN).  And to make this communication possible, the MN has  
to establish an IPsec tunnel to the VPN gateway first, and run the traffic
to the 
home network inside that tunnel (this is true even if MIP is not in the
picture)
Maybe you can help us understand why you think we are suggesting any
tunneling
order (or a solution) here.

Thanks

-Serge

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 04 Jun 2002 18:32:13 -0500

Hi Farid,
  Here are my questions on the draft:
- where is draft-bpatil-mobileip-sec-guide-01.txt? It does not seem to 
be at the drafts directory any more. Same for

draft-ietf-mobileip-ipsec-use-00.txt?
- Are you trying then to come up with similar solutions as in these two drafts?
- How is the problem domain different than draft-ietf-mobileip-nat-traversal-03.txt? Especially if you are not considering MNs behind foreign NATs?

Regards,

>see my reply below (marked by Farid Writes>).
--behcet