Subject: Re: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 1

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Jan 2008 13:15:14 -0800 (PST)

Hi Sri,
  IMHO HNP, in view of multihoming support could be the stable identifier. Yes the first PBU will not contain HNP but all others will, right?

Regards,

Behcet

----- Original Message ----
From: Sri Gundavelli <[email-masked]>
To: Alper Yegin <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Thursday, January 3, 2008 9:38:45 AM
Subject: RE: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 1

On Thu, 3 Jan 2008, Alper Yegin wrote:

>>>> The actual
>>>> mechanism by which the local mobility anchor verifies if a
 specific
>>>> mobile access gateway is authorized to send Proxy Binding Updates
 on
>>>> behalf of a mobile node is outside the scope of this document.
  One
>>>> possible way this could be achieved is by sending a query to the
>>>> policy store, such as AAA.
>>>
>>> This is problematic as the authorization check is a key feature of
 the
>>> proxy functionality, and you cannot leave it unspecified. However,
>>> specifying
>>> a mandatory base requirement appears easy. Here's an attempt that
>> continues
>>> from where my previous comment ended:
>>>
>>> The local mobility anchor MUST be locally configurable to authorize
 such
>>> specific combinations. Additional mechanisms such as a policy store
 or
>> AAA
>>> may be employed, but these are outside the scope of this
 specification.
>>>
>>
>> Sure.
>
> Local configuration would not suffice for authorization of MAG to
 send a PBU
> for a given MN as MN's current attachment to the network cannot be
 stored in
> a local configuration. "Query to the AAA store" was meant to capture
 that,
> in an informative fashion. I personally prefer being informative
 (vague?)
> rather than missing that point. Someone may have a better wording to
 improve
> this tradeoff though.

There are two things here. The MAG authorization and the issue of 
network having to ensure a given MN is attached to a given MAG.
The later is in the case of a untrusted or a compromized MAG sending
a false PBU. Local configuration should be sufficient for the
authorization. For the later, for eliminating the threat, the network
can query the AAA to ensure the MN is attached a given access network.
This is captured in the security section, as this is really a residual
threat.

>>>>    Typically, the MN-Identifier is the key for locating a Binding
 Cache
>>>>    entry.  However, when supporting multihoming there MAY be more
 than
>>>>    one Binding Cache entry with the same MN-Identifier and in such
>> cases
>>>>    the entry can be located using any of the following key
>> combinations:
>>>>
>>>>    o  MN-Identifier, MN-HNP
>>>>
>>>>    o  MN-Identifier, Proxy-CoA
>>>>
>>>>    o  MN-Identifier, MN-Interface-Identifier
>>>>
>>>>    o  MN-Identifier, Access Technology Type (When MN-Interface-
>>>>       Identifier is not present)
>>>>
>>> This seems somewhat ad hoc. Is there a better way to define how
 proxy
>>> BCEs are looked up? E.g., MN-ID + ATT + MNIID.
>>>
>>
>> MN-IID and HNP are optional, as the MAG may not predictably learn
>> them in all cases. The Proxy CoA address may be different after a
>> handoff. That leaves few combinations for the BCE lookup.
>> But, these are indeed unique for a BCE lookup. We can be silent and
>> leave this to implementations as well.
>
> We need to nail this down. We cannot be having a spec whose security
 relies
> on undefined end-point identifier. It is one thing that we don't know
 what
> to put in MN-id, but it is another thing that we don't know whether
 we use
> MN-id or some combination of that with other IDs.
>

MN-Id is the stable identifier. How ever, there could be multiple
sessions for a given MN and the combination of IID or HNP will
act as the selectors for identifying the specific mobility session.

> Given that some of the identifiers may be NULL depending on the
 scenario,
> could this be what we need:
>
> MN-ID + MNIID + HNP
>
> Regards, and happy new year.
>

Happy New Year !

Sri

> Alper

_______________________________________________
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: Thu, 3 Jan 2008 15:36:32 -0800 (PST)

Hi Behcet,

>  IMHO HNP, in view of multihoming support could be the stable identifier. Yes the first PBU will not contain HNP but all others will, right?

No. Requires CT in place for that to be present all times. A given
MAG can always send the HNP after the initial assignment. But, when
there is a handoff to a new MAG, it would not know what HNP to send
and so that's not the stable identifier.

MN-Id truley identifies the node that is getting the mobility service.
The IID, HNP or Access Technology identify provide sufficient hints
for the LMA to identify the binding that the request needs to be
associated with.

Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 6 Jan 2008 22:58:00 +0200

> > Hi Sri,
> >  IMHO HNP, in view of multihoming support could be the stable
> identifier. Yes the first PBU will not contain HNP but all others will,
> right?
> 

How does the new MAG know what the MN-ID is? New MAG receives it via either
CT or AAA. The same CT/AAA mechanism could also deliver the HNP to the new
MAG.

Alper

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 7 Jan 2008 07:09:05 -0800 (PST)

Hi Alper,

> CT or AAA. The same CT/AAA mechanism could also deliver the HNP to the new

MN-Id can also be obtained by the MAG as part of access authentication, in
addition to the ways you mentioned above.

Regards
Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 7 Jan 2008 19:09:57 +0200

Sri,

> addition to the ways you mentioned above.

Actually that's what I had meant by "AAA".

Alper

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 7 Jan 2008 19:39:03 -0800

Hi Alper, 

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Monday, January 07, 2008 9:10 AM
> To: 'Sri Gundavelli'
> Cc: 'Behcet Sarikaya'; 
> [email-masked]; [email-masked]
> > > How does the new MAG know what the MN-ID is? New MAG 
> receives it via
> > either
> > > CT or AAA. The same CT/AAA mechanism could also deliver 
> the HNP to the
> > new
> > > MAG.
> > >
> > 

If the assigned prefix is a static prefix and configured in AAA
and for AAA based authentications, the MAG will have access to
HNP just as it would have access to MN-Id. I agree !
For all other cases, the MAG may or may not have access to HNP.
The key difference is the requirement for the Authentication
system such as AAA to have the MN's HNP pre-configured for using
HNP as the stable identifier in PMIP signaling. The MN-Id as the
stable identifier, gives the additional flexibility for supporting
dynamic prefix assignment and it is a true stable identifier and
will eliminate any issues related to address reuse and identity
ambiguity.

Regards
Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 8 Jan 2008 11:22:09 +0200

Sri,

I was not arguing against use of MN-ID. I'm afraid you are confusing my
point with an earlier thread :)

You seem to suggest that HNP cannot be available to the new MAG when the MN
performs handover to it. And my point was that the new MAG needs to learn
the MN-ID via CT or AAA, and through that it can also learn the HNP.  

Alper

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2008 5:39 AM
> To: 'Alper Yegin'
> Cc: 'Behcet Sarikaya'; [email-masked];
> [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 8 Jan 2008 06:41:58 -0800 (PST)

Hi Alper,

Thanks for the clarification. I do agree that HNP is available
when CT is in place and also thru AAA when its pre provisioned
in AAA. Sorry for the confusion, I thought you are not ok with
the MN-Id presence in signaling messages.

Regards
Sri