Subject: RE: [netlmm] I-D Submission: draft-sgundave-mip6-proxymip6-01.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Feb 2007 00:28:33 -0600

Hi Vijay,

A couple of comments/questions below.

Regards,
Ahmad

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 12:23 PM
> To: Gerardo Giaretta
> Cc: netlmm
> Subject: Re: [netlmm] I-D Submission: 
> draft-sgundave-mip6-proxymip6-01.txt
> 
> catching up with some old emails....
> 
> Gerardo Giaretta wrote:
> 
> > So the HA will accept a PBU for a binding cache entry 
> created by the 
> > MN via RFC 3775 signaling?
> 
> Very much. The binding cache entry can be updated either 
> using a binding update from the mobile node or a proxy 
> binding update from a PMA. IMO, this should be supported.
> 
> > It does seem a big depart from RFC 3775 security model.
> 
> As long as the HA sees the PMA as being authorized to send 
> proxy binding updates for the mobile node's home address, we 
> don't break the security model assumed in RFC 3775.

[Ahmad]
I assume that there are many MAGs which are authorized to send BUs?
In the case of RFC3775 security model only the MN can sends a BU to its
HA to inform it with its current location at the current time. Do not
you think that now there are more than one node which can claim the same
thing for the same MN?

> 
>   >> At this point the
> >> mobile will detect its home and send a dereg and that 
> message will be 
> >> tunneled back to the home via the proxy tunnel. The home agent, in 
> >> this scenario, needs to accept dereg from the pmip tunnel 
> and should 
> >> acknowledge back.
> >>
> > 
> > But when the HA processes this new BU, doesn't it remove 
> the binding 
> > cache entry mentioned above (i.e. the CoA of the PMA)?
> 
> No. Once the binding cache entry has been updated using a 
> proxy BU, and if the home agent receives a de-registration BU 
> from the mobile node after that, it should just send a 
> binding ack back to the mobile node with the success status '0'.

[Ahmad]
I am sorry, how would the LMA/HA decides that the MN does not really
mean de-registration at this moment?

> 
> And yes, we need a some more detail on the home agent which 
> describes how it should process proxy binding updates and 
> binding updates that update the same binding cache entry.
> 
> Vijay
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 

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

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 2 Feb 2007 11:16:45 -0800 (PST)

> mean de-registration at this moment?

Discussed with Gerardo on this topic.

Home Agent on receiving a Binding Update message message with lifetime=0,
directly from mobile, if the message is received on the PMA-HA tunnel,
it should simply ignore the message. Note that the BU message, if sent
from the mobile, will arrive from the  PMA-HA tunnel.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Feb 2007 16:18:49 -0600

Hi Sri,

Just to make sure that we are on the same page, what you are saying is
that whenever LMA/HA receives a CMIP BU on a PMIP tunnel with lifetime
of zero, LMA/HA will acknowledge the BU without deleting the BCE. Is
that right?

Having said this and since this BU is a CMIP BU, I would like to bring
to the discussion what RFC3775 says on de-registration, (BU with
lifetime of zero)

RFC3775 Under section 6.1.7:
"
Lifetime: 
....  A value of zero indicates that the Binding Cache entry for the
mobile node MUST be deleted.
"

Regards,
Ahmad

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Friday, February 02, 2007 1:17 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; Gerardo Giaretta; netlmm
> Subject: RE: [netlmm] I-D Submission: 
> Home Agent on receiving a Binding Update message message with 
> lifetime=0, directly from mobile, if the message is received 
> on the PMA-HA tunnel, it should simply ignore the message. 
> Note that the BU message, if sent from the mobile, will 
> arrive from the  PMA-HA tunnel.
> 
> Thanks
> Sri
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 2 Feb 2007 15:41:06 -0800 (PST)

Hi Ahmad,

> of zero, LMA/HA will acknowledge the BU without deleting the BCE. Is

Yes. If the associated BCE entry for that mobile exists and has the
Proxy Registration flag turned ON, the BCE must not be deleted for
dereg message that are received from the tunnel and sent by the
CMIP enabled mobile. This will ensure, the mobile after detecting the
home link, will not remove the binding established due to proxy
registrations. This check is required.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Feb 2007 18:48:12 -0600

Hi Sri,
Thanks for the quick reply. I hope that we can continue this discussion
until we nail all the details down.

Regards,
Ahmad

> Sent: Friday, February 02, 2007 5:41 PM
> Yes. If the associated BCE entry for that mobile exists and 
> has the Proxy Registration flag turned ON, the BCE must not 
> be deleted for dereg message that are received from the 
> tunnel and sent by the CMIP enabled mobile. This will ensure, 
> the mobile after detecting the home link, will not remove the 
> binding established due to proxy registrations. This check is 
> required.
> 

[Ahmad]
My guess is that your logic behind this recommended behavior is the
following:

1. Since the P-MIP BCE flag is set, you consider this entry a non-CMIP
BCE for this MN.
2. This behavior is valid only with the following restrictions:
2.1. LMA/HA receives a CMIP BU with Lifetime ZERO on the PMIP tunnel,
and
2.2. The CMIP BU is requesting a return to home de-registration as per
section 11.5.4. in RFC3775.
2.3. This only valid when both CMIP and PMIP BCE are collocated at the
same box.

agree.?

If the above is a correct logic, then I would recommend that LMA/HA
sends a BA with error code 133 and this way, we will be inline of
RFC3775 section 10.3.2.:
"
o     If the receiving node has no entry marked as a home registration
      in its Binding Cache for this mobile node, then this node MUST
      reject the Binding Update and SHOULD return a Binding
      Acknowledgement to the mobile node, in which the Status field is
      set to 133 (not home agent for this mobile node).
"

Finally, I see that you recommend clear separation between the CMIP BCE
and PMIP BCE. Is that a true reading?
And I assume that this does not preclude the MN, at any time when it has
a CMIP BCE, from being able to de-register any of its CoA. Right?

Thanks again.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 Feb 2007 22:54:13 -0800

> you think that now there are more than one node which can claim the same

One of the main security threats we wanted to prevent
when RFC 3775 was being standardized was to prevent
a mobile node from sending binding updates for another
mobile node's home address. We also wanted to prevent
a mobile node from creating security associations on
behalf of another mobile node. That is why you see all
that text in RFC 3775. There were no MAGs or PMA
sending BUs on behalf of the mobile node when RFC
3775 was written.

Now the home agent (pHA) has to allow the mobile node
and all authorized PMAs/MAGs to modify the binding
cache entry for the mobile node.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 3 Feb 2007 01:40:45 -0600

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Saturday, February 03, 2007 12:54 AM
> Cc: Gerardo Giaretta; netlmm
> >> Very much. The binding cache entry can be updated either using a 
> >> binding update from the mobile node or a proxy binding 
> update from a 
> >> PMA. IMO, this should be supported.
> >>
> >> As long as the HA sees the PMA as being authorized to send proxy 
> >> binding updates for the mobile node's home address, we don't break 
> >> the security model assumed in RFC 3775.
> > 
> > [Ahmad]
> > In the case of RFC3775 security model only the MN can sends a BU to 
> > its HA to inform it with its current location at the 
> current time. Do 
> > not you think that now there are more than one node which can claim 
> > the same thing for the same MN?
> 
> One of the main security threats we wanted to prevent when 
> RFC 3775 was being standardized was to prevent a mobile node 
> from sending binding updates for another mobile node's home 
> address. We also wanted to prevent a mobile node from 
> creating security associations on behalf of another mobile 
> node. That is why you see all that text in RFC 3775. There 
> were no MAGs or PMA sending BUs on behalf of the mobile node when RFC
> 3775 was written.
> 
> Now the home agent (pHA) has to allow the mobile node and all 
> authorized PMAs/MAGs to modify the binding cache entry for 
> the mobile node.

So I do not understand, Are we breaking/relaxing RFC3775 security model
or not?

One more thing, Just for one second, let us imagine that we are looking
at the security model that has been adopted by RFC3775 and we have the
chance to change/modify it. Having in mind our current PMIP requirement,
would you agree to a security model which allows certain MNs to send BUs
on behalf of other MNs as long as they are authorized to do so? In other
words, do you think that is a secure model?

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 03 Feb 2007 08:46:09 -0800

> So I do not understand, Are we breaking/relaxing RFC3775 security model

We are not breaking or relaxing anything. The security
model when you have the same home agent supporting both
MIPv6 and PMIPv6 is slightly different from what is
assumed in RFC 3775. Apart from the MN, authorized (and
authenticated) PMAs are also allowed to modify the
binding cache entries for the mobile node. Moreover,
this does not change anything for a home agent that
supports MIPv6 only. RFC 3775 security model will still
apply to these home agents.

> words, do you think that is a secure model?

Nope. We are not allowing a mobile node to send a BU
on behalf of another mobile node. Nobody proposed that.
Only authorized and authenticated PMAs can send proxy
BUs.

It is quite simple.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 3 Feb 2007 09:14:40 -0800

Vijay,
I think you are missing the point here. Ahmad's point, I believe, is
this: 

Allowing *any* entity to send BUs on behalf of the MN's HoA is
equivalent to relaxing the security model of RFC3775, given that RFC3775
ensures that *no other entity* except the MN can update the binding
corresponding to the HoA of the MN. 

Even if those entities are infrastructure entities, this is true. There
is no good reason an MN should trust a MAG to be legitimate. As I've
tried to explain in a couple of emails before, it is a noted threat for
network-based mobility itself, within the PMIP domain. There are a
couple of ways to mitigate that threat, but, that would either involve
the MN or specific authorization checks with an entity like AAA server.
But, allowing HoA mappings to be modified does change the security
guarantees that come with MIP6. 

Vidya 

> Sent: Saturday, February 03, 2007 8:46 AM
> To: Ahmad Muhanna
> Cc: netlmm
> Subject: Security Model (was Re: [netlmm] I-D 
> Submission:draft-sgundave-mip6-proxymip6-01.txt)
> 
> Ahmad Muhanna wrote:
> 
> RFC 3775 
> >> was being standardized was to prevent a mobile node from sending 
> >> binding updates for another mobile node's home address. We also 
> >> wanted to prevent a mobile node from creating security 
> associations 
> >> on behalf of another mobile node. That is why you see all 
> that text 
> >> in RFC 3775. There were no MAGs or PMA sending BUs on 
> behalf of the 
> >> mobile node when RFC
> >> 3775 was written.
> >>
> the mobile 
> >> node.
> > So I do not understand, Are we breaking/relaxing RFC3775 security 
> > model or not?
> 
> We are not breaking or relaxing anything. The security model 
> when you have the same home agent supporting both
> MIPv6 and PMIPv6 is slightly different from what is assumed 
> in RFC 3775. Apart from the MN, authorized (and
> authenticated) PMAs are also allowed to modify the binding 
> cache entries for the mobile node. Moreover, this does not 
> change anything for a home agent that supports MIPv6 only. 
> RFC 3775 security model will still apply to these home agents.
> 
> > One more thing, Just for one second, let us imagine that we are 
> > looking at the security model that has been adopted by 
> RFC3775 and we 
> > have the chance to change/modify it. Having in mind our 
> current PMIP 
> > requirement, would you agree to a security model which 
> allows certain 
> > MNs to send BUs on behalf of other MNs as long as they are 
> authorized 
> > to do so? In other words, do you think that is a secure model?
> 
> Nope. We are not allowing a mobile node to send a BU on 
> behalf of another mobile node. Nobody proposed that.
> Only authorized and authenticated PMAs can send proxy BUs.
> 
> It is quite simple.
> 
> Vijay
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 03 Feb 2007 09:23:29 -0800

Vijay,

Vijay Devarapalli wrote:
> Ahmad Muhanna wrote:
> 
>>> One of the main security threats we wanted to prevent when RFC 3775 
>>> wanted to prevent a mobile node from creating security associations 
>>> on behalf of another mobile node. That is why you see all that text 
>>> in RFC 3775. There were no MAGs or PMA sending BUs on behalf of the 
>>> mobile node when RFC
>>> 3775 was written.
>>>
>>> authorized PMAs/MAGs to modify the binding cache entry for the mobile 
>>> node.
>>

A mobile node compliant to 3775-6 security model assumes that it is the 
only entity that can modify its binding entry at the home agent with 
which it has a security association.  No third party can modify that 
entry and it has nothing to worry about.

If that binding entry is to be shared, authenticated PMAs (I am not sure 
about authorization here really; the claim might be that the HA is going 
to authorize modification of the binding entry, but the MN surely 
doesn't) can modify the entry without the knowledge of the MN.

That is a *huge* leap.  There is no other way to spin that.

> Only authorized and authenticated PMAs can send proxy

Please read what Ahmad wrote carefully.  He is merely asking you to 
imagine a scenario!  I would go further than him and ask this question: 
would we allow a model where the binding entry of an MN can be modified 
by any entity that the HA unilaterally authenticates and authorizes?

best,
Lakshminath

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 3 Feb 2007 09:48:45 -0800 (PST)

Hi Ahmad,

> until we nail all the details down.

Sure. As the draft moves to the next phase, we need to focus
on these finer details.

> 1. Since the P-MIP BCE flag is set, you consider this entry a non-CMIP

There is only one BCE for the mobile at the home agent. We have
extended the 3775 Conceptual BCE structure, with additional fields.
One of the fields is a Proxy-Registration flag. This flag will be
set for all Proxy registrations and will not be set for direct
registrations.

> section 11.5.4. in RFC3775.

Yes

> 2.3. This only valid when both CMIP and PMIP BCE are collocated at the

If the mobile is configured for both PMIP and CMIP registrations, a
simply policy check.

> agree.?

Yes.

>      set to 133 (not home agent for this mobile node).

Not sure why the BU should be rejected. If the mobile  transitions
into a PMIP domain after having established a CMIP session, the home
agent must accept the deregistration for the previous CMIP session.

> a CMIP BCE, from being able to de-register any of its CoA. Right?

PMIP introduces additional state into the BCE. At at any point from
the home agent perspective, there is only one type of mobility
session, CMIP or PMIP and the home agent should handle the dereg
messages for the previously created session.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 3 Feb 2007 10:13:11 -0800 (PST)

Hi Laxshminath,

Please see inline.

On Sat, 3 Feb 2007, Lakshminath Dondeti wrote:

>
> A mobile node compliant to 3775-6 security model assumes that it is the only 
> entity that can modify its binding entry at the home agent with which it has 
> a security association.  No third party can modify that entry and it has 
> nothing to worry about.
>

You have to see the security model in proper perspective. We are
focussing on these broader statements, but not in proper context.
Please note that:

- Proxy mobile agent is not a third party service. Its a core
   managed network service.

- We mandate a proper security mechanism in place for securing
   all control data exchanged between the core entities.

- In today's network, we trust many services, DNS, DHCP, LDAP,
   AAA. Indeed, when these network services are compromised, there
   is an impact on the network. Ex: When AAA server delivers some
   handover keys, a compromise of that service impacts many elements.

- We are not allowing some random node in the network to modify
   the BCE state. We permit a trusted, managed and an authorised
   network element to modify the BCE state.

- The security model either in PMIP or CMIP at the end translates
   to a service for a given mobile node. If the mobile is configured
   for a PMIP service, the operator is allowing such a security
   model and now enabling a MIP service for that mobile will not
   introduce any additional vulnerability for the mobile's service.
   Now, keeping a seperate BCE's or HoA's, when both the services
   are enabled, does not provid any greater security from the
   mobile's perspective.

Further, we cannot develop PMIP in vaccum and with out having
a relation to 3775 home agent. If the view is that, PMIP is
just a borrowed home agent code and protocol, we are just wasting
our time. It should be our goal to integrate these two services
and evolve a common architecture for integrated local and global
mobility, IMHO.

Regards
Sri

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 03 Feb 2007 17:44:49 -0800

Hi Sri,

Thanks for your notes.  Please see inline:

Sri Gundavelli wrote:
>> A mobile node compliant to 3775-6 security model assumes that it is 
>> the only entity that can modify its binding entry at the home agent 
>> with which it has a security association.  No third party can modify 
>> that entry and it has nothing to worry about.
>>
> 

What does this mean?  I am confused.  Proxy mobile agent is itself not a 
service, is it?  What do you mean by "core managed network service?"

In your view, should the protocol to be standardized by this WG be 
inline with the PS and the REQ drafts?

>   all control data exchanged between the core entities.

What is "proper?"

>   handover keys, a compromise of that service impacts many elements.

We don't blindly trust any of those services.  AAA key delivery is 
protected hop-by-hop or end-to-end and for a service in the access 
network.  If you think anything is broken in it, we can discuss that in 
the appropriate forum.

Some of us think the security model being proposed for NETLMM is broken 
and hence discussing it here.

>   network element to modify the BCE state.

If the mobile's binding entry at its home agent is allowed to be 
modified, from the mobile's perspective, we are allowing any random node 
in the *access* network modify it.

Let us also examine what you say there:  you are saying that a MAG is 
"trusted."  Trusted to do what?  What does "managed" mean and what 
assurance does it provide?  And finally, what is it "authorized" to do? 
  And authorized by which entities?

Actually I wonder how a home agent is supposed to have a security 
association with every access router in every access network into which 
the mobiles might roam into.  But, that's a different topic.

>   for a PMIP service, 

Does a mobile need to be "configured" for local mobility service?  I 
thought it is plausible to allow the mobile to move within an access 
network (or local domain) without it being aware that it is actually 
"moving" at L3 (i.e., IP address doesn't change and therefore it doesn't 
need to do any mobility signaling with the HA).

> the operator is allowing such a security

 From the mobile's point of view it's binding entry can be manipulated 
by third parties without its knowledge or authorization, no?    Why is 
that not a vulnerability?

>   are enabled, does not provid any greater security from the

Could you explain this?

> our time. 

Indeed we do need to talk about the interaction between 3775 and the 
NETLMM work.  We just differ on how best to do that.

Don't we have PS and REQ drafts in this WG?  Could you point to the REQ 
that supports your statements and we can move on?

> It should be our goal to integrate these two services

Again, this is not something that has WG consensus now, is it?

regards,
Lakshminath

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 3 Feb 2007 20:11:12 -0800 (PST)

Hi Laxshminath,

Please see inline ....

> service, is it?  What do you mean by "core managed network service?"

Proxy mobile agent is not a service ?

With all due respect, if our discussion goes in this track, dont
see any signs of convergence, and dont think any one else can follow
this thread. So, I just state the following and leave it to the
interpretation of the group, on my view points:

- 
For a hypothetical case, the mobile's MN1 and MN2 anchored at the same
home agent. MN1 is configured for CMIP Only and MN2 is configured for
both PMIP and CMIP service. This specification will not impact the
security model or the operation of MN1. So, the vulnerabilities of
PMIP security model, if any, will not extend to a mobile service that
is not configured for PMIP service.

Now, for the MN2, keeping MIP6-HoA != PMIP6-HoA, from the mobile's
perspective, will not offer any greater security. If the security
is compromised for either types of registrations, by the way of
flow redirection, the impact is the same from the mobile's perspective.
-

Now, some responses to your questions. You have questioned my general
verbal text, fair enough, may be I should have cut the text from the
draft to be specific. In any case,

- "proxy mobile agent is itself, not a service" ?
   Proxy mobile agent is a service, its performing the service of
   network signaling for a mobile node.

- What is "proper" ?
   All control messages between the home agent and the proxy mobile
   agent MUST be protected by IPSec SA, in ESP mode. Please refer
   to the Security section in the draft. And yes, there needs to be
   static or dynamic IPSec SA setup, between the home agent and the
   PMA's.

- "Trusted to do what" ?
   The home agent is required to check who in the network is allowed
   to send proxy registrations.

- "Mobile configured for local mobility service"
   For the local mobility service to work, the network needs to identify
   the mobile and it needs to offer the mobility service. There is no
   configuration required on the mobile.

Regards
Sri

> In your view, should the protocol to be standardized by this WG be inline 
> with the PS and the REQ drafts?
>
>>
> We don't blindly trust any of those services.  AAA key delivery is protected 
> hop-by-hop or end-to-end and for a service in the access network.  If you 
> think anything is broken in it, we can discuss that in the appropriate forum.
>
> Some of us think the security model being proposed for NETLMM is broken and 
> hence discussing it here.
>
>>
> If the mobile's binding entry at its home agent is allowed to be modified, 
> from the mobile's perspective, we are allowing any random node in the 
> *access* network modify it.
>
> "trusted."  Trusted to do what?  What does "managed" mean and what assurance 
> does it provide?  And finally, what is it "authorized" to do?
> Actually I wonder how a home agent is supposed to have a security association 
> with every access router in every access network into which the mobiles might 
> roam into.  But, that's a different topic.
>
>
>>
> Does a mobile need to be "configured" for local mobility service?  I thought 
> it is plausible to allow the mobile to move within an access network (or 
> local domain) without it being aware that it is actually "moving" at L3 
> (i.e., IP address doesn't change and therefore it doesn't need to do any 
> mobility signaling with the HA).
>
> From the mobile's point of view it's binding entry can be manipulated by 
> third parties without its knowledge or authorization, no?    Why is that not 
> a vulnerability?
>
> Indeed we do need to talk about the interaction between 3775 and the NETLMM 
> work.  We just differ on how best to do that.
>
> Don't we have PS and REQ drafts in this WG?  Could you point to the REQ that 
> supports your statements and we can move on?
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 03 Feb 2007 22:10:45 -0800

Sri Gundavelli wrote:
>> What does this mean?  I am confused.  Proxy mobile agent is itself not 
>> a service, is it?  What do you mean by "core managed network service?"
>>
> 
> see any signs of convergence, 

Huh!

Sri, I am not sure what you are talking about.  Why do you think the 
discussion is off-track.  For us to have a discussion, we all need to 
understand each other's terminology.  We could use terminology we agreed 
to or take the pains to explain clearly as to what these things mean.

Let's look back: you started out saying "You have to see the security 
model in proper perspective. We are
focusing on these broader statements, but not in proper context.
Please note that:

- Proxy mobile agent is not a third party service. Its a core
   managed network service. "

That is confusing to me.  So I asked you for clarification.  First, 
Proxy mobile agent is a "third party."  Next, it cannot be a service. 
It may be able to provide a service.  Now that I have explained what I 
am confused about, perhaps you might reword your first statement.

Next, if you are saying "proxy mobility" is a core managed network 
service, you need to define what "core" is?

cheers,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 04 Feb 2007 00:10:57 -0800

> flow redirection, the impact is the same from the mobile's perspective.

How are payload packets protected when MIP6-HoA == PMIP6-HoA?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 4 Feb 2007 23:44:26 -0600

Hi Vijay,

Please see comment inline.

Regards,
Ahmad

> Sent: Saturday, February 03, 2007 10:46 AM
> Subject: Security Model (was Re: [netlmm] I-D Submission: 
> draft-sgundave-mip6-proxymip6-01.txt)
> 
> Ahmad Muhanna wrote:
> 

[Ahmad]
Unfortunately you missed the whole point. To me and I am sure others,
the deviation of PMIP security model from RFC3775 is obvious. Hope that
the contribution of other members on this WG ML will explain this
deviation better.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 4 Feb 2007 23:52:31 -0600

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Saturday, February 03, 2007 11:15 AM
> To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10)
> Cc: netlmm
> Subject: RE: Security Model (was Re: [netlmm] I-D 
> Allowing *any* entity to send BUs on behalf of the MN's HoA 
> is equivalent to relaxing the security model of RFC3775, 
> given that RFC3775 ensures that *no other entity* except the 
> MN can update the binding corresponding to the HoA of the MN.

[Ahmad]
Yes. I Agree.

> 
> Even if those entities are infrastructure entities, this is 
> true. There is no good reason an MN should trust a MAG to be 
> legitimate. As I've tried to explain in a couple of emails 
> before, it is a noted threat for network-based mobility 
> itself, within the PMIP domain. There are a couple of ways to 
> mitigate that threat, but, that would either involve the MN 
> or specific authorization checks with an entity like AAA server.
> But, allowing HoA mappings to be modified does change the 
> security guarantees that come with MIP6. 
> 
> Vidya 
> 
> > MIPv6 and PMIPv6 is slightly different from what is assumed in RFC 
> > 3775. Apart from the MN, authorized (and
> > authenticated) PMAs are also allowed to modify the binding cache 
> > entries for the mobile node. Moreover, this does not change 
> anything 
> > for a home agent that supports MIPv6 only.
> > Nope. We are not allowing a mobile node to send a BU on behalf of 
> > another mobile node. Nobody proposed that.

---

From: [email-masked]
Date: Mon, 05 Feb 2007 09:36:41 +0100

>> MN can update the binding corresponding to the HoA of the MN.
Sorry, I don't think RFC3775 states such a thing:
"*no other entity* except the MN..."

My understanding is that RFC3775 define mechanisms to legitimate MN-HA 
Binding Updates in regard of Malicious Mobile and Man-in-the-middle 
threats. It does not forbid a component to send legitimate MN-HA BU's 
and does not state it has to be the physical MN. As long as a component 
satisfies authentication and authorization that applies for a MN (not 
excluding out-of-band and whatever mechanisms), this component complies 
with RFC3775 and can send legitimate MN-HA BU's. The protocol is logical 
and cannot (shall not) make the difference between the implementation at 
MN level and a proxy implementation.

I think RFC3775 has been done in that way, but i might be wrong.

Why don't we take an advice from RFC3775's authors to confirm?
Bruno.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 11:24:31 +0100

Ahmad Muhanna wrote:
> Regards, Ahmad
>> -----Original Message----- From: Vijay Devarapalli
>> [mailto:[email-masked]] Sent: Saturday, February
>> 03, 2007 10:46 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Gerardo
>> Giaretta; netlmm Subject: Security Model (was Re: [netlmm] I-D
>> Submission: draft-sgundave-mip6-proxymip6-01.txt)
>> 
>> Ahmad Muhanna wrote:
>> 
>>>> was being standardized was to prevent a mobile node from
>>>> sending binding updates for another mobile node's home address.
>>>> We also wanted to prevent a mobile node from creating security
>>>> 
>> associations
>>>> mobile node when RFC 3775 was written.
>>>> 
>> We are not breaking or relaxing anything. The security model when
>> you have the same home agent supporting both MIPv6 and PMIPv6 is
>> slightly different from what is assumed in RFC 3775. Apart from the
>> MN, authorized (and authenticated) PMAs are also allowed to modify
>> the binding cache entries for the mobile node. Moreover, this does
>> not change anything for a home agent that supports MIPv6 only. RFC
>> 3775 security model will still apply to these home agents.
>> 
>> another mobile node. Nobody proposed that. Only authorized and
>> authenticated PMAs can send proxy BUs.
>> 
>> It is quite simple.
> 
> [Ahmad] Unfortunately you missed the whole point. To me and I am sure
> others, the deviation of PMIP security model from RFC3775 is obvious.
> Hope that the contribution of other members on this WG ML will
> explain this deviation better.

I agree with Ahmad on this topic.  It has been made obvious several
times in the WG that PMIPv6 (draft-sgundave) is a significant departure
from the 3775/6 security model.  An AR can hardly prove secure when
updating the HA about a third IP address (MN's), without further
developping new mechanisms for security.

Vijay and Sri seem to take the ARs as granted for sending BUs on behalf
of the MN.  However, I would like to see _how_ an AR was authorized by
the MN to do that.  Is this happening through PANA process?  Through IKE?

It is not enough to assume that MN and all AR/LMAs in a domain are
trusting each other because under same operator.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Feb 2007 10:03:03 -0800 (PST)

Hi Lakshminath,

> How are payload packets protected when MIP6-HoA == PMIP6-HoA?

Sorry for the late reply.

Its upto the policy, IPSec security can be applied on the
HA-PMA tunnel for the data traffic. We have covered this in
the Proxy Mobile IP Security section of the document.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Feb 2007 10:04:17 -0800 (PST)

Vidya,

>> MN can update the binding corresponding to the HoA of the MN.

We are looking at this in one statement in a very purestic view.
I do not see how this translates a real security threat. In any
case, if the goal is that no other entity other than the mobile
should be able to "update the MIP6 BCE", I've the following
option and that should satisfy your requirement.

1. For the scenario where PMIP6-HoA == MIP6-HOA, when the home
agent receives a Proxy Binding Update from a proxy mobile agent,
if there is an active BCE (Direct Registration) for that mobile,
the home agent will not delete the BCE, till it receives a proper
deregistration message from the mobile.

2. In other words, we will keep the 3775 BCE sacred. We will not
allow a proxy mobile agent to delete that BCE. As per 3775, when
attached to the access link supported proxy mobile agent, the mobile
should detect the home network and send a deregistration message.
The home agent after accepting the Dereg will remove the BCE for
the mobile. After that point, we will allow the creation of the
BCE in the proxy mode. We just switch the order.

3. Now, MIP6-HOA happens to be the same as PMIP6-HoA. This is
the address the mobile is configured with. So, there is no
relation.

I'm not convinced with this entire argument of not allowing any
other node to modify a BCE. But, too move forward ....

Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 19:20:32 +0100

Sri Gundavelli wrote:
> 
> Vidya,
> 
>> 
>>> -----Original Message----- From: Narayanan, Vidya
>>> [mailto:[email-masked]] Sent: Saturday, February 03, 2007
>>> 11:15 AM To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10) Cc:
>>> netlmm Subject: RE: Security Model (was Re: [netlmm] I-D 
>>> Vijay, I think you are missing the point here. Ahmad's point, I
>>> believe, is this:
>>> 
>>> equivalent to relaxing the security model of RFC3775, given that
>>> RFC3775 ensures that *no other entity* except the MN can update
>>> the binding corresponding to the HoA of the MN.
>> 
> 
> We are looking at this in one statement in a very purestic view. I do
> not see how this translates a real security threat.

Threat: AR1 sends P-BU on behalf of a MN for which the AR1 isn't
authorized to send P-BUs.

Why don't you think this is real?  There were many real attacks with 
rogue APs.

> In any case, if the goal is that no other entity other than the
> mobile should be able to "update the MIP6 BCE", I've the following 
> 1. For the scenario where PMIP6-HoA == MIP6-HOA, when the home agent
> receives a Proxy Binding Update from a proxy mobile agent, if there
> is an active BCE (Direct Registration) for that mobile, the home
> agent will not delete the BCE, till it receives a proper 

How long is that 'till'?  10s?  More, less?  How can this be 
implemented?  How can this affect fast handovers?

> should detect the home network and send a deregistration message. The
> home agent after accepting the Dereg will remove the BCE for the
> mobile. After that point, we will allow the creation of the BCE in
> the proxy mode. We just switch the order.

How does one make sure that _first_ the 3775-BU-lifetime0 arrives to the 
HA and only then the P-MIPv6-BU arrives to the HA?

How can one make sure the order of arrival of these two BUs?

> 3. Now, MIP6-HOA happens to be the same as PMIP6-HoA. This is the
> address the mobile is configured with. So, there is no relation.
> 
> 
> I'm not convinced with this entire argument of not allowing any other
> node to modify a BCE. But, too move forward ....

Not myself either.  Somehow authorization should happen reversely 
compared to regular AAA-ish way.  MN must authorize the AR somehow for 
that P-BU operation.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 10:25:27 -0800

Lakshminath Dondeti wrote:

>>>> authorized PMAs/MAGs to modify the binding cache entry for the 
>>>> mobile node.
>>>

We are not talking about RFC 3775-only mobile nodes/
home agents here. We are talking about a mobile node
that is transitioning between using CMIP and PMIP.
This ofcourse implies that the MN and all authorized
PMA can modify the binding cache entry for the MN.

> That is a *huge* leap.  There is no other way to spin that.

Nobody trying to spin anything here.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 10:35:20 -0800

> the contribution of other members on this WG ML will explain this

Ok. Lets step back a bit. Lets see what I missed. There
are three types of scenarios

1. RFC 3775-only mobile nodes and the home agents.
Here the security model assume RFC 3775 of course applies.
No changes. The home agent will not allow any entity other
than the mobile node to modify the binding cache entry. We
(NETLMM WG) are not going to update/modify this security
model.

2. PMIPv6 only mobile nodes and home agents
Here we have a new security model. The one that is described
in draft-sgundave-mip6-proxymip6-01 and in the NETLMM problem
statement and requirements draft. The home agent allows only
authorized and authenticated PMAs (MAGs) are allowed to
change the binding cache entry for the mobile node.

3. A home agent that supports both PMIPv6 and CMIPv6 with
the mobile node transitioning between the two.
This is a new scenario. In the security model for this, the
home agent allows both the mobile node *and* authorized PMAs
to modify the binding cache entry for the mobile node.

If you want to treat them as separate scenarios and therefore
separate security models, its fine with me.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 10:38:40 -0800

> the MN to do that.  Is this happening through PANA process?  Through IKE?

*Nobody* ever suggested that a PMA that is not
authenticated and authorized should send a proxy BU
to the HA. If the HA receives a BU from a PMA that
is not authenticated and authorized, the Proxy BU
is dropped.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 10:39:51 -0800

> How are payload packets protected when MIP6-HoA == PMIP6-HoA?

It might be better if you explain where you see a
problem. This is too cryptic. You want to see the
SPD entries to protect the payload packets?

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Feb 2007 10:40:05 -0800 (PST)

On Mon, 5 Feb 2007, Alexandru Petrescu wrote:

>
> Why don't you think this is real?  There were many real attacks with rogue 
> APs.
>

Alex:

Can you answer this ?

- We are not extending the PMIP security vulernerabilties, if any, 
to native MIP6. If the home agent is hosting MIP6 nodes and PMIP6
nodes, do you agree what ever the PMIP draft proposes has no implication
on the MIP6 service or the security for the MIP6 nodes ? Its contained
to PMIP nodes.

- Now, for the PMIP nodes, when MIP6-HoA == PMIP6-HoA, if one of the
security model is weaker and make affect the HoA flows, how does it
matter, if the same weaker security extends to the mobile when operating
in the other mode ??

- We are containing the security model to only nodes configured for
PMIP service ?

>>  mobile should be able to "update the MIP6 BCE", I've the following option
>>  and that should satisfy your requirement.
>>
>>
>>  agent will not delete the BCE, till it receives a proper deregistration
>>  message from the mobile.
>
> How long is that 'till'?  10s?  More, less?  How can this be implemented? 
> How can this affect fast handovers?
>

Why will it take 10sec ? Does dereg happen after 10secs after the home
is detected. This is make-before-break scenario. The tunnel is setup,
from the PMA the data path is setup and for the home agent, it can
wait for the dereg before it receives the BCE.

>>  2. In other words, we will keep the 3775 BCE sacred. We will not allow a
>>  proxy mobile agent to delete that BCE. As per 3775, when attached to the
>>  access link supported proxy mobile agent, the mobile should detect the
>>  home network and send a deregistration message. The
> How does one make sure that _first_ the 3775-BU-lifetime0 arrives to the HA 
> and only then the P-MIPv6-BU arrives to the HA?
>

Does not matter. The PMIP BCE state can be created and put inactive mode,
till the dereg happens.

> Not myself either.  Somehow authorization should happen reversely compared to 
> regular AAA-ish way.  MN must authorize the AR somehow for that P-BU 
> operation.
>
> Alex
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 19:45:18 +0100

Vijay Devarapalli wrote:
>>  times in the WG that PMIPv6 (draft-sgundave) is a significant 
>> departure from the 3775/6 security model.  An AR can hardly prove 
>> secure when updating the HA about a third IP address (MN's), 
>> without further developping new mechanisms for security.
>> 
>> Vijay and Sri seem to take the ARs as granted for sending BUs on 
>> behalf of the MN.  However, I would like to see _how_ an AR was 
>> authorized by the MN to do that.  Is this happening through PANA 
>> process?  Through IKE?
> 
> *Nobody* ever suggested that a PMA that is not authenticated and 
> authorized should send a proxy BU to the HA. If the HA receives a BU
>  from a PMA that is not authenticated and authorized, the Proxy BU is
>  dropped.

You (sorry for pointing, no mean intention :-) keep saying that a PMA
is authenticated and authorized.  By whom?  By HA?  Or by MN?  How can
MN indicate to PMA that that PMA from now on can do 'proxy' operations
on its behalf?

AR (PMA) authenticated and authorized by HA - yes, I agree, a small
domain, feasible.  One would describe how the keys are distributed, etc.
It happens in all routing domains today.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Feb 2007 12:48:56 -0600

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 2:37 AM
> Cc: Narayanan, Vidya; Vijay Devarapalli; netlmm
> Subject: Re: Security Model (was Re: [netlmm] I-D 
> >> RFC3775 ensures that *no other entity* except the MN can 
> update the 
> >> binding corresponding to the HoA of the MN.
> >>     
> >
> > [Ahmad]
> > Yes. I Agree.
> >
> >   
> My understanding is that RFC3775 define mechanisms to 
> legitimate MN-HA Binding Updates in regard of Malicious 
> Mobile and Man-in-the-middle threats. It does not forbid a 
> component to send legitimate MN-HA BU's and does not state it 
> has to be the physical MN. As long as a component satisfies 
> authentication and authorization that applies for a MN (not 
> excluding out-of-band and whatever mechanisms), this 
> component complies with RFC3775 and can send legitimate MN-HA 
> BU's. The protocol is logical and cannot (shall not) make the 
> difference between the implementation at MN level and a proxy 
> implementation.
> 

[Ahmad]
RFC3775 does not need to state that explicitly.
Let us not forget that RFC3775 introduce a MIPv6 protocol to control the
relationship between two entities; The Mobile Node and Home Agent.
Mobile Node, as per RFC3775 which has a specific SA with its HA, is not
allowed to send a BU on behalf of any other Mobile Node which most
probably belong to the same HA domain (regardless with the authorization
of the other MN or not). Do you think that is not enough?

RFC3775 section 5.1: excerpt
"
   In order to protect messages exchanged between the mobile node and
   the home agent with IPsec, appropriate security policy database
   entries must be created.  A mobile node must be prevented from using
   its security association to send a Binding Update on behalf of
   another mobile node using the same home agent.  This MUST be achieved
   by having the home agent check that the given home address has been
   used with the right security association.  .........."

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 10:54:09 -0800

Alexandru Petrescu wrote:
>>> secure when updating the HA about a third IP address (MN's), without 
>>> further developping new mechanisms for security.
>>>

The solution for this is very much deployment specific.
That is why we haven't described a solution for this.

I can describe on possible solution. For authentication
the easiest mechanism would be have the PMA and the HA
to run IKEv2 to authenticate each other. They can even
go ahead and setup a fat tunnel that can be used to
carry all PMIPv6 related signaling messages and all
data traffic for the mobile nodes.

Authorization is very deployment specific. Lets assume
there is a AAA infrastructure. AAA home server knows
which PMA the mobile node is currently attached to,
assuming there was some kind of access authentication.
The HA before processing the BU just needs to check with
the AAA home server if the PMA is authorized to send
BUs for the mobile node.

Another option is for the HA to be configured with all
authorized PMAs for a particular domain.

I guess we will get to this later.

But if the PMA is not authenticated and authorized, the
home agent will ofcourse drop the proxy BU. I think we
all agree on that.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 10:56:03 -0800

Hi Ahmad

>    used with the right security association.  .........."

The above text was written to make sure a misbehaving
mobile node does not/cannot send BU's for another mobile
node. There was no concept of PMA when this text was
written.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Feb 2007 13:10:48 -0600

> Sent: Monday, February 05, 2007 12:54 PM
> To: Alexandru Petrescu
> Cc: Muhanna, Ahmad (RICH1:2H10); netlmm
> Subject: Re: Security Model (was Re: [netlmm] I-D Submission: 
> I can describe on possible solution. For authentication the 
> easiest mechanism would be have the PMA and the HA to run 
> IKEv2 to authenticate each other. They can even go ahead and 
> setup a fat tunnel that can be used to carry all PMIPv6 
> related signaling messages and all data traffic for the mobile nodes.

[Ahmad]
I am not sure if this solution addresses the problem.

> 
> Authorization is very deployment specific. Lets assume there 
> is a AAA infrastructure. AAA home server knows which PMA the 
> mobile node is currently attached to, assuming there was some 
> kind of access authentication.
> The HA before processing the BU just needs to check with the 
> AAA home server if the PMA is authorized to send BUs for the 
> mobile node.

[Ahmad]
Yes, as you just pointed out, for the PMIP security model to work and be
as secure as Client Mobile IP, Home Agent needs to know of the current
location of the Mobile Node via a trusted entity other than PMA, e.g.
AAA. One thing I disagree with is to label this as an implementation
specific. I believe this is a security threat that is introduce by
allowing MAG/PMA to send BU on behalf of other MN to inform the HA with
the current location of the MN. If we guarantee that every time the MN
moves from a MAG/PMA to another, HA will get confirmation from a trusted
entity other than MAG/PMA with the current MN location, then that takes
care of the problem.

BTW: this is only one option but at least I see that we are finally
converging on this issue.

> But if the PMA is not authenticated and authorized, the home 
> agent will ofcourse drop the proxy BU. I think we all agree on that.
> 
> Vijay
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 20:19:11 +0100

Sri Gundavelli wrote:
>> Why don't you think this is real?  There were many real attacks
>> with rogue APs.
>> 
> 
> Alex:
> 
> Can you answer this ?
> 
> - We are not extending the PMIP security vulernerabilties, if any, to
>  native MIP6. If the home agent is hosting MIP6 nodes and PMIP6 
> nodes, do you agree what ever the PMIP draft proposes has no
> implication on the MIP6 service or the security for the MIP6 nodes ?
> Its contained to PMIP nodes.

Yes, I agree an unsecure PMIPv6 doesn't break secure MIPv6, provided
that at least that BCE access can be sequenced securely.

Do you agree that because we use secure MIPv6 it doesn't mean P-MIPv6
reuses its security features?  And that new work is needed to render
P-MIPv6 secure?

> matter, if the same weaker security extends to the mobile when
> operating in the other mode ??

Sorry, I don't get it.  Do you mean that P-MIPv6 being insecure means
MIPv6 is insecure too?

> - We are containing the security model to only nodes configured for 

I agree the P-MIP6 security model affects only P-MIPv6 entities, and
these are ARs and LMAs, no MNs.  There's no means to 'configure' a MN to
run or not run P-MIPv6.  At least not currently.  And not in the
requirements either.

I agree that a MN prefers to not attach to a network that may be insecure.

I agree though that a MN and a network under same operator can assume
mutual trust based only on eg SIM credentials.  But that stays closed.

>>> mobile should be able to "update the MIP6 BCE", I've the
>>> following option and that should satisfy your requirement.
>>> 
>>> 
> Why will it take 10sec ? Does dereg happen after 10secs after the
> home is detected. This is make-before-break scenario. The tunnel is
> setup, from the PMA the data path is setup and for the home agent, it
> can wait for the dereg before it receives the BCE.

Sending two packets one after the other and arriving 10s one after the
other is something that has been seen on GPRS networks.

>>> attached to the access link supported proxy mobile agent, the
>>> mobile should detect the home network and send a deregistration
>>> message. The home agent after accepting the Dereg will remove the
>>> BCE for the mobile. After that point, we will allow the creation
>>> of the BCE in the proxy mode. We just switch the order.
>> 
>> How does one make sure that _first_ the 3775-BU-lifetime0 arrives
>> to the HA and only then the P-MIPv6-BU arrives to the HA?
>> 
> 
> 
> Does not matter. The PMIP BCE state can be created and put inactive
> mode, till the dereg happens.

It works if deletion can be created similarly: create a 'deleting' entry
and activate it only when the two messages are arrived.  How long to
wait for the two messages to confirm an action?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Feb 2007 11:33:01 -0800

> I am not sure if this solution addresses the problem.

I agree that IKEv2 between the PMA and the HA does not
address the authorization issue. It is used just for
the PMA and the HA to authenticate each other.

> converging on this issue.

Great! Now I understand the security issue you were
bringing up. You wanted the HA to also to check if
the mobile node is currently attached to the PMA
(in addition to checking if the PMA is authorized
to send proxy BUs) before processing the proxy BU.
We can definitely point this out in the security
considerations section.

However whether this check if actually enforced on a
particular HA might be specific to the deployment.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 20:35:33 +0100

Vijay Devarapalli wrote:
>>>> I agree with Ahmad on this topic.  It has been made obvious 
>>>> several times in the WG that PMIPv6 (draft-sgundave) is a 
>>>> significant departure from the 3775/6 security model.  An AR 
>>>> can hardly prove secure when updating the HA about a third IP 
>>>> address (MN's), without further developping new mechanisms for
>>>>  security.
>>>> 
>>>> Vijay and Sri seem to take the ARs as granted for sending BUs 
>>>> on behalf of the MN.  However, I would like to see _how_ an AR
>>>>  was authorized by the MN to do that.  Is this happening
>>>> through PANA process?  Through IKE?
>>> 
>>>  authorized should send a proxy BU to the HA. If the HA receives
>>> a BU from a PMA that is not authenticated and authorized, the
>>> Proxy BU is dropped.
>> 
>> You (sorry for pointing, no mean intention :-) keep saying that a 
>> PMA is authenticated and authorized.  By whom?  By HA?  Or by MN? 
>> How can MN indicate to PMA that that PMA from now on can do 'proxy'
>>  operations on its behalf?
>> 
>>  domain, feasible.  One would describe how the keys are 
>> distributed, etc. It happens in all routing domains today.
> 
> The solution for this is very much deployment specific. That is why 
> we haven't described a solution for this.

What is the solution for MN to authorize an AR to do a P-BU?

Remark MIPv6 is secure overall, no need to assume existence of a
deployment-specific unknown.

> I can describe on possible solution. For authentication the easiest 
> mechanism would be have the PMA and the HA to run IKEv2 to 
> authenticate each other.

I agree with this.

> They can even go ahead and setup a fat tunnel that can be used to 
> carry all PMIPv6 related signaling messages and all data traffic for 
> the mobile nodes.

They could.  The security threat in this case is MN that takes advantage
of that fat tunnel without being authorized to.

And the dismissal of DHAAD-like load-balancing: to _which_ HA should the
fat tunnel be set up?  How can MN let know PMA that it prefers a certain
HA and thus PMA execute that decision on its behalf ("proxy").

> Authorization is very deployment specific. Lets assume there is a AAA
>  infrastructure. AAA home server knows which PMA the mobile node is 
> currently attached to, assuming there was some kind of access 
> authentication. The HA before processing the BU just needs to check 
> with the AAA home server if the PMA is authorized to send BUs for the
>  mobile node.

HA to check with AAA server whether PMA is authorized is new.

Remark that until now we talked MN-HA security ok (3775/6) then we
talked MN-PMA-HA security (unknown yet) and now we talk
MN-PMA-HA-AAAserver security (even bigger unknown).

The more we talk this the more are entities.  Securing a 4-entity
protocol is not easy.  It would have been much easier if we relied on a
MN-AR mechanism for this security, don't you think?

> Another option is for the HA to be configured with all authorized 
> PMAs for a particular domain.

I agreed with this too.  Remark this can not be done with existing AAA.
  It must be done as you say with a pre-configuration stuff.

> But if the PMA is not authenticated and authorized, the home agent 
> will ofcourse drop the proxy BU. I think we all agree on that.

Of course, I agree.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Feb 2007 13:55:21 -0600

> the easiest 
> >> mechanism would be have the PMA and the HA to run
> >> IKEv2 to authenticate each other. They can even go ahead 
> and setup a 
> >> fat tunnel that can be used to carry all PMIPv6 related signaling 
> >> messages and all data traffic for the mobile nodes.
> > 
> > [Ahmad]
> address the authorization issue. It is used just for the PMA 
> and the HA to authenticate each other.
> 
> there is a AAA 
> >> authentication.
> the AAA home 
> >> server if the PMA is authorized to send BUs for the mobile node.
> > 
> > [Ahmad]
> > Yes, as you just pointed out, for the PMIP security model 
> to work and 
> > be as secure as Client Mobile IP, Home Agent needs to know of the 
> > current location of the Mobile Node via a trusted entity 
> other than PMA, e.g.
> > allowing MAG/PMA to send BU on behalf of other MN to inform the HA 
> > with the current location of the MN. If we guarantee that 
> every time 
> > the MN moves from a MAG/PMA to another, HA will get 
> confirmation from 
> > a trusted entity other than MAG/PMA with the current MN 
> location, then 
> > that takes care of the problem.
> > 
> Great! Now I understand the security issue you were bringing 
> up. You wanted the HA to also to check if the mobile node is 
> currently attached to the PMA (in addition to checking if the 
> PMA is authorized to send proxy BUs) before processing the proxy BU.

[Ahmad]
Exactly. A pointer to a couple of options for addressing the security
threat would be great too.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 21:00:43 +0100

> threat would be great too.

I'm not sure this fits the bill.

I don't think adding simple text "HA must check if the MN is currently 
attached to the PMA before processing the BU" is enough.  How can it 
check?  Remark the whole P-MIPv6 protocol security relies on this.

I think the base protocol should stay independent of requesting HA to 
check the AAA Server.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Feb 2007 12:02:19 -0800 (PST)

Hi Ahmad,

> threat would be great too.

Ok.

The tunneled dereg message from the client is another indicator
that the mobile is attached to the serving proxy mobile agent.
We should add all these to the security sectiomn.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Feb 2007 14:07:36 -0600

Hi Sri,

Regards,
Ahmad

> Sent: Monday, February 05, 2007 2:02 PM
> Cc: Vijay Devarapalli; netlmm
> Subject: RE: Security Model (was Re: [netlmm] I-D Submission: 
> The tunneled dereg message from the client is another 
> indicator that the mobile is attached to the serving proxy 
> mobile agent.

[Ahmad]
The threat in this case is applicable to all scenarios including a MN
which has only PMIP. In that case, there is no CMIP to satisfy this
requirement. However, this could be made to work as an option as long as
the deregistration message is coming over the IPSec tunnel between the
MN and its HA and not over the PMIP tunnel. In other words, HA needs to
be sure that the deregistration is coming from the MN itself.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Feb 2007 12:11:39 -0800 (PST)

Hi Ahmad,

In other words, HA needs to
> be sure that the deregistration is coming from the MN itself.

The dereg message will be protected by the MN-HA IPSec SA. So, we
should probably be ok here. I think, we can cover few cases and
add proper text.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Feb 2007 14:14:00 -0600

> Sent: Monday, February 05, 2007 12:56 PM
> Cc: [email-masked]; Narayanan, Vidya; netlmm
> > Let us not forget that RFC3775 introduce a MIPv6 protocol 
> to control 
> > the relationship between two entities; The Mobile Node and 
> Home Agent.
> > Mobile Node, as per RFC3775 which has a specific SA with its HA, is 
> > not allowed to send a BU on behalf of any other Mobile Node 
> which most 
> > probably belong to the same HA domain (regardless with the 
> > authorization of the other MN or not). Do you think that is 
> not enough?
> > 
> The above text was written to make sure a misbehaving mobile 
> node does not/cannot send BU's for another mobile node. There 
> was no concept of PMA when this text was written.

[Ahmad]
Just to close on this discussion, no one claims that MAG/PMA does not
also misbehave due to many different reasons, e.g. being compromised. In
that sense I see the same requirement on the MN is applicable on the
MAG/PMA.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Feb 2007 14:27:13 -0600

Hi Alex,

Regards,
Ahmad

> bringing up. You 
> >> wanted the HA to also to check if the mobile node is currently 
> >> attached to the PMA (in addition to checking if the PMA is 
> authorized 
> >> We can definitely point this out in the security considerations 
> >> section.
> >>
> >> However whether this check if actually enforced on a particular HA 
> >> might be specific to the deployment.
> > 
> > [Ahmad]
> I don't think adding simple text "HA must check if the MN is 
> currently attached to the PMA before processing the BU" is 
> enough.  How can it check?  Remark the whole P-MIPv6 protocol 
> security relies on this.

[Ahmad]
I was replying back to confirm the idea but not the exact wording. My
opinion here is that this security threat needs to be clearly documented
under the security section. A couple or whatever number of proposed
solutions need to be captured for addressing this threat. IMO, each
deployment or SDO can mandate whatever proper to their network
deployment. I am not sure if we can find an easy/acceptable universal
solution for this issue. 

> 
> I think the base protocol should stay independent of 
> requesting HA to check the AAA Server.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 21:36:22 +0100

Ahmad Muhanna wrote:
>>>>>> currently attached to, assuming there was some kind of
>>>>>> access authentication. The HA before processing the BU just
>>>>>> needs to check with
>>>> the AAA home
>>>>> [Ahmad] Yes, as you just pointed out, for the PMIP security
>>>>> model
>>>> to work and
>>>>> be as secure as Client Mobile IP, Home Agent needs to know of
>>>>> the current location of the Mobile Node via a trusted entity
>>>> other than PMA, e.g.
>>>> to send proxy BUs) before processing the proxy BU. We can
>>>> definitely point this out in the security considerations 
>>>> section.
>>>> 
>>>> However whether this check if actually enforced on a particular
>>>> HA might be specific to the deployment.
>>> [Ahmad] Exactly. A pointer to a couple of options for addressing
>>> 
>> the security
>> currently attached to the PMA before processing the BU" is enough.
>> How can it check?  Remark the whole P-MIPv6 protocol security
>> relies on this.
> 
> [Ahmad] I was replying back to confirm the idea but not the exact
> wording. My opinion here is that this security threat needs to be
> clearly documented under the security section. A couple or whatever
> number of proposed solutions need to be captured for addressing this
> threat. IMO, each deployment or SDO can mandate whatever proper to
> their network deployment. I am not sure if we can find an
> easy/acceptable universal solution for this issue.

I agree there should be a security section that documents at least those 
fine grain threats that aren't dealt with by the protocol.

But, I wouldn't like to see a security section that recommends the use 
of AAA as a panacea to all threats.

MIP6 is secure in itself, relying on IPsec, not on AAA.  It has some 
weaknesses but doesn't recommend AAA to deal with these weaknesses. 
They're simply imposible to deal with.

If P-MIPv6 is to be secure in itself it should rely on IPsec too.  And 
should not rely on new three-party or four-party communications security 
exchanges, inherently difficult to secure.

How can AR be authorized to HA about its relationship with MN?  Maybe 
with SeND?

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 5 Feb 2007 22:41:59 +0200 (EET)

> How can AR be authorized to HA about its relationship with MN?  Maybe

=> IMHO, the SeND track deserves special attention in such scenario.

Wassim H.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 6 Feb 2007 11:14:22 +0100

On Monday 05 February 2007 20:55, Ahmad Muhanna wrote:
> >
> > Great! Now I understand the security issue you
> > were bringing up. You wanted the HA to also to
> > check if the mobile node is currently attached to
> > the PMA (in addition to checking if the PMA is
> > authorized to send proxy BUs) before processing
> > the proxy BU. We can definitely point this out in
> > the security considerations section.
> >
> > However whether this check if actually enforced on
> > a particular HA might be specific to the
> > deployment.
>
> [Ahmad]
> Exactly. A pointer to a couple of options for
> addressing the security threat would be great too.

I think the MN-AR interface (or MN-PMA interface) is 
the place to do that.

The current doc defines a mechanism based on SEND. We 
can certainly add AAA-based mechanism to the doc.

--julien