Subject: [mobile-ip] LMM requirements

From: Theo Pagtzis <[email-masked]>
Date: Tue, 20 Aug 2002 18:01:07 +0100

Hi all,

  I have read the latest version of the LMM requirements and I have some
comments as well as questions about some of these.

- 3.2.5-> What does the draft define as a security hole? Where can a
security hole be introduced (like in what aspects -signalling or data) ?

- 3.2.5 -> How does the possibility of a DoS attack come into play for
the core LMM function?

- 3.2.1 ->How does a replay attack come into action for the LMA. Does it
mean replay of a sniffed RBU message? Basically does it refer to the RBU
message?

- 3.2.6 ->The security associate with routing, does it refer to the
possibility of forging the entries in the regional binding cache with
the intent of deflecting traffic on a node other than the MN?

-3.2.6 ->what is defined as topological confidentiality within a LMM
domain. If the RA provides the prefix of the LMA how does one envisage
that this can reveal the topology of the domain?? 

A simple traceroute on the RCoA could do that..

-3.3.2 -> when it is said that non-lmm-aware host/HA/MN must
interoperate with LMA is it meant that "the operation of the LMM
function is optional with default mode of operation MIPv6"?

3.3.3 -> must not increase the no. of messages between MN-CN/HA. I take
it you mean global BUs. Increase it in contrast to what though??? Also
"must minimize the global (BU) signalling between MN-peers". What is max
acceptable threshold? Furthermore, I believe that the last statement is
wrong on the same clause. Consider:

It is stated that "The amount of regional (RBU) signalling must not
surpass the amount of global signalling...(used basically under base IP
mobility)". Well the threhold you allow here is fundamentally wrong.
Why?

In mip we have only global signals, say Xg.
In LMM we have global and local signals, X'g and Xi. If you allow (from
the clause) Xi=Xg then it will be that (Xi+X'g)> Xg (unless X'g=0, i.e.
I am still in the home net) which is unacceptable for LMM since its
signalling cost gets bigger than that of base MIPv6.

The relations that must hold are:

 The sum of intra-domain RBU signals must always be less than the number
of BU signal performed under base MIPv6.
 The inter-domain signals for LMM must always be the difference between
the total no. of MIPv6 BU signals and the sum of intra-domain RBU under
LMM. This way the basic equation of Xg = X'g + Xi is always honoured.
You see what we want to achieve is break the multiplicative term Xg of

(k+1)Xg for MIPv6 where Xg is also the number of handoffs

into a much smaller one with the remainder being just additive, i.e.

(k+2)X'g + Xi

I suggest that 3.3.3 is restated to reflect that.

-3.4.1 states that "The LMM complexity.." does that mean "the scaling of
BU/RBU signalling" ? Also if it scales linearly with the size of the
local domain, then it contradicts directly the last statement of 3.4.5.
If I accept 3.4.1 to be the case (subject to proof) then I cannot accept
3.4.5. Please remove 3.4.5 unless there is contradictory evidence.

-3.4.2 states "The LMM must keep the number of host routes to a
minimum". What is this measure of minimum; basically what is considered
to be the maximum?

-3.4.4 I trust that as long as the LMM function does not depend the
MIPv6 function then it will not interfere with it. Besides the LMA is a
major interferer :).. I can only deduce that you do not mean interfere,
but impede the MIP function. If this is the case then the clause must be
removed since it is expressed in detail in 3.5.1, 3.5.2, 3.5.3. If it is
not then just remove it since it does not make sense (at least to me :).

- 3.4.5 From what I understand so far from networking, configuration and
interconnects in networking have nothing to do with IP routing. Do you
mean "route"?

- 3.4.7 states "..header/tunneling overhead caused by LMM must be
reduced on the radio link by compression". The expression to me conveys
semantings of compression on the radio link (i.e. layer 2). LMM works on
layer 3. Thus the above statement is impossible since either the radio
link compresses anything (LMM or not) or we hit a layer violation. I
want to believe that this wants to mean "..caused by LMM must be reduced
by IP header compression (RHOC specs), when the underlying link layer is
wireless due to bandwidth restrictions.". Could we change it to
something like that?

-3.4.8 "..should not prohibit optimal placement of LMM agent..."..while
this is fine..optimal placement of something is bound to be restrictive
on how the topology is configured for LMM, yes? If this is the case then
this conflicts the statement of 3.4.5, where you enforce a must that the
LMM function does not restrict the configuration of the network. If this
is the case should we remove the statement of 3.4.5, or is there a
different rationale?

3.5.1, 3.5.2, 3.5.3 the must on the increase is ok on all of them. What
I believe though is that it should also be a must on the decrease.
Consider:

  latency: if not decrease it stays the same or gets bigger. Well if it
stays the same, we still win on less signalling..sorry latency reduction
is not the selling feature for LMM). But if it gets bigger then it
conflict the "MUST NOT" about increase. 
  The clauses must be revisited to state that "At worst, latency,
service disruption (i.e. latency), and no of messages incurred by LMM
must be the same as in MIPv6"

3.7. Traces of this clause are found in 3.4.5. Please remove the
relevant statement of 3.4.5 

3.9 is rather puzzling. I believe it basically means that LMM and MIP
must interoperate when LMM is available. Fine. The last bit confuses me
though.. I think it tries to say that while the above interoperability
is assumed to exist, optimisation from either end, MIPv6 or LMM MAY be
interoperable with the other. I believe the title of the requirement
must change to "Interoperability between MIPv6, LMM and potential
optimisations."

I would appreciate if on the security requirements somebody could give a
plausible situation that the LMM function is likely to engage.

-- 

thanks

theo
UCL/Mobile Systems Group

---

From: Theo Pagtzis <[email-masked]>
Date: Sun, 25 Aug 2002 16:45:17 +0100

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

---

From: Greg Daley <[email-masked]>
Date: Mon, 26 Aug 2002 11:00:19 +1000

Hi Theo,

It is very simple in Basic Mode HMIPv6 for example, to have
a system which allows HA and CN bindings to an address at
the LMM Agent (the MAP), without modification to the binding
mechanism provided for MIPv6.

This is because there is a 1-to-1 mapping between the
RCoA and the MN in HMIPv6 Basic Mode.

As just another CoA the MN's RCoA (at the LMM) is required
to undergo Return Reachability tests to CNs. Therefore the
HMIPv6 protocol must support the use of RR as an exisiting
authorization protocol, without interfering in the process.

Since the RCoA Addresses provided in Basic HMIPv6 are
uniquely mapped to the MN all packets to that address
(even without mobility headers) are delivered to the MN.

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.  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

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 26 Aug 2002 22:28:53 +0900

Hi Theo and Greg,

I agree with Greg's opinion.
The HMIPv6 is a good representative of LMM, 
and the RCoA in Basic HMIPv6 is uniquely assigned to the MN. 
Therefore, IPSec associations are also negotiated directly 
between MN and CN, without the interference from the LMM Agent.

And, I think that the Extended mode in HMIPv6 must be not involved
in the LMM requirements, but in NEMO (network mobility) requirements.
As you know, the mode is schemed out for supporting a mobile network
by having the Mobile Router act as MAP within the visited network.

Youn-Hee Han
Samsung AIT.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 26 Aug 2002 09:00:08 -0700

Theo,

> they communicate with another in terms of security bindings.

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 26 Aug 2002 09:15:16 -0700

> and also has an trust relationship which allows the MN to

No, end to end security is end to end. It can't  be compromised by involving
someone in the middle. But, as you say, breaking it in the middle isn't required
for basic mode anyway.

As for extended mode, I'm always in favor of making protocols simpler and I have
never really seen the need for it anyway, so I think it could profitably be
dropped from the specification.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 26 Aug 2002 10:09:59 -0700

> by having the Mobile Router act as MAP within the visited network.

I agree. I think extended mode should be taken out of the HMIP draft and moved
into NEMO, since it seems primarily motivated by a desire to support mobile
routers.

            jak

---

From: Greg Daley <[email-masked]>
Date: Tue, 27 Aug 2002 10:23:52 +1000

Hi James and Youn-Hee Han,

 > I agree. I think extended mode should be taken out
 > of the HMIP draft and moved into NEMO, since it
 > seems primarily motivated by a desire to support mobile
 > routers.
 >
 >             jak

We may have to talk in NEMO about the authorization
of route optimization with extended mode HMIPv6.
Since it seems that the current MIP authorization
mechanisms fail if you have a one (R)CoA to many
MN relationship.

If Extended Mode HMIPv6 is useful, then it will
still have to overcome this issue whether here or
in the other place (NEMO).

Hesham,

How do you see the future of HMIPv6 extended mode in
Mobile-ip WG?

Greg Daley