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

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 4 Sep 2002 21:38:17 -0400

Greg,

I think this is good summary. The key point is that the HMIP RCoA is the MNs
address and not the LCoA. Nested MIP makes the same decision and
specifically allows the RCoA to be used as a local home address for local
access traffic (which is why I called it an RoA (cf HoA) rather than an
RCoA), and the RMA in basic Nested is then simply a HA.

As an aside, given the many similarities between HMIP and NestedMIPv6
architecture it might be worth combining these. I'll try to document the
differences in requirements, architecture and features between the two to
see if this is practical, and then have some discussions with Hesham on this
if he is supportive..

Alan.

-----Original Message-----
From: Greg Daley [mailto:[email-masked]]
Sent: 04 September 2002 10:09
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] LMM requirements: security issue

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.

Theo Pagtzis wrote:
> 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)..

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.

> 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?)

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

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

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: Greg Daley <[email-masked]>
Date: Thu, 05 Sep 2002 12:46:45 +1000

Hi Alan,

 > As an aside, given the many similarities between
 > HMIP and NestedMIPv6 architecture it might be
 > worth combining these. I'll try to document the
 > differences in requirements, architecture and
 > features between the two to see if this is
 > practical, and then have some discussions with
 > Hesham on this if he is supportive..

Hesham's definitely the person to talk to on that
one..

In my guess the advantages wouldn't be in MIPv6,
but in NEMOs.  Would it be better to talk about
it over there?

Greg

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Sep 2002 09:12:31 -0700

If we intend to include extended mode into the base spec, and if the NestedMIPv6
work would fold into extended mode, then we should discuss it here.

I think there are a number of issues with extended mode that we need to resolve,
and I assume that any fold-in of NestedMIPv6 would either resolve them or not,
and may perhaps generate more. Would it make sense to maybe spend a little time
seeing if we can resolve them, after Alan and Hesham have had time to chat, then
perhaps make a decision, based on the discussion, whether to keep extended mode
in the base spec or separate it into a different spec?

This would be a way to accelerate progress on basic mode, assuming we have
agreement that the issues with basic mode have been addressed. Also, if people
think that the issues with basic mode haven't been addressed, then perhaps we
could focus on them?

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 05 Sep 2002 11:29:52 -0500

Well, I believe an architecture document is in order here, without it 
how can we proceed in LMM?
For this there is one in table, which states several architectural 
issues without going into protocol details.

Regards,

>think that the issues with basic mode haven't been addressed, then perhaps we
--behcet

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Sep 2002 10:36:13 -0700

Behcet,

There have been some architectural issues raised by Phil on the basic idea of
routing proxies. I briefly brought up this issue with the IAB earlier this year,
and got back only one comment, "not a problem", but there was not an extensive
discussion.

In effect, the idea of routing proxies has already been implicitly accepted with
the Home Agent in both MIPv4 and MIPv6, and with the Foreign Agent, in MIPv4.
The MIPv6 design has attempted to get rid of the latter, so perhaps there is an
issue with re-introducing routing proxies with LMM.

If there is an issue, then I think the WG chairs and ADs should figure out some
way to raise it with the IESG, involving the IAB if necessary, to address it.

I don't think we need a draft, specific to HMIPv6, to address it. If there is a
requirement for a draft, then it should address the architectural implications
of routing proxies in general.

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 05 Sep 2002 13:35:56 -0500

Jim,
  How can you say that we do not need an architecture document? Anytime 
a new entity, e.g. LMA as defined in the requirements draft  is added, 
not only requirements but also architecture document needs to be 
developed, e.g. architectural considerations regarding LMAs, not routing 
proxies (I do not know what are these?).
  As a cochair of Seamoby, you should know this more that anybody else. 
For example you added a small section in RFC 3514 for paging. For CT, I 
saw some drafts. So this is the right way to go.
  Unfortunately LMM first followed the old practice of coming up with 
the solution fast, as in MIPv4 and MIPv6. There has been some correction 
and as a result we have the requirements work that Carl Williams is 
editing.
  We need to complete the correction and come up with an architecture draft.

Regards,

--behcet

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Sep 2002 12:15:19 -0700

Behcet,

<WG member hat on>

> saw some drafts. So this is the right way to go.

RFC 3514 was a mistake. It did not consider paging in the wider context of IP
routing in general, and MIPv6 in particular. If that had been done, paging would
never have been added to the Seamoby charter. I am not going to go into the
details why I believe this, since this mailing list is not the venue for it.

What I am trying to do in this case is learn from my mistakes and recommend to
uplevel the architectural discussion (should the ADs and WG chairs agree there
is a need) so that routing proxies can be considered in the wider context of the
general IP routing architecture.

>   We need to complete the correction and come up with an architecture draft.

Personally, I believe that the IETF has already accepted the concept of routing
proxies in the form of the HA and the FA, so the issue of whether there is an
architectural issue is unclear to me, but I believe it is up to the WG chairs
and ADs to make that determination.

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 05 Sep 2002 16:11:17 -0500

Hello,
 > As a cochair of Seamoby, you should know this more that anybody else. 
For example you >added a small section in RFC 3514 for paging. For CT, I 
saw some drafts. So this is the right >way to go.
I now realized that CT and CAR do not add any new entities, it was only 
paging that proposed new entities as per RFC 3514.
  Koodli's draft  draft-koodli-seamoby-ct-04.txt is entitled:
A Context Transfer Protocol for Seamless Mobility
and NOT

A Context Transfer Framework for Seamless Mobility

as announced. Just looking at the title, I had been mislead. Apologies.
  So, Seamoby's CT and CAR do not seem to need any architecture work.

Regards,

--behcet