Subject: [Mip4] WGLC Comments: draft-ietf-mip4-mobike-connectivity-01.txt

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 12 Dec 2006 23:33:50 -0800

Overall, I support advancing this draft. But, I think it requires some
clarifications.  

1. The draft states: 

"The Mobile IP tunnel uses reverse tunneling through the
   home agent [8]."

>From this, it is not clear if reverse tunneling is mandated or not. This
should be clarified. When using the HoA for communication, reverse
tunneling probably needs to be mandated when accessing via a VPN -
otherwise, the VPN GW is going to drop the packets. If the VPN is set up
to bypass such packets as well, it will work, if the HoA is a routable
address and if there is no ingress filtering on the local network. But,
I'm not sure we need to allow such a scenario. Alternately, the MN may
use its VPN TIA for communication. 

2. For crossing security boundaries, the document states: 

"   If the mobile node has an existing VPN tunnel to its VPN gateway, it
   MUST send a MOBIKE message at the same time as the registration
   request to the i-HA whenever the IP address changes.  If the mobile
   node receives a response from the VPN gateway, but not from the i-HA,
   it assumes it is outside the enterprise network.  If it receives a
   response from the i-HA, then it assumes it is inside the enterprise
   network."

I don't understand this. I don't think it is trivial to bypass the VPN
to send a MIP RRQ, when the tunnel outer address is changing and a
MOBIKE exchange has been initiated. This would involve dynamically
changing the bypass rules for the VPN - in fact, it's not clear to me
how such a rule might even work. Obviously, UDP port 434 messages cannot
always be allowed to bypass IPsec. "Bypass UDP port 434 traffic when a
link change just occurred" doesn't quite work. If the MN is using a
CCoA, "bypass UDP port 434 traffic when IP source = local address" might
work, but, it won't work when the MN is using an FA CoA. Also, if the MN
discovered an FA on the local network, how does it know whether or not
to use it? It needs to not use it if that subnet is part of an untrusted
network. I understand that the motivation is to allow an operation with
lower latency, but, I am confused as to how this works. 

In fact, I think it is simplest to state that the detection of trusted
networks is done by out-of-band mechanisms and that if there is a VPN
tunnel, that is always used. If we attempt to solve it as in the draft,
we need a lot more clarity on the following: 

- What bypass rules are to be used for IPsec? I don't think hand-waving
this is good. 
- Is the MN allowed to use an FA upon a subnet change? Is this the same
behavior whether the MN is moving from an untrusted or trusted network? 
- If the MN used an FA, but discovers it is on an untrusted network, it
needs to then obtain a local address to set up a VPN. 

3. Some VPNs support bypass mode/split tunneling when the host is
attached via an untrusted network - such traffic will not have any
mobility support as well. This is not too different from a MIP MN using
it's CoA for local communication - however, since this document ties the
VPN to MIP, I think it is good to note this - especially to avoid any
implementation issues (ambiguities with respect to what packets go
through MIP processing prior to IPsec processing and what don't). Any
attempt to route packets meant to bypass the VPN through the MIP stack
will result in dropped packets. 

4. The document doesn't touch on simultaneous bindings and I think it
should. Some enterprises treat the internal wireless access networks
similar to untrusted networks (thereby requiring a VPN over it) and it
is quite common to have simultaneous wired and wireless connectivity.
One of those may be routed through a VPN, while the other may be routed
directly. Is the MN allowed to register both interfaces with the HA?
Unfortunately, the only form of simultaneous bindings supported by
RFC3344 is bicasting, which is not-so-desirable here, since, there may
be long periods of time when wired and wireless interfaces are
simultaneously active. So, perhaps the right thing to do is to recommend
against simultaneous bindings, but, I'm not sure. 

5. Is a scenario where an MN may connect via a cellular network in scope
for the document? If so, there are a couple of cases to consider here.
The cellular network may be offering MIP separately. This is not an
issue when the MIP client for the cellular network is in the cellular
modem. But, when the MIP client in the host attempts to handle that
mobility as well, there might be a problem. This leads to a
MIP-IPsec-MIP layering, which I'm not sure we want to get into :) May be
we need to say that it is out of scope, but I'd like to hear other views
on this. 

Vidya

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Dec 2006 17:40:35 +0100

on 2006-12-13 08:33 Narayanan, Vidya said the following:
> should be clarified.

This is part of a solution overview, and as such is perfectly clear to me
- it simply says that the solution uses reverse tunnelling through the
home agent.  Nothing to clarify.

> When using the HoA for communication, reverse
> I don't understand this.

Seems clear enough to me.

> I don't think it is trivial to bypass the VPN

It seems to me that a rule to permit traffic to a specific host address
and port is trivial to implement.  What's so hard about that?

> we need a lot more clarity on the following: 

How to do the inside-outside detection isn't trivial, on the other hand,
so there is clear value in defining it.  Declaring it undefined doesn't
help.

> needs to then obtain a local address to set up a VPN. 

Since the text you're criticizing already states clearly that a local
address has been acquired, this is not particularly relevant.  Sending
a RRQ to the i-HA using the acquired local address constitutes a simple
and feasible test of inside/outsideness, and that's what's desired here.

> will result in dropped packets. 

A note about this seems reasonable.

> against simultaneous bindings, but, I'm not sure. 

I guess a note about this could be added, too.

> we need to say that it is out of scope, but I'd like to hear other views

I don't see the problem.  If a MIP client in the cellular modem provides
what is (to it) a stable inner IP address, it does so completely
transparently to the IPsec and inner nested MIP tunnel, resulting in
less IP address changes for the IPsec.  So?  This is essentially an
application of RFC 4093 and should be unproblematic.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 09:29:16 -0800

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 8:41 AM
> To: Narayanan, Vidya
> Cc: Mobile IPv4 Mailing List
> Subject: Re: [Mip4] WGLC Comments: 
> draft-ietf-mip4-mobike-connectivity-01.txt
> 
> 
> 
> - it simply says that the solution uses reverse tunnelling 
> through the home agent.  Nothing to clarify.
> 

I'm not saying that it needs to be clarified in the overview, but there
is no clarification on it elsewhere either. If the MN is allowed normal
RFC3344 behavior (where reverse tunneling is optional), nothing needs to
be said. But, as I state below, when a VPN is used, I think reverse
tunneling should be mandatory. Or at least, it should be noted that if
reverse tunneling is not used, packets will be dropped by the VPN GW.

> > When using the HoA for communication, reverse tunneling 
> probably needs 
> > to be mandated when accessing via a VPN - otherwise, the VPN GW is 
> > going to drop the packets. If the VPN is set up to bypass 
> such packets 
> > as well, it will work, if the HoA is a routable address and 
> if there 
> > is no ingress filtering on the local network. But, I'm not sure we 
> > need to allow such a scenario. Alternately, the MN may use 
> its VPN TIA 
> > for communication.
> > 
> > I don't think it is trivial to bypass the VPN to send a MIP 
> RRQ, when 
> > the tunnel outer address is changing and a MOBIKE exchange has been 
> > initiated. This would involve dynamically changing the bypass rules 
> > for the VPN - in fact, it's not clear to me how such a rule 
> might even 
> > work. Obviously, UDP port 434 messages cannot always be allowed to 
> > bypass IPsec. "Bypass UDP port 434 traffic when a link change just 
> > occurred" doesn't quite work. If the MN is using a CCoA, 
> "bypass UDP 
> > port 434 traffic when IP source = local address" might 
> work, but, it 
> > won't work when the MN is using an FA CoA. Also, if the MN 
> discovered 
> > an FA on the local network, how does it know whether or not 
> to use it? 
> > It needs to not use it if that subnet is part of an 
> untrusted network. 
> > I understand that the motivation is to allow an operation 
> with lower 
> > latency, but, I am confused as to how this works.
> 
> It seems to me that a rule to permit traffic to a specific 
> host address and port is trivial to implement.  What's so 
> hard about that?
> 

UDP port 434 traffic to HA cannot always be bypassed and that's the
problem. We want to selectively bypass it only when a subnet change just
occurred - I don't see how there is a good way to do that. At other
times, you want to send MIP RRQs through the VPN tunnel (to register the
TIA as the CoA, for instance). 

> > tunnel, that is always used. If we attempt to solve it as in the 
> > draft, we need a lot more clarity on the following:
> 
> How to do the inside-outside detection isn't trivial, on the 
> other hand, so there is clear value in defining it.  
> Declaring it undefined doesn't help.
> 
> > - What bypass rules are to be used for IPsec? I don't think 
> > hand-waving this is good.
> > - Is the MN allowed to use an FA upon a subnet change? Is this the 
> > same behavior whether the MN is moving from an untrusted or 
> trusted network?
> > - If the MN used an FA, but discovers it is on an untrusted 
> network, 
> > it needs to then obtain a local address to set up a VPN.
> 
> Since the text you're criticizing already states clearly that 
> a local address has been acquired, this is not particularly 
> relevant.  

That is the point - it says "a local address has been acquired" without
stating implications of "what if there was an FA the MN found". Given
that FAs in trusted networks are allowed by the solution, that behavior
needs to be clarified. 

> Sending a RRQ to the i-HA using the acquired local 
> address constitutes a simple and feasible test of 
> inside/outsideness, and that's what's desired here.
> 
<snip>

> 
> > 5. Is a scenario where an MN may connect via a cellular network in 
> > scope for the document? If so, there are a couple of cases 
> to consider here.
> > MIP-IPsec-MIP layering, which I'm not sure we want to get 
> into :) May 
> > be we need to say that it is out of scope, but I'd like to 
> hear other 
> > views on this.
> 
> I don't see the problem.  If a MIP client in the cellular 
> modem provides what is (to it) a stable inner IP address, it 
> does so completely transparently to the IPsec and inner 
> nested MIP tunnel, resulting in less IP address changes for 
> the IPsec.  So?  This is essentially an application of RFC 
> 4093 and should be unproblematic.
> 

I already said that if the MIP client is in the modem, it is not an
issue. It is an issue when the MIP client in the host is expected to
handle MIP for cellular access too - I don't think this model is
deployed today, but, as cellular networks adopt various access
technologies (WLAN, WiMAX, etc.), this model has to change, if mobility
across the interfaces is needed. In that case, it does become an issue. 

Regards,
Vidya

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Dec 2006 19:18:17 +0100

on 2006-12-13 18:29 Narayanan, Vidya said the following:
...
> reverse tunneling is not used, packets will be dropped by the VPN GW.

Ok, that makes sense.

[snip]
> TIA as the CoA, for instance). 

There's no need to create time-dependent or conditional rules here.
Any port 434 from TIA to HA goes through the tunnel.  Any port 434
to HA from other addresses doesn't.

[snip] 
> that FAs in trusted networks are allowed by the solution, that behavior

The inside-outside detection mechanism is described in more detail
in http://tools.ietf.org/html/draft-ietf-mip4-vpn-problem-solution,
if I remember correctly.  If so, a reference to it might help.  If
the text can be read as if you could send the detection registration
to an FA instead of the HA, it should be clarified, although I have
a hard time reading it that way.

> across the interfaces is needed. In that case, it does become an issue.

But then this draft still isn't relevant -- you're still back in the 
RFC 4093 scenario, and the solution of draft-ietf-mip4-vpn-problem-solution
applies, no?

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 11:30:16 -0800

> > problem. We want to selectively bypass it only when a subnet change 
> > just occurred - I don't see how there is a good way to do that. At 
> > other times, you want to send MIP RRQs through the VPN tunnel (to 
> > register the TIA as the CoA, for instance).
> 
> Any port 434 from TIA to HA goes through the tunnel.  Any 
> port 434 to HA from other addresses doesn't.
> 

I don't believe RFC4301 allows this sort of SPD rules set up. The IP
address cannot be a variable in the SPD. Here, the local address of the
MN is changing every time. So, this involves dynamically updating the
SPD value to create a bypass rule for the acquired address and then
sending the RRQ - however, MNs almost never have admin access to create
such SPD rules and I think it would create a security vulnerability to
enable something like this in software. 

> [snip] 
> > 
> > That is the point - it says "a local address has been acquired" 
> > without stating implications of "what if there was an FA the MN 
> > found". Given that FAs in trusted networks are allowed by the 
> > solution, that behavior needs to be clarified.
> 
> The inside-outside detection mechanism is described in more 
> detail in 
> http://tools.ietf.org/html/draft-ietf-mip4-vpn-problem-solution,
> if I remember correctly.  If so, a reference to it might 
> help.  If the text can be read as if you could send the 
> detection registration to an FA instead of the HA, it should 
> be clarified, although I have a hard time reading it that way.
> 

Perhaps, we are talking about different things here. My question is
basically this - when the MN changed subnets, it doesn't know if that is
a trusted or untrusted subnet; if it sees an FA on that subnet, should
it use that FA, assuming it is a trusted subnet first or should it
ignore that and acquire an address to use as CCoA? If the subnet ends up
being trusted, it could be using that FA without a problem. If not, that
address has to be the VPN tunnel outer address. 

If an MN is configured to always use an FA CoA mode within the trusted
network and CCoA mode only when the VPN TIA is used as the CoA, it poses
a problem. 

> >> Sending a RRQ to the i-HA using the acquired local address 
> >> constitutes a simple and feasible test of inside/outsideness, and 
> >> that's what's desired here.
> >> 
> > <snip>
> > 
> >> 
> >> I don't see the problem.  If a MIP client in the cellular modem 
> >> provides what is (to it) a stable inner IP address, it does so 
> >> completely transparently to the IPsec and inner nested MIP tunnel, 
> >> resulting in less IP address changes for the IPsec.  So?  This is 
> >> essentially an application of RFC
> > technologies (WLAN, WiMAX, etc.), this model has to change, if 
> > mobility across the interfaces is needed. In that case, it 
> does become an issue.
> 
> But then this draft still isn't relevant -- you're still back 
> in the RFC 4093 scenario, and the solution of 
> draft-ietf-mip4-vpn-problem-solution
> applies, no?
> 

Hmmm.. I'm not sure. The solution in
draft-ietf-mip4-vpn-problem-solution assumes that the external HA is
part of the enterprise network and handles mobility for all types of
external connectivity. However, in the case under discussion here, the
cellular HA will handle mobility only for the cellular access networks;
there may be other untrusted networks that the MN has to support without
that HA. 

Here's a scenario: 

Let's say that a laptop is connected via ethernet to the intranet, via
WLAN to an untrusted AP and via a data card to a cellular network. It
must now do - direct MIP4 to the i-HA on ethernet, MOBIKE over WLAN, and
MIP-IPsec-MIP (no MOBIKE) on the cellular interface. Alternately, it may
ignore the cellular MIP service and just do MOBIKE with the corporate
VPN GW even over the cellular interface, but I am not sure that is a
practical option, given that there may be times when it is good to use
the available cellular mobility service and that in order to use other
services in the cellular network, it may have to use MIP as well. 

Vidya

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Dec 2006 21:15:53 +0100

on 2006-12-13 20:30 Narayanan, Vidya said the following:
> MN is changing every time.

No, how do you figure that?  As soon as the VPN is set up, TIA is stable,
the local address of the MN is the TIA and is stable, and there's no need
to change the rule setup.

> So, this involves dynamically updating the

See above.  There's no need for dynamic rule update.

> address has to be the VPN tunnel outer address. 

Checking draft-ietf-mip4-vpn-problem-solution, we find that this is
all very clearly described there, so I'd suggest that referencing that
draft would provide answers to all of the above.  

> network and CCoA mode only when the VPN TIA is used as the CoA, it poses

In that case, you'll of course have to complete the inside-outside
determination first, and then re-register if you haven't registered
according to this configuration.  (I've not come across clients with
rules like this, though.)

> services in the cellular network, it may have to use MIP as well. 

This means that it has a double-MIP client setup according to
draft-ietf-mip4-vpn-problem-solution when it is using IPsec over MIP
over cellular; the IPsec TIA from this setup is available to the
inner MIP client in the same way as the local address from the WLAN
and the MOBIKE TIA.

Yes, it is complex, but no, I don't see that we're missing any
components here...

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 12:41:56 -0800

<snip>

> > address cannot be a variable in the SPD. Here, the local address of 
> > the MN is changing every time.
> 
> No, how do you figure that?  As soon as the VPN is set up, 
> TIA is stable, the local address of the MN is the TIA and is 
> stable, and there's no need to change the rule setup.
> 

No, this is not correct. When the MN is trying to register the TIA as
the CoA, it always goes through the VPN - there is no confusion there.
It is the case where the MN has a VPN, but has changed subnets and is
trying to determine the direct reachability of the HA on that subnet -
here, it will attempt to register the newly acquired local address with
the HA to determine if that address can be treated as a MIP CCoA
(trusted network case) or it needs to be treated as a VPN tunnel outer
address (untrusted network case) - so, the RRQ in discussion here is
sent not with the TIA, but with the newly acquired local address. Hence
the problem. 

> > So, this involves dynamically updating the SPD value to create a 
> > bypass rule for the acquired address and then sending the RRQ - 
> > however, MNs almost never have admin access to create such 
> SPD rules 
> > and I think it would create a security vulnerability to enable 
> > something like this in software.
> 

Please see above explanation. 

> >> The inside-outside detection mechanism is described in 
> more detail in 
> >> to an FA instead of the HA, it should be clarified, 
> although I have a 
> >> hard time reading it that way.
> >> 
> > 
> > basically this - when the MN changed subnets, it doesn't 
> know if that 
> > is a trusted or untrusted subnet; if it sees an FA on that subnet, 
> > should it use that FA, assuming it is a trusted subnet 
> first or should 
> > it ignore that and acquire an address to use as CCoA? If the subnet 
> > ends up being trusted, it could be using that FA without a 
> problem. If 
> > not, that address has to be the VPN tunnel outer address.
> 
> Checking draft-ietf-mip4-vpn-problem-solution, we find that 
> this is all very clearly described there, so I'd suggest that 
> referencing that draft would provide answers to all of the above.  
> 

Could you please point me to the section in
draft-ietf-mip4-vpn-problem-solution that points to that? Since that
solution uses MIP for both external and internal mobility, an MN can
always use an FA and it's not a problem. The problem arises here
because, the MN cannot use an FA for external mobility, but can do so
for internal mobility. I see this as a scenario specific to this
solution. What am I missing here? 

<snip>

> draft-ietf-mip4-vpn-problem-solution when it is using IPsec 
> over MIP over cellular; the IPsec TIA from this setup is 
> available to the inner MIP client in the same way as the 
> local address from the WLAN and the MOBIKE TIA.
> 
> Yes, it is complex, but no, I don't see that we're missing 
> any components here...
> 

This draft starts off describing that it is an alternative to the double
MIP solution. But, it appears that in a particular scenario, the double
MIP solution needs to be employed even if the solution in this draft is
in use. That's why I wonder if it is worth describing it. I was not
claiming that there is a missing component - there is a missing
connection between the components. 

Vidya

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 13 Dec 2006 22:48:11 +0200

[snip]
> across the interfaces is needed. In that case, it does become an issue. 

As this draft is mostly intended to enterprise use cases (where the 
enterprise runs its own HA and VPN gateway) I assume that the IT manager 
planning to roll out laptops with a mobility service would not select 
e.g. CMIP mode for the WiMAX access nor intentionally create overlapping 
mobility service solutions etc.

Cheers,
	Jouni

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Dec 2006 22:36:09 +0100

on 2006-12-13 21:41 Narayanan, Vidya said the following:
> sent not with the TIA, but with the newly acquired local address.

*Exactly*.  So rules which says that port 434 from TIA to HA always go
through the tunnel, port 434 from non-TIA to HA never goes to tunnel
will work.  No need for anything more complex.

> Hence

Nope, no problem :-)

> Please see above explanation. 

Again, there's no need for dynamic rule updates.

> solution. What am I missing here? 

You're missing that this is a specific mechanism to determine whether
you're inside or outside, and exactly how that is to be performed is
described in section 3, with handling of FAs (if you want to do that,
which I'd choose only doing when the previous connection was inside)
in subsection 3.4.

Once the inside-outside determination has been done, you can apply
policies or rules you have about exactly what's permitted / mandatory
in the different situations.  This may involve re-registration,
depending on your inside-outside determination implementation and
your policies.

> connection between the components. 

Ok.  I'm fine with the current partition and description, but if the
authors want to update according to your suggestion, that's fine with
me too.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 14:18:23 -0800

<snip>

> 
> *Exactly*.  So rules which says that port 434 from TIA to HA 
> always go through the tunnel, port 434 from non-TIA to HA 
> never goes to tunnel will work.  No need for anything more complex.
> 

A rule to the effect of "UDP Port = 434, Local IP address != TIA, Remote
IP address = HA --> Bypass" is not something that can be set up, in
accordance with RFC4301, as far as I know.  

<snip>

> 
> You're missing that this is a specific mechanism to determine 
> whether you're inside or outside, and exactly how that is to 
> be performed is described in section 3, with handling of FAs 
> (if you want to do that, which I'd choose only doing when the 
> previous connection was inside) in subsection 3.4.
> 
> Once the inside-outside determination has been done, you can 
> apply policies or rules you have about exactly what's 
> permitted / mandatory in the different situations.  This may 
> involve re-registration, depending on your inside-outside 
> determination implementation and your policies.
> 

So, what you are saying is this then - if the MN is moving from an
untrusted network, it needs to first acquire an IP address, try reaching
the HA with it; if the HA is not reachable, use that address as the VPN
tunnel outer address; if it is reachable, either operate in CCoA mode or
then use an FA and re-register with the FA. OTOH, if the MN is moving
from a trusted network, it may use an FA first; determine that the HA is
unreachable, subsequently acquire an IP address and set up a VPN. Is
that correct? 

But, regardless of this issue, I think just bypassing the VPN is an
issue, since I don't think a bypass entry as you indicate is feasible in
IPsec. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 14:28:37 -0800

> From: Jouni Korhonen [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 12:48 PM
> To: Narayanan, Vidya
> Cc: Henrik Levkowetz; Mobile IPv4 Mailing List
> As this draft is mostly intended to enterprise use cases 
> (where the enterprise runs its own HA and VPN gateway) I 
> assume that the IT manager planning to roll out laptops with 
> a mobility service would not select e.g. CMIP mode for the 
> WiMAX access nor intentionally create overlapping mobility 
> service solutions etc.
> 

Maybe, but, I'm not so sure. There are times when I use cellular data
cards and WLAN access on my laptop without connecting to the enterprise.
So, in such situations, I'd want to use mobility on the cellular
network. The setup has to be then such that MIP in the cellular network
is disabled when I'm connected to the enterprise network, and not
otherwise. 

It can be done, of course. It may be worth noting for sake of clarity. 

Vidya

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Dec 2006 23:42:21 +0100

> accordance with RFC4301, as far as I know.  

Why on earth not?  You'd say UDP, Port=434, Dest=HA, Src=TIA (which
is a known, fixed address, just as HA is) --> Tunnel, and if this
isn't taken, you have UDP, Port=434, Dest=HA --> Bypass.

> unreachable, subsequently acquire an IP address and set up a VPN. Is

Yup.

> issue, since I don't think a bypass entry as you indicate is feasible in

Oh, yes.  You'll have to explain why a simple fixed-src-addr,
fixed-dest-addr, fixed-dest-port rule isn't feasible - I see no
problem with it at all.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Dec 2006 18:26:19 -0800

> isn't taken, you have UDP, Port=434, Dest=HA --> Bypass.

It is actually trivial to setup SPD entries so that
you can send one registration request from the local
IP address with the destination set to the HA so that
it bypasses the IPsec engine. There will be one for
the registration request with source address set to
the TIA.

So agree with Henrik here.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Dec 2006 18:39:53 -0800

Hello,

> draft would provide answers to all of the above.  

Yes, we already reference draft-ietf-mip4-vpn-problem-solution.

    Security boundary detection is based on the reachability of the i-HA
    from the mobile node's current point of attachment.  Whenever the
    mobile node detects that it has moved to a new IP subnet [9] and its
    IP address changes, it sends a Registration Request to the i-HA
    without any VPN encapsulation.  If the mobile node receives a
    Registration Reply, then it is assumes that it is on a trusted
    network.  This is based on the mechanism described in [6] to detect
    attachment to the internal trusted network.  The mobile node should
    re-transmit the Registration Request if it does not receive the
    Registration Reply within a timeout period.  The number of times the
    mobile node should re-transmit the Registration Request and the
    timeout period for receiving the Registration Reply are configurable
    on the mobile node.

    [6]   Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across
          IPsec-based VPN Gateways",
          draft-ietf-mip4-vpn-problem-solution-02 (work in progress),
          November 2005.

The only difference is that in this document a MOBIKE update
is sent to the VPN gateway rather than a registration request
to the external HA.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 18:45:36 -0800

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 6:26 PM
> To: Henrik Levkowetz
> Cc: Narayanan, Vidya; Mobile IPv4 Mailing List
> >>> *Exactly*.  So rules which says that port 434 from TIA to 
> HA always 
> >>> go through the tunnel, port 434 from non-TIA to HA never goes to 
> >>> tunnel will work.  No need for anything more complex.
> >>>
> >> A rule to the effect of "UDP Port = 434, Local IP address != TIA, 
> >> Remote IP address = HA --> Bypass" is not something that 
> can be set 
> >> up, in accordance with RFC4301, as far as I know.
> > 
> > Why on earth not?  You'd say UDP, Port=434, Dest=HA, 
> Src=TIA (which is 
> > a known, fixed address, just as HA is) --> Tunnel, and if 
> this isn't 
> > taken, you have UDP, Port=434, Dest=HA --> Bypass.
> 
> It is actually trivial to setup SPD entries so that you can 
> send one registration request from the local IP address with 
> the destination set to the HA so that it bypasses the IPsec 
> engine. There will be one for the registration request with 
> source address set to the TIA.
> 

I am missing something. In a typical remote access VPN setup, there will
be one SA used to protect any traffic being sent from the host. So, the
SPD entry will specify a range of remote IP addresses (typically, either
everything or configured enterprise subnets) that should be protected.
There are corporate VPNs that don't allow any bypass, period. For those
setups, all outbound traffic will be sent using that SA and all
unprotected inbound traffic will be discarded. Where bypassing is
allowed, specific bypass rules need to be in place. If the PROTECT
condition applies (say, where the remote address falls within the range
of configured subnets), the packet will be sent via the VPN tunnel. If
there is a BYPASS rule that applies, it will be bypassed. All other
packets will be discarded. The HA IP address will fall under the range
of addresses within the enterprise subnets that would be setup for a
PROTECT condition in the SPD. 

If you are relying on the order of SPD entries for the bypass rule to
catch it before the protect rule, it is problematic, since that will
result in all RRQs being bypassed. If you go through the protect rule
first, it is going to be protected, given that the HA IP address is
likely to be part of the range of addresses that need protection. 

Also, I'd say that if you expect MIP-specific IPsec SPD entries to be
cumpulsorily present on the host/VPN GW, this document needs to spell
those out. My main problem here is that the document is written such
that it just uses a corporate VPN with MOBIKE capability. I don't see
how that is sufficient. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Dec 2006 19:25:55 -0800

hi Vidya,

> use its VPN TIA for communication. 

The intention was to use reverse tunneling all the
time when coming through an IPsec VPN gateway. How
about the following text?

    The solution described above results in a Mobile IP tunnel inside an
    IPsec tunnel.  The Mobile IP tunnel is between the mobile node and
    the home agent and the IPsec tunnel is between the MN and the mVPN
    gateway.  The mobile node MUST reverse tunnel through the home agent
    [8] when the Mobile IP tunnel is inside an IPsec tunnel.

> will result in dropped packets. 

Would the following text address your concern?

    Some IPsec VPN implementations allow a host to send traffic directly
    to the Internet when attached to an untrusted network.  This traffic
    bypasses the IPsec tunnel with the VPN gateway.  This document does
    not prevent such traffic from being sent out from the host, but there
    will be no mobility or session continuity for the traffic.  Any data
    traffic that is sent through the Mobile IP tunnel with the home agent
    is always sent through the VPN gateway.

> directly. 

The typical behavior when this happens would be for
the client to indicate to the user it is connected to
the trusted network and terminate the IPsec tunnel.
Only the wired connection would be used. At least
thats my experience.

> Is the MN allowed to register both interfaces with the HA?

If you are attached to the trusted network, you
should stop using the connection from the untrusted
network.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 19:42:20 -0800

Hi Vijay, 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 7:26 PM
> To: Narayanan, Vidya
> > otherwise, the VPN GW is going to drop the packets. If the 
> VPN is set 
> > up to bypass such packets as well, it will work, if the HoA is a 
> > routable address and if there is no ingress filtering on the local 
> > network. But, I'm not sure we need to allow such a scenario. 
> > Alternately, the MN may use its VPN TIA for communication.
> 
> The intention was to use reverse tunneling all the time when 
> coming through an IPsec VPN gateway. How about the following text?
> 

Sounds good. 

> > mobility support as well. This is not too different from a MIP MN 
> > using it's CoA for local communication - however, since 
> this document 
> > ties the VPN to MIP, I think it is good to note this - 
> especially to 
> > avoid any implementation issues (ambiguities with respect to what 
> > packets go through MIP processing prior to IPsec processing 
> and what 
> > don't). Any attempt to route packets meant to bypass the 
> VPN through 
> > the MIP stack will result in dropped packets.
> 

Sounds good too. 

> > One of those may be routed through a VPN, while the other may be 
> > routed directly.
> 
> The typical behavior when this happens would be for the 
> client to indicate to the user 

Which client? MIP or IPsec? My IPsec client does not indicate that. 

>it is connected to the trusted 
> network and terminate the IPsec tunnel.
> Only the wired connection would be used. At least thats my experience.
> 

Well, an example is this - we use IPsec over internal WLANs to access
the network. There are several times I forget to disconnect my VPN when
I undock and dock my laptop and it stays on, along with my ethernet
connection. In the cases where we are only talking about external to
internal network transition, it is not that important, since a gap in
physical/RF connectivity is going to cause the VPN to disconnect,
alerting the user of the same. However, if the transition is seamless,
which is hopefully what the world is moving towards, this is a problem. 

> > simultaneously active. So, perhaps the right thing to do is to 
> > recommend against simultaneous bindings, but, I'm not sure.
> 
> If you are attached to the trusted network, you should stop 
> using the connection from the untrusted network.

What I've said above holds. Additionally, I sometimes keep a data card
(say, EV-DO) connected while I'm also attached to an internal network -
this is especially true if I frequently disconnect from the direct
intranet connection, since keeping the data card connected provides more
seamlessness than trying to connect after I've lost my network
connection. 

So, I think we should be planning for having multiple simultaneously
active interfaces and not ruling them out. We can rule them out from a
MIP perspective (say, no simultaneous bindings) and that's probably
okay. 

Vidya

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 14 Dec 2006 11:56:29 +0100

> likely to be part of the range of addresses that need protection. 

WHOA!!!

RFC 4301 clearly specifies that the SPD is an *ordered* database, exactly
for cases like this, where rules overlap and it is important to process
them in the correct order.  This is also what I'd expect from practical
experience.

This is just not a problem.

> that it just uses a corporate VPN with MOBIKE capability. I don't see

Actually, since MIP implementations need to have low-level access to raw
incoming packets, to do their job right, they work through mechanisms
like xBSD's BPF-taps or Windows' various slots low in the IP stack where
drivers can attach.  So the choice of using SPD entries to bypass the
VPN tunnel is only one way of doing this; there are other ways which
also will work fine, and practical experience is probably needed to
determine what approach will be best in which market.  I don't think we
should put all of that in this draft; as an implementor, this seems to me
like something which has to be worked out, but doesn't need to be covered
in the document necessarily.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 14 Dec 2006 23:45:07 +0100

Re-sending this.  Vidya, I still haven't seen a response from you to
this.  Is our discussion complete regarding these points?

	Henrik

WHOA!!!

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 14 Dec 2006 15:47:57 -0800

Hi Henrik,
Apologies for the delay. Vijay and I also exchanged a lot of emails
offline on the topic. Eventually, we figured out that we agree on what
needs to be done (that a bypass entry for the local IP address needs to
be there), but disagree on whether the draft should be providing clarity
on this. I feel that it will help to have some text in the draft, but,
will leave it up to the authors to decide. 

Also, I think it is worth mentioning that enterprise IP addresses may be
visible on untrusted networks, due to transmission of the RRQ, while
bypassing the VPN - the i-HA IP address will be available in the clear. 

Regards,
Vidya 

> Sent: Thursday, December 14, 2006 2:45 PM
> To: Narayanan, Vidya
> Cc: Vijay Devarapalli; Mobile IPv4 Mailing List
> Re-sending this.  Vidya, I still haven't seen a response from 
> you to this.  Is our discussion complete regarding these points?
> 
> 	Henrik
> 
> >> It is actually trivial to setup SPD entries so that you 
> can send one 
> >> registration request from the local IP address with the 
> destination 
> >> set to the HA so that it bypasses the IPsec engine. There 
> will be one 
> >> for the registration request with source address set to the TIA.
> >> 
> > 
> > I am missing something. In a typical remote access VPN setup, there 
> > will be one SA used to protect any traffic being sent from 
> the host. 
> > So, the SPD entry will specify a range of remote IP addresses 
> > (typically, either everything or configured enterprise 
> subnets) that should be protected.
> > There are corporate VPNs that don't allow any bypass, period. For 
> > those setups, all outbound traffic will be sent using that 
> SA and all 
> > condition applies (say, where the remote address falls within the 
> > range of configured subnets), the packet will be sent via the VPN 
> > tunnel. If there is a BYPASS rule that applies, it will be 
> bypassed. 
> > All other packets will be discarded. The HA IP address will 
> fall under 
> > the range of addresses within the enterprise subnets that would be 
> > setup for a PROTECT condition in the SPD.
> > 
> RFC 4301 clearly specifies that the SPD is an *ordered* 
> database, exactly for cases like this, where rules overlap 
> and it is important to process them in the correct order.  
> This is also what I'd expect from practical experience.
> 
> Actually, since MIP implementations need to have low-level 
> access to raw incoming packets, to do their job right, they 
> work through mechanisms like xBSD's BPF-taps or Windows' 
> various slots low in the IP stack where drivers can attach.  
> So the choice of using SPD entries to bypass the VPN tunnel 
> is only one way of doing this; there are other ways which 
> also will work fine, and practical experience is probably 
> needed to determine what approach will be best in which 
> market.  I don't think we should put all of that in this 
> draft; as an implementor, this seems to me like something 
> which has to be worked out, but doesn't need to be covered in 
> the document necessarily.
> 
> 
> 	Henrik
> 
> 
> 
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 15 Dec 2006 01:15:52 +0100

> will leave it up to the authors to decide. 

Ok.  So I take it this means that you don't have any further reservations
with regards to the ability to specify bypass SPD entries or effect bypass
in other ways.

> bypassing the VPN - the i-HA IP address will be available in the clear. 

New topic here.  The observation seems to be correct.  I'll leave it up to
the authors whether they want to comment further on this.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Dec 2006 16:27:21 -0800

> the authors whether they want to comment further on this.

We could add the following text in the Security
Considerations section.

    When the mobile node sends a registration request to the i-HA from an
    untrusted network that does not go through the IPsec tunnel, it may
    be leaking the i-HA's address and its own home address to the
    untrusted network.  This may be a concern in some deployments.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 15 Dec 2006 01:41:30 +0100

Hi Vijay,

>     untrusted network.  This may be a concern in some deployments.

Works for me.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 14 Dec 2006 16:48:25 -0800

Sounds good to me too.  

> Sent: Thursday, December 14, 2006 4:42 PM
> To: Vijay Devarapalli
> >>> Also, I think it is worth mentioning that enterprise IP addresses 
> >>> may be visible on untrusted networks, due to transmission of the 
> >>> RRQ, while bypassing the VPN - the i-HA IP address will 
> be available in the clear.
> >> 
> >> New topic here.  The observation seems to be correct.  
> I'll leave it 
> >> up to the authors whether they want to comment further on this.
> > 
> > We could add the following text in the Security Considerations 
> > section.
> >

---

From: Sami Vaarala <[email-masked]>
Date: Fri, 15 Dec 2006 08:00:36 +0200

>    untrusted network.  This may be a concern in some deployments.

I can live with that, though I think the potential concern is a bit wider.
How about this:

     When the mobile node sends a registration request to the i-HA from an
     untrusted network that does not go through the IPsec tunnel, the request
     leaks some information possibly useful for an attacker.  In particular,
     the request reveals the i-HA address (and other address information),
     the user's NAI (if present), and may provide data which allows an
     off-line brute-force attack on the MN-HA authentication key.

I guess an underlying assumption here has been that the i-MIP setup is not
considered to be confidential.  Some users may be uncomfortable with their
username (NAI) being revealed.

-Sami

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Dec 2006 22:51:32 -0800

Sami Vaarala wrote:
>>>> may be

None of these registration requests from the untrusted
network including the registration request from the
mobile node make to the i-HA. They are all dropped at
the Enterprise firewall.

So I don't understand the brute-force attack on the
MN-HA authentication key.

BTW, this text needs to be added to
draft-ietf-mip4-vpn-problem-solution too.

Vijay

---

From: Sami Vaarala <[email-masked]>
Date: Fri, 15 Dec 2006 09:19:55 +0200

> mobile node make to the i-HA. They are all dropped at

When the MN visits an untrusted network and attempts to send an RRQ to
the i-HA, the RRQ is visible potentially to anyone, including any
attackers.  The RRQ has an authenticator (which may be, for instance,
HMAC-based).  Given the full RRQ packet, a brute force attack on the
HMAC key can be launched; this is an off-line attack because all you
need is the RRQ and you can begin churning away on possible HMAC keys,
the MN-HA authentication data will give you the correct answer for
comparison.  This attack doesn't involve the i-HA in any way, all you
need is the RRQ packet.

> draft-ietf-mip4-vpn-problem-solution too.

Yup, already added.

BR,

-Sami

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Dec 2006 23:40:54 -0800

> comparison.  This attack doesn't involve the i-HA in any way, all you

RFC 3344 is susceptible to this attack.

Vijay

---

From: Sami Vaarala <[email-masked]>
Date: Fri, 15 Dec 2006 09:38:48 +0200

> RFC 3344 is susceptible to this attack.

Naturally, and this is why this wasn't mentioned in security
considerations earlier.  I was personally assuming this would be
clear from context.

However, the point was raised that although the dual MIP solution in
general protects leaks of traffic intended for the internal network,
the i-HA RRQ will leak and reveal some information anyway.  It might
be worth mentioning.  At least if we mention that the i-HA address can
be seen from the i-HA RRQ, we should IMO also mention that the i-HA
RRQ is wide open for all other kinds of abuse as well.

BR,

-Sami

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 15 Dec 2006 00:44:37 -0800

I agree with Sami here. In RFC3344, there is no notion of "enterprise"
level of security. A typical enterprise network will be sensitive to
revealing of internal IP addresses, user names and any crypto data. The
text that Sami sent looks good to me. 

Vidya 

> From: Sami Vaarala [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 11:39 PM
> To: Vijay Devarapalli
> Cc: Narayanan, Vidya; Mobile IPv4 Mailing List; Henrik Levkowetz
> >> When the MN visits an untrusted network and attempts to 
> send an RRQ 
> >> to the i-HA, the RRQ is visible potentially to anyone, 
> including any 
> >> need is the RRQ and you can begin churning away on possible HMAC 
> >> keys, the MN-HA authentication data will give you the 
> correct answer 
> >> for comparison.  This attack doesn't involve the i-HA in 
> any way, all 
> >> you need is the RRQ packet.
> > 
> considerations earlier.  I was personally assuming this would 
> be clear from context.
> 
> However, the point was raised that although the dual MIP 
> solution in general protects leaks of traffic intended for 
> the internal network, the i-HA RRQ will leak and reveal some 
> information anyway.  It might be worth mentioning.  At least 
> if we mention that the i-HA address can be seen from the i-HA 
> RRQ, we should IMO also mention that the i-HA RRQ is wide 
> open for all other kinds of abuse as well.
> 
> BR,
> 
> -Sami
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Dec 2006 08:03:11 -0800

Sami, Vidya,

I am not convinced that there is anything special
here. Any protocol that uses a hash function to
generate a MAC is susceptible to brute force
attacks.

I agree that the IP addresses and possibly the
NAI is revealed.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 15 Dec 2006 08:43:40 -0800

> Sent: Friday, December 15, 2006 8:03 AM
> To: Narayanan, Vidya
> Cc: Sami Vaarala; Mobile IPv4 Mailing List; Henrik Levkowetz
> I am not convinced that there is anything special here. Any 
> protocol that uses a hash function to generate a MAC is 
> susceptible to brute force attacks.
> 

Well, it is the same thing as the IP address and NAI - if the
registrations were only limited to be inside the trusted network, this
would not have been available to an attacker in the untrusted network. 

I don't feel strongly about having this text though. I see Sami's point
and agree with that, but, if you don't include the text on brute force
attacks, that's fine with me. 

Vidya

> I agree that the IP addresses and possibly the NAI is revealed.
> 
> Vijay
> 
> Narayanan, Vidya wrote:
> > revealing of internal IP addresses, user names and any crypto data. 
> > The text that Sami sent looks good to me.
> > 
> > Vidya
> > 
> solution in 
> >> be worth mentioning.  At least if we mention that the i-HA address 
> >> can be seen from the i-HA RRQ, we should IMO also mention that the 
> >> i-HA RRQ is wide open for all other kinds of abuse as well.
> >>
> >> BR,
> >>
> >> -Sami
> >>
> 
>

---

From: Sami Vaarala <[email-masked]>
Date: Sat, 16 Dec 2006 04:39:40 +0200

> attacks, that's fine with me. 

Right, I also think this attack is rather obvious.  I just think that
if we mention that the i-HA address can be easily seen from the RRQ,
many other attacks are also possible: they are all part of the same
"problem".  So I'd prefer that we either (a) don't mention this at all
(because it's fairly obvious), or (b) mention that there are several
vulnerabilities related to the attacker seeing the inner MIP RRQ,
including address/NAI leakage and brute force attacks.

Either way (with or without a security considerations issue) works
for me.  I don't think the clarification is necessary, but it doesn't
do any harm either.

BR,

-Sami

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Dec 2006 11:43:42 -0800

Sami Vaarala wrote:
>>> I am not convinced that there is anything special here. Any protocol 
>>> that uses a hash function to generate a MAC is susceptible to brute 
>>> force attacks.
>>>
>>

Here is some new text

    When the mobile node sends a registration request to the i-HA from an
    untrusted network that does not go through the IPsec tunnel, it may
    be leaking the i-HA's address, its own identity including the NAI and
    the home address, and the Authenticator value in the authentication
    extensions to the untrusted network.  This may be a concern in some
    deployments.

Vijay

---

From: Sami Vaarala <[email-masked]>
Date: Wed, 20 Dec 2006 09:00:20 +0200

>    extensions to the untrusted network.  This may be a concern in some

Sounds best so far.  But why "it may be leaking"?  It is leaking this
information with 100% certainty (we're not assuming any trust in the
network).  Whether anyone is listening is another matter :-)  So how
about this refinement:

    When the mobile node sends a registration request to the i-HA from an
    untrusted network that does not go through the IPsec tunnel, it leaks
    the i-HA's address, its own identity including the NAI and the home
    address, and the Authenticator value in the authentication extensions
    to the untrusted network.  This may be a concern in some deployments.

BR,

-Sami

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Dec 2006 23:22:27 -0800

>    to the untrusted network.  This may be a concern in some deployments.

Ok. Replaced "leak" by "reveal".

    When the mobile node sends a registration request to the i-HA from an
    untrusted network that does not go through the IPsec tunnel, it will
    reveal the i-HA's address, its own identity including the NAI and the
    home address, and the Authenticator value in the authentication
    extensions to the untrusted network.  This may be a concern in some
    deployments.

Vijay