Subject: Re: [mobile-ip] LMM requirements: security issue

From: Theo Pagtzis <[email-masked]>
Date: Tue, 03 Sep 2002 07:37:49 +0100

Hi Greg

 Excuse the late response as I was away for a conference. I am aware of
the mapping that you refer to; what I am find difficult to accept is how
one can "hide" the on-link CoA of the MN (privacy say through giving the
RCoA), without "interfering"?

Consider again the situation:

The MN is represented by the RCoA (which is basicaly the addr of the LMM
agent)

It provides to the CN and HA the RCoA addr as _its_ address. So the CN
is made to believe that it sets a security association (at the tunnel
level since the socket would be aware only of the home address) with the
MN. But the tunnel is securely associated with the LMM agent (which
indirects the packet to the MN).

Isn't that considered interference of the LMM agent in the security
bindings of the MN-CN?? I though it LMM was all about interference of
the LMM agent (hence the indirection)..

Greg Daley wrote:
> 
> All security associations are between the MN and the CN
> (e-to-e), if the MN can send CoT messages reverse tunnelled
> to the MAP. 

Exactly...who sets this reverse tunnel, and on behalf who?? (IMHO the
LMM agent injects to the MN what must be considered its CoA (i.e. the
RCoA) the CN "buys" that and sets the SA for the tunnel with the LMM
agent. Of course RR ensures that this is secure but, if that is not
interference, then what is it?)

I fear that privacy of the MN and interference of the LMM in the
security binding of the MN are a bit conflicting since LMM is all about
interference (i.e. the link between MN/CN is attributed privacy through
indirect interference of the LMM agent)

Isn't that the case?

theo

 IKE negotiated IPSec associations are also
> negotiated directly, without the interference from the
> LMM Agent.
> 
> In the case with the current HMIPv6 extended mode, the RCoA
> is shared, and therefore the RR CoT may not be performed
> without interference from the Extended MAP.  This means that
> Extended Mode HMIPv6 breaks this LMM requirement as specified
> today.
> 
> As it stands, I think that HMIPv6 extended mode is about to
> be modified.
> 
> The statement in the LMM draft sounds OK, but is it really
> necessary, if the MN has identified the LMM agent, and trusts
> it?  Couldn't the security associations be formed with the
> help of the LMM, since it owns the address which
> is being used for a regional care-of-address (or defends it
> on the LMM's link, which amounts to the same thing),
> and also has an trust relationship which allows the MN to
> use the RCoA?
> 
> So, seeing that we can have two worlds (with the HMIPv6 Basic
> mode LMM case) where e-to-e security associations and location
> privacy is maintained,
> is it necessary or desirable to have the e-to-e security
> association/negotiation , precluding the mediation of the
> LMM agent?
> 
> Greg Daley
> 
> Theo Pagtzis wrote:
> > In addition to what I have mentioned previously I would like to add that
> > I believe that two more requirements are conflicting about security:
> >
> > In A:
> >    it is required that the LMM agent does not interfere with the
> > security bindings between the MN and the peers
> >
> > whereas on B:
> >
> >  it is required that the MN preserves location privacy under LMM.
> >
> > I cannot see how one can maintain location privacy (B) of the MN without
> > breaking the end-to-end principle (A) in terms of security bindings. If
> > the LMM agent is not to interfere with the security bindings of the
> > MN-peers that means it cannot "hide" the MN.
> >
> > No interference by the LMM agent in the security bindings to means that
> > the bindings are effected end-to-end, ie. the MN with a peer CN (and the
> > respective on-link CoAs), or the MN and the HA. But the MN has to
> > provide the regional CoA which is the addr of the LMM agent. That
> > implies that any security binding effected...is effected between the LMM
> > agent and the CN/HA. This is clearly violation of the end-2-end
> > principle, since the peers think they communicate with one node, while
> > they communicate with another in terms of security bindings.
> >
> > Thus, if one wants to keep location privacy in the requirements, I
> > believe he has to kiss goodbye end-to-end security bindings. The
> > opposite may also be the case; however both of the cases are mutualy
> > exclusive. We _cannot_ have both worlds...unless somebody can convince
> > for the opposite without violating the end-2-end principle.
> >
> > In fact when it comes to security between the MN and the peers, this is
> > the first time that peers MUST know who they are talking to (i.e. not
> > the MN, but a trusted representative of the MN), and thus the peers have
> > to be injected with special functionality over security functions. That
> > is to say, that LMM is transparent to the peers until the time the
> > scheme requires security between the MN and the peers.
> >
> >
> >
> > theo
> > UCL/Mobile Systems Group
> >

-- 

thanks

theo

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 03 Sep 2002 07:45:04 +0100

Hi James,

  What I am pondering about is the conflict of "interference" of the LMM
agent with the security bindings, while it aims to provide privacy to
the location of the MN at the MN peers.

The LMM clearly injects a RCoA addr in basic mode, into the MN, which is
suppossed to be believed by the CNs of the MN (even with RR) at the CoA
of the MN. On this basis the SA for the tunnel between the CN and the
LMM agent are set (am I wrong?). Isn't that interference??

My concern is the conflict of "privacy" with "interference" and the
inherent property of indirection in LMM which is really the very
semantics of "interference" (at least in my mind)

am I mistaken?

theo

James Kempf wrote:

> Theo,
> I don't see how this follows. It the MN is performing the regional care of
> address binding update, it can provide the proper security credentials. With the
> Home Agent, it uses the IPsec security association required for Mobile IPv6.
> With any correspondent nodes, it uses RR or some other algorithm.
> 
> Am I missing something?
> 
>             jak

-- 

thanks

theo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Sep 2002 11:27:01 -0700

Theo,

> semantics of "interference" (at least in my mind)

I think you are specifically talking about using a routing proxy for LMM, such
as HMIP, as opposed to directly using the routing fabric, right? If you use the
routing fabric, there should be no issue with security.

I can't see an issue with basic mode HMIP. The MAP doesn't touch the inside of
the packet in basic mode, it just tunnels to the MN. The signaling to change the
RCoA is between the MN and the HA, the MAP never gets involved. The MN delegates
the routing to the MAP and must provide the proper credentials to the HA to
effect that delegation.

Extended mode has a problem, because it removes the HA tunnel. So far, I've seen
no suggestion from anybody about how to solve the problem. If we can't figure
out how to solve it, I think we should remove extended mode from the spec.

There is, of course, an issue of whether the MN can trust a MAP to act as a
routing proxy for it. Some kind of authentication procedure is required,
otherwise, anybody could advertise as a MAP. Since the MAP is not part of the
routing fabric, the authentication procedure must be separate from the
authentication between the MN and its access router, though perhaps related.

There are also nonsecurity related issues (tunnel overhead, single point of
failure, etc.) involving a routing proxy approach.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 04 Sep 2002 10:38:35 +1000

Hi Theo,

It's certainly a very important issue
(e-to-e security association).  I'll try to indicate how
I see things, especially regarding the security aspects.

> the LMM agent (hence the indirection)..

How I see the issue with HMIPv6 Basic is that there is an address at
the MAP, which is delegated to the MN through a security association
and a binding with the MAP. The LMM agent (MAP) then treats the
address specially, but doesn't interfere with packets sent and received 
from this address.

All packets bound for this address are proxy neighbour discovered,
and sent on, just in the same way that a home agent in MIPv6 does.
No packets are received and processed by the LMM agent as its own.
It's a router with host-specific dynamic tunnels to the MN's LCoA.

The idea is that the address is not the MAP's, it's the MN's, but
managed by the MAP.

> interference, then what is it?)

Reverse tunnelling can be provided as an advertised service by the MAP.
If there is such a binding/SA pair with the MN, it can send packets
with the RCoA as source address, in order to get around ingress
filtering.

This just means that the packets are sent
[Src:LCoA,Dest:MAP,Payload[Src:RCoA,Dest:CN,Payload:Y]]

and decapsulated by the MAP (which explicitly allows this
type of tunnel).

the MAP, which has done a proxy DAD for the RCoA on its link
knows that it may send the de-encapsulated packet out onto the
link.

the packet looks like:

[Src:RCoA,Dest:CN,Payload:Y]

This is equivalent of MIPv6 reverse tunnelled services provided by
HA's, if no route optimization is used.

on access networks where MN's may use the RCoA as a packet source
address, location privacy is accomplished trivially by the MN.

As you see, in neither the CN->MN nor the MN->CN direction does
the LMM agent treat the packets as it's own. It is a dynamic tunnel
server, which uses bindings to determine

> indirect interference of the LMM agent)

I'd say that the security and privacy provided by tunneling
has actually been removed through the route optimization
interactions in MIPv6.  The ability of the MN to select an
LMM agent which can provide these services (based on the
removal of the RO requirements in the access network) are
a re-instatement of those capabilities.

In those situations where the CN doesn't need RO capabilities
in MIPv6, the same services can be provided with a HA.
In every case, the HA does not interfere with any communications
between the MN and CN, except to provide dynamic tunnels for a home
address (which is the real address of the node).

 From my point of view, in HMIPv6, the RCoA is the real address
of the MN.  The LCoA is just an address it found on the visited
network.

Greg

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 04 Sep 2002 10:40:36 +0200

Hello Theo,

> The MN is represented by the RCoA (which is basicaly the addr of the LMM

In the Basic mode, the RCoA is  ONE addr of the LMM agent ...not THE address...

> the LMM agent (hence the indirection)..

In the basic mode, the MAP is not a proxy it only redirects the packets to the
LCoA...
The MAP relays all packets to the MN including the IKE packets...as a result
the SA is e2e i.e.
between the MN and the CN (the MAP is not involved there)....
So i don't see any problem here...
cheers,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 04 Sep 2002 14:30:26 +0100

Hi Greg,

 some comments in line..

The LMM agent (MAP) then treats the
> address specially, but doesn't interfere with packets sent and received

ok..but the defence of the RCoA from the "remote" HA function in the LMM
agent would create a nested tunnel..right? If RO capability is not
active at the real HA that implies a permanent nested (double) tunnel.
Isn't that fattening up the header overheads..?

> HA's, if no route optimization is used.

I thought we agreed at some point that packets sent out by the MN are
_NOT_ routed through the LMM agent, I thought we said that a requirement
is that dynamic routing would prevail...at the very least for the return
path between the MN-CN.

i.e. there is no need for a reverse tunnel between the MN and the LMM
agent.

Has that changed???

> address, location privacy is accomplished trivially by the MN.

That assumes that ingress filtering is not happening on these access
networks. How is the MN going to know that there is not ingress
filtering so as not use the RCoA as the source address? Even more how
would it know that there is not ingress filtering so as not to require
the reverse tunnel??

> a re-instatement of those capabilities.

well if a full blown "visited" Home Agent resumes the role of the LMM
agent, then the remote Home Agent MUST not offer route optimisation if
availability of LMM capability is to be effected. In such case, only the
"root" Home Agent (i.e. the one on the home net) may offer RO
capabilities. 

> of the MN.  The LCoA is just an address it found on the visited

The _real_ address of the MN, is and will always be the on-link care of
address. Now you suggest you may want to abstract that address with a
RCoA obtained from the prefix of the LMM agent sitting on the edge of
the defined net domain. This RCoA is further abstracted by the home
address of the MN..

So for every on-link CoA an RCoA must exist plus the tunnel from the
defence of the RCoA (local to the LMM agent) towards that on-link CoA.
That means that for a million subscribers you are going to need three
million addresses for the LMM function...(home,RCoA, LCoA) ...is that
acceptable?

-- 

thanks

theo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Sep 2002 10:17:10 -0700

Theo,

> Isn't that fattening up the header overheads..?

The MN only needs to do RO once when it starts the converstation with the CN,
because the MAP stays fixed. RR should work because the packets are tunneled
from the MAP to the MN.

> i.e. there is no need for a reverse tunnel between the MN and the LMM

I don't think this can work if there is ingress filtering on the access router.
The source address on the packet issuing from the MN must be the RCoA. So the MN
would have to tunnel back through the MAP.

> would it know that there is not ingress filtering so as not to require

Yes.

> million addresses for the LMM function...(home,RCoA, LCoA) ...is that

I'm not sure I follow your reasoning. Why would there need to be more than one
RCoA per mobile node?

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 05 Sep 2002 10:11:03 +1000

Hi Theo,
This is getting long, but interesting

> Isn't that fattening up the header overheads..?

Extended Mode HMIPv6 dispenses with the double tunnel.
Unfortunately there are some issues with CN signalling (CoT)
and ESP tunneled IP packets.

(For Basic Mode)
Certainly the overhead is something which must be considered
for real applications as it lowers the effective MTU.
I'm not sure how much this will affect the use of HMIP

It is interesting to note that other methods of handover
smoothing in mobileip (BETH, most of the FH drafts, MIPv6
signalling to previous AR) all employ double tunnels for non RO
packets.

Most of the other tunnelling mechanisms can be ignored in networks
which combine HMIPv6 with FH or vanilla MIPv6.

[ Some of my old comments cut]
> i.e. there is no need for a reverse tunnel between the MN and the LMM

There is only one point where reverse tunnels may be needed.
That is if it is not possible for the MN to send a CoT to the
CN using the RCoA as source address (due to ingress filtering).

In this case it will be necessary to reverse tunnel that packet.

(the MAP advertisement has no I or P bit in the MAP option).

I guess this will need some additional specification in HMIPv6

> would it know that there is not ingress filtering so as not to require

The MAP Advertisements indicate whether or not the RCoA MAY or MUST
be used as a source address to CNs. (I and P bits in the HMIPv6 spec).

This is up to the MAP and ARs to advertise correctly, based on the
configuration of the network.

[older section snipped]
> "root" Home Agent (i.e. the one on the home net) may offer RO

I'm not sure what you mean here.

The MN is in charge of what RO is done. a HA just
tunnels packets.

A MAP just tunnels RO'ed packets or double encapsulates
already tunnelled packets (maybe not the best).

If what you mean is that we RO to exclude the Local HA/MAP/RCoA,
instead going to the LCoA, then, certainly, there is no LMM.

> the defined net domain. This RCoA is further abstracted by the home

Well that's mobile-ip for you ;)

I meant "real" as what you tell everyone else to route to.
the abstraction is required if you want the privacy and
limitation of signalling.

If you want to have an ongoing conversation while moving networks,
then the HoA is needed.

If you want to reduce the amount of signalling to HA/CNs,
you have to provide some abstract target for them to fire packets
at.

AFAIK that's LMM.

> million addresses for the LMM function...(home,RCoA, LCoA) ...is that

I think so.  Even if one MAP handles all those nodes, they will all
still fit into the one /64 network of RCoAs.

The LCoA and the HoA are the cost of doing MIPv6.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Sep 2002 18:33:17 -0700

> which combine HMIPv6 with FH or vanilla MIPv6.

None of these involve tunneling over the air though. There has been speculation
that header compression can remove the overhead, but I haven't seen a definitive
statement from ROHC whether it is possible.

> CN using the RCoA as source address (due to ingress filtering).

Why is this restricted to the CoT? Won't the MN have to put the RCoA on all
packets? Otherwise, the CN won't have the right source address.

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 05 Sep 2002 12:30:29 +1000

Hi James,

the RCoA doesn't go on all packets sent from the
MN, the Home Address destination option is.

the Binding which the CN has takes care of the
sending to the RCoA.

Of course the RCoA must be sent as an Alt-CoA in
BU packets which use the LCoA as source.

MIPV6 handover smoothing does require double tunnelling
over the air interface.  As you say though, FMIPv6
doesn't (but I'm not sure what's the future there ?!)

I'm not relying on header compression though, if
HMIPv6's encapsulation overhead is not a killer,
then the limitation of signalling and location privacy
are still valuable (the same may be said for BETH, too).

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 05 Sep 2002 07:38:24 +0100

> I'm not sure how much this will affect the use of HMIP

neither am I, I'm just observing the fact.. ;)

> signalling to previous AR) all employ double tunnels for non RO

ok

> I'm not sure what you mean here.

what I mean is that there are two route optimisations that can be
effected since we have two home agents on a per handoff transition
basis:

1) the route optimisation that eliminates the need of going through the
home HA. Such optimisation does not stop you from going to the visited
HA.
2) the route optimisation that eliminates the need of going through the
visited HA. That effectively stops availability of the LMM capability on
the visited domain (ok optimal placement of the LMM agent would bring
the traffic through it anyway..I am talking about the random placement
of LMM)

> Well that's mobile-ip for you ;)

:)...well the abstraction is happening for MIP on a per IP handoff
transition. The RCoA case happens on a per inter-domain IP handoff
transition. So it is not MIP but localised MIP ;)

> limitation of signalling.

true and agreed.

cheers

theo

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 05 Sep 2002 07:28:51 +0100

> because the MAP stays fixed. RR should work because the packets are tunneled

agreed, I was observing the case of "fat" packets... (nested tunnels -
the bio term :) 
I think this is going to be _the_ issue in next generation of IP
protocols.

> would have to tunnel back through the MAP.

yes, I realised that from the start of the discussion. I guess it is an
isolated case for ingress filtering, for which I don't see any reason to
make life more complex..by trying to avoid it..

> I'm not sure I follow your reasoning. Why would there need to be more than one

because in the pure sense of the HA function (the remote one) and in
basic mode you must provide a different RCoA to the MN so that you can
establish the tunnel transparently...otherwise you must consult your
host route table and then route the packet to the correct tunnel, which
to me seems extra processing on the LMM agent. This is at least the
understanding that I got so far.., i.e. that with a proxy neighbour
advert the MN configures a RCoA topoligally correct on the abstract
(defended) net of the LMM agent (local HA function), the address is then
defended (i.e must be unique mapping in the neighbour cache and then
forwards it to the right tunnel..

am I wrong ?

-- 

thanks

theo

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Sep 2002 11:18:40 -0700

Greg,

> BU packets which use the LCoA as source.

But that still means that the RCoA must go on packets where there is no binding
cache entry at the CN. Using the Home Address Option in this case is explicitly
forbidden by the latest drafts of the MIP spec as a security risk. These packets
would have to be tunneled back through the MAP.

> doesn't (but I'm not sure what's the future there ?!)

No, it does not. None of the FMIPv6 algorithms require any over the air
tunneling.

> are still valuable (the same may be said for BETH, too).

From a carrier's perspective, any encapsulation overhead on the access link is
unacceptable. We need to verify (and I believe this is stated in the
requirements draft) that this can be removed by header compression, and,
specifically, that handover does not cause a large drop in performance due to
the compression engine needing to be restarted.

            jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 06 Sep 2002 10:34:17 +1000

Hi James.

I've made some responses inline.

James Kempf wrote:
> But that still means that the RCoA must go on packets
 > where there is no binding cache entry at the CN.
 > Using the Home Address Option in this case is explicitly
 > forbidden by the latest drafts of the MIP spec as a
 > security risk. These packets would have to be tunneled
 > back through the MAP.

That's correct. In setting up a binding in the Basic HMIPv6
case, either the RCoA may be sent as source address (!? if
ingress filtering allows) or the packets have to be
reverse tunnelled to the MAP.

This is necessary only when no binding exists, and before the
BU.

> No, it does not. None of the FMIPv6 algorithms require
 > any over the air tunneling.
> 
> 
> 
> From a carrier's perspective, any encapsulation overhead on
 > the access link is unacceptable. We need to verify (and I
 > believe this is stated in the requirements draft) that this
 > can be removed by header compression, and, specifically, that
 > handover does not cause a large drop in performance due to

Certainly this is outside my experience, I'm not
sure what the case is today.

I'll have to think and read a bit about that issue.

Greg.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Sep 2002 09:29:50 -0700

> I'll have to think and read a bit about that issue.

I think we need to get someone from the ROHC group who understands the
compression algorithms to take a look at the problem and render an opinion.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Sep 2002 09:51:36 -0700 (PDT)

> compression algorithms to take a look at the problem and render an opinion.

I haven't been following this very closely, but
it's worth pointing out that mobility != cellular
3G. 802.11 for one couldn't care the least about
compression considerations, and 3G is certainly
not the end of the line for cellular. We should be
first and foremost concerned about security here
because *it* is a consideration that ain't going
to change. I'm not adverse to trying to make
things ROHC friendly, but ROHC should not be the
overarching design consideration; if it's needed
and ROHC can't deal with it... what exactly is the 
alternative, and what are its security properties?

		 Mike