Subject: [netlmm] PMIP-MIP interactions

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 25 Apr 2007 19:23:33 +1000

Folks, 

FYI:

http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-mip-interactions-0
0.txt

I didn't see an announcement on the list. 

Hesham

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: <[email-masked]>
Date: Thu, 26 Apr 2007 13:44:33 +0200

Thanks for a very interesting draft. After a quick look at it I got
few initial questions for my clarification.

Firstly, why rfc4283 & 4285 are ruled out of this analysis?

Secondly, the assumption in scenario C (cases in figures 9a and 9b)
for "HoA management and lookup key in the BC" looks a bit odd.
The LMA/HA are the same box; thus they then should be able to share
the same 'policy store'/'subscriber db'. So I would assume having a
mapping HoA -> MN-ID on HA side internally should be easily doable,
depending what prefix was allocated to the MN (and MN-ID) on the LMA
side. I would assume MPD handling requires similar functionality
anyway. Or did I miss something?

Cheers,
	Jouni

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: 25. huhtikuuta 2007 12:24
To: [email-masked]
Subject: [netlmm] PMIP-MIP interactions

Folks, 

FYI:

http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-mip-interactio
ns-0
0.txt

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Apr 2007 05:13:36 -0700

> anyway. Or did I miss something?

A Mobile IPv6 home agent does have the MN identifier
available as part of the IKEv2 exchange. In fact
when HoA allocation is done as part of the IKEv2
exchange, the identifier is associated with the home
address.

As long as the same identifier is used in the PMIPv6
proxy BU, we are ok. We do have a mapping between
the Mobile IPv6 HoA, MN identifier, and the PMIPv6
MN-HoA.

Vijay

---

From: <[email-masked]>
Date: Thu, 26 Apr 2007 14:38:09 +0200

Hi,

See inline. 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 26. huhtikuuta 2007 15:14
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netlmm] PMIP-MIP interactions
> 
> available as part of the IKEv2 exchange. In fact when HoA 
> allocation is done as part of the IKEv2 exchange, the 
> identifier is associated with the home address.

I am under the assumption that the scope of this draft is only
rfc3775 & 3776 and preshared Sas.. at least based on the current
text. Hence the question/concern.

> As long as the same identifier is used in the PMIPv6 proxy 
> BU, we are ok. We do have a mapping between the Mobile IPv6 
> HoA, MN identifier, and the PMIPv6 MN-HoA.

Right. But that requires rfc4877 (or rfc4283 if IPSec is
not desired).

Cheers,
	Jouni

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 26 Apr 2007 22:38:51 +1000

Hi Jouni, 

 > Firstly, why rfc4283 & 4285 are ruled out of this analysis?

=> Not necessarily, I'm not sure about the context of your question though.

 > mapping HoA -> MN-ID on HA side internally should be easily doable,

=> Functionally they are separated, but sure, any two boxes can share the
same credentials in a common database. But, the id of a MN may not be the
same (regardless of shring the db) as far as both functions are concerned.
In other words, within a local domain, every MN may be given a different id
to use from its home domain's id. 

 > anyway. Or did I miss something?

=> I didn't follow this part, can you elaborate? 

Thanks,
Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Apr 2007 07:32:33 -0700

> text. Hence the question/concern.

Even considering RFC 3776, the mobile node identifier is known
to the home agent. The Phase 1 id is the mobile node identifier.
I am only considering dynamic keying here.

> Right. But that requires rfc4877 (or rfc4283 if IPSec is

Both IKEv1 and IKEv2 I would say.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Apr 2007 09:43:53 -0500

Hi Hesham,
Comments inline.

Regards,
Ahmad

> Hi Jouni, 
> 
>  > Thanks for a very interesting draft. After a quick look at 
> it I got  > few initial questions for my clarification.
>  >
>  > Secondly, the assumption in scenario C (cases in figures 
> 9a and 9b)  > for "HoA management and lookup key in the BC" 
> looks a bit odd.
>  > The LMA/HA are the same box; thus they then should be able 
> to share  > the same 'policy store'/'subscriber db'. So I 
> would assume having a  > mapping HoA -> MN-ID on HA side 
> internally should be easily doable,
> 
> => Functionally they are separated, but sure, any two boxes 
> can share the same credentials in a common database. 

[Ahmad]
I am sorry I failed to understand this one. Is not the problem the draft
trying to address in this scenario is the fact that these two boxes acts
as one and handling the CMIPv6 and PMIPv6 sessions as one. no?

If they are two separate boxes, then we are talking about the scenario
in Fig. 8. where there is no issue there. Right?

> But, the 
> id of a MN may not be the same (regardless of shring the db) 
> as far as both functions are concerned.
> In other words, within a local domain, every MN may be given 
> a different id to use from its home domain's id. 
> 
>  > depending what prefix was allocated to the MN (and MN-ID) 
> on the LMA  > side. I would assume MPD handling requires 
> similar functionality  > anyway. Or did I miss something?
>

---

From: <[email-masked]>
Date: Thu, 26 Apr 2007 16:50:10 +0200

Hi Hesham, 

> Sent: 26. huhtikuuta 2007 15:39
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> Subject: RE: [netlmm] PMIP-MIP interactions
> 
> Hi Jouni, 
> 

As far as I understood some of the issues that were brought up could
be solved e.g. by including MN-ID into Bus. If this is the case
why not stating it (my assumption is that the MN-ID for CMIP and
PMIP would be the same anyway, which makes sense when LMA/HA are the
same entity managed by the same operator).

> can share the same credentials in a common database. But, the 

And also sharing the same BC..

> a different id to use from its home domain's id. 

Why would those identities be different? Any particular reason
to do so as the LMA/HA is the same entity hosted by the same
operator?

> => I didn't follow this part, can you elaborate? 

Just were wondering how mobile prefix solicitations are supposed
to be handled.

Cheers,	
	Jouni

>  > From: Hesham Soliman [mailto:[email-masked]]  > 
> Sent: 25. huhtikuuta 2007 12:24  > To: [email-masked]  > 
> Subject: [netlmm] PMIP-MIP interactions  >  > Folks,  >  > FYI:
>  >

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 27 Apr 2007 01:17:43 +1000

> same entity managed by the same operator).

=> Ok, see below.

 > And also sharing the same BC..

=> Hmm, it really depends on the model of operation and address allocation
schemes you have in mind. I think this discussion is good because it partly
illustrates why that scenario is a pain :) more below. 

 > to do so as the LMA/HA is the same entity hosted by the same

=> Sure, for the same reason that a TMSI is used in the mobile's home
network today. I mean, why does the operator give another identity to a
mobile when it's in its home network? I think you should consider the fact
that an LMA and an HA can share the same box, purely incidental. We don't
standardise archtectures in IETF, a protocol should work if the LMA and the
HA share the same box or if for some reason that LMA has changed. Of course
it's useful to see the impacts of certain architectures on the operation of
the final protocol, but assumptions about sharing the same identities and
dbs would limit the operation of the protocol and might also limit the
deployment models. 

There are other cases for having multiple identities, a single MN might use
different ids with different HAs, however, for the purpose of LMM, there may
or may not be a need to have a 1:1 mapping between the permanent ids and
local ids. So, for example, 2 remote identities (e.g. NAIs) may map to one
local identity or two, depending on the deployment requirements. 

 > Just were wondering how mobile prefix solicitations are supposed

=> Well, these are only relevant for the HoA(s). So, in my "preferred"
model, there should be no difference for MPD as NETLMM would not manage the
HoA. 

Hesham

---

From: <[email-masked]>
Date: Thu, 26 Apr 2007 17:33:30 +0200

[macho-snip]

> > rfc3775 & 3776 and preshared Sas.. at least based on the 
> current text. 
> > Hence the question/concern.
> 
> Even considering RFC 3776, the mobile node identifier is 
> known to the home agent. The Phase 1 id is the mobile node identifier.

True... That would void the concerns on unability of mapping HoA to
MN-HoA etc in this scenario. The draft should describe this.

> BU, we are 
> >> ok. We do have a mapping between the Mobile IPv6 HoA, MN 
> identifier, 
> >> and the PMIPv6 MN-HoA.
> > 

Cheers,
	Jouni

---

From: <[email-masked]>
Date: Thu, 26 Apr 2007 18:30:29 +0200

Hi Hesham, 

Thanks for clarifcations. See some more mumbling inline.

> Sent: 26. huhtikuuta 2007 18:18
>  > >  > Thanks for a very interesting draft. After a quick 
> look at  > > it I got  > few initial questions for my clarification.
>  > >  >
>  > > => Not necessarily, I'm not sure about the context of 
> your  > > question though.
>  >
>  > As far as I understood some of the issues that were 
> brought up could  > be solved e.g. by including MN-ID into 
> Bus. If this is the case  > why not stating it (my assumption 
> is that the MN-ID for CMIP and  > PMIP would be the same 
> anyway, which makes sense when LMA/HA are the  > same entity 
> managed by the same operator).
> 
> => Ok, see below.
> 
>  >
>  > >  > Secondly, the assumption in scenario C (cases in 
> figures  > > 9a and 9b)  > for "HoA management and lookup key 
> in the BC" 
>  > > looks a bit odd.
>  > >  > The LMA/HA are the same box; thus they then should be 
> able  > > to share  > the same 'policy store'/'subscriber 
> db'. So I  > > would assume having a  > mapping HoA -> MN-ID 
> on HA side  > > internally should be easily doable,  > >  > > 
> > > can share the same credentials in a common database. But, 
> the  > > id of a MN may not be the same (regardless of shring 
> the db)  >  > And also sharing the same BC..
> 
> => Hmm, it really depends on the model of operation and 
> address allocation schemes you have in mind. I think this 

This has been about the scenarion C and its subcases
where LMA/HA were said to be the same entity.

> discussion is good because it partly illustrates why that 
> scenario is a pain :) more below. 

I don't see all the described pain in Scenarion C with combined 
LMA/HA . That's why I am a bit confused.

>  > > In other words, within a local domain, every MN may be 
> given  > > a different id to use from its home domain's id. 
>  >
>  > Why would those identities be different? Any particular 
> reason  > to do so as the LMA/HA is the same entity hosted by 
> the same  > operator?
> 
> => Sure, for the same reason that a TMSI is used in the 
> mobile's home network today. I mean, why does the operator 

Because of security? Not willing to reveal IMSI over the air.
This analogue is different to what we have here imho.

> give another identity to a mobile when it's in its home 
> network? I think you should consider the fact that an LMA and 
> an HA can share the same box, purely incidental. We don't 

My concerns were about the shared case.

> standardise archtectures in IETF, a protocol should work if 
> the LMA and the HA share the same box or if for some reason 
> that LMA has changed. Of course it's useful to see the 

Right.

> impacts of certain architectures on the operation of the 
> final protocol, but assumptions about sharing the same 

We always tend to have some deployment model/architecure in
mind anyway ;)

> identities and dbs would limit the operation of the protocol 
> and might also limit the deployment models. 

Less options is imho good.

> There are other cases for having multiple identities, a 
> single MN might use different ids with different HAs, 
> however, for the purpose of LMM, there may or may not be a 
> need to have a 1:1 mapping between the permanent ids and 
> local ids. So, for example, 2 remote identities (e.g. NAIs) 
> may map to one local identity or two, depending on the 
> deployment requirements. 

Yes these are possible, of course. However, from an operator
perspective the less identities to handle the better.

>  > >  > depending what prefix was allocated to the MN (and 
> MN-ID)  > > on the LMA  > side. I would assume MPD handling 
> requires  > > similar functionality  > anyway. Or did I miss 
> something?
>  > >
>  > Just were wondering how mobile prefix solicitations are 
> supposed  > to be handled.
> 
> model, there should be no difference for MPD as NETLMM would 
> not manage the HoA. 

Cheers,
	Jouni

>  > >  > From: Hesham Soliman 
> [mailto:[email-masked]]  >  > > Sent: 25. 
> huhtikuuta 2007 12:24  > To: [email-masked]  >  > > Subject: 
> [netlmm] PMIP-MIP interactions  >  > Folks,  >  > FYI:
>  > >  >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Apr 2007 16:36:44 -0700

> MN-HoA etc in this scenario. The draft should describe this.

This is explained in more detail in
http://tools.ietf.org/id/draft-devarapalli-netlmm-pmipv6-mipv6-01.txt

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 27 Apr 2007 10:52:18 +1000

> LMA/HA . That's why I am a bit confused.

=> There is a long list of issues in the draft, including security issues in
the security section. Please let us know which ones you find unreasonable.

 > This analogue is different to what we have here imho.

=> Why is it different? For the same reasons, an operator might not want to
reveal the permanent identifier of the MN. This is more important in this
case given that ARs are storing it and passing it around. 

 > Less options is imho good.

=> Sure, but these are not options, they're deployment models. There are
fairly concrete requirements in the industry today and it would be strange
to develop something new that limits those requirements. 

 > perspective the less identities to handle the better.

=> Yes, but we can't design for one identity only. Operators today use more
than one when they need/have to do so. 

But we're drifting from the main point I'd hoped would be achieved by the
draft. The point is (and Gerardo might add to or disgree with this), running
PMIP for the HoA is not a good idea and should be avoided. The issue of
colocation of the LMA and the HA, while valid, is secondary IMO. There are a
number of other issues for each scenario, but I thought the HoA issue was
the most serious one to consider. 

Hopefully this answers Ahmad's earlier email as well. 

Hesham

---

From: <[email-masked]>
Date: Fri, 27 Apr 2007 23:35:04 +0200

Hi Hesham, 

>  > I don't see all the described pain in Scenarion C with 
> combined  > LMA/HA . That's why I am a bit confused.
> 
> => There is a long list of issues in the draft, including 
> security issues in the security section. Please let us know 
> which ones you find unreasonable.

My concers were (so far) only about the scen C (when LMA/HA
are combined) and the described lack of identities or unability
of doing mapping between HoA - MN-HoA - MN-ID. Because there are
existing ways, either based on protocol extensions or some product
engineering, to help out the situation, I see no issue there that
would become a real problem.

> > > mobile's home network today. I mean, why does the 
> operator  >  > Because of security? Not willing to reveal 
> IMSI over the air.
> => Why is it different? For the same reasons, an operator 
> might not want to reveal the permanent identifier of the MN. 
> This is more important in this case given that ARs are 
> storing it and passing it around. 

Identity protection/hiding whatever is imo different than having
non mappable identities on different access scenarios or not having
identities at all (other than HoA).

[snap]
 
> => Yes, but we can't design for one identity only. Operators 
> today use more than one when they need/have to do so. 

No one is requiring to make a design based on one identity. But
in cases where the device and the subscriber is the same although
the access method changes it makes sense to use the same identity
or identities that are easily mappable.

> But we're drifting from the main point I'd hoped would be 
> achieved by the draft. The point is (and Gerardo might add to 

Yep.

> or disgree with this), running PMIP for the HoA is not a good 
> idea and should be avoided. The issue of colocation of the 

Could be so..

> LMA and the HA, while valid, is secondary IMO. There are a 
> number of other issues for each scenario, but I thought the 
> HoA issue was the most serious one to consider. 
> 

Cheers,
	Jouni

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 30 Apr 2007 11:11:59 +0200

Hi Jouni,

thanks for your comments. Please see inline..

> same entity managed by the same operator).

I agree with you that this specific issue can be solved including
MN-ID in the BUs. There may be other solutions too. But this is
exactly what we did not want to discuss in the draft at least in the
first version.

The draft is listing the issues (most of them may be solved as you
stated). A consequence of this issue, if solved as you suggested, is
that we need to change a rfc3775-compliant MN to work in scenario C. I
think this is an important requirement: the WG should discuss if this
is the right way to proceed (i.e. putting requirements on MIPv6 MNs in
order to support a scenario where PMIPv6 is also used).

Gerardo

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 30 Apr 2007 11:16:24 +0200

Hi Vijay,

a question inline...

On 4/26/07, Vijay Devarapalli <[email-masked]> wrote:
> >> on the LMA

Agree. But the HA operation based on rfc3775 does not imply that this
ID is used in the BU processing, right? Stating that this ID should be
considered in the BU processing is something different from rfc3776,
where this ID is only used in the SA setup.

Gerardo

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 30 Apr 2007 10:59:59 -0700

> From: Gerardo Giaretta [mailto:[email-masked]] 

> where this ID is only used in the SA setup.

When we have a Mobile IPv6 home agent and a PMIPv6 LMA co-located 
on the same box, obviously it has some new/modified functionality. 
Most probably the code is re-used. It would be silly if there are 
two completely independent MIPv6 and PMIPv6 software stacks on the 
same box that don't interact with each other.

Anyway, the new/modified behavior for a combined MIPv6 home agent
and PMIPv6 LMA is documented in draft-devarapalli-netlmm-pmipv6-mipv6.
It would be great if you can review it.

Vijay