Re: [netlmm] [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt

[Vijay Devarapalli <[e-mail]>]

Hi Sri,

Sri Gundavelli wrote:
> 
> 
> On Mon, 16 Mar 2009, Vijay Devarapalli wrote:
> 
>> Sri Gundavelli wrote:
>>> > > >  Does the LMA keep a list of MAGs that are authorized for
>>> > >  sending bulk revocations? How is this list configured? In
>>> > >  addition, I think this authorization step is unnecessary and
>>> > >  should be removed.
>>> >
>>>
>>>  Bulk revoc is a high security risk operation, requiring such
>>>  authorization check will allow the system to build some
>>>  configurability into the system.
>>>
>>>  Even for a single binding, if you recall and as Ahmad pointed
>>>  out, we do require this in 5213. We added this per IESG note.
>>
>> This authorization check was added in a very early version of the 
>> PMIPv6 draft in response to a review from Lakshminath. Not due to the 
>> IESG. One of the options suggested was to have the LMA check if the MN 
>> is really attached to the MAG before allowing the MAG to create a 
>> binding for the mobile node. But this has nothing to do with the 
>> authorization check for bulk revocation.
>>
> 
> No. That's not true. I've added this during the AD review. We may
> have discussed this earlier, but this specific authorzation check
> was added per the AD review. We may have discussed this very
> early and I remember that discussion as well.
> 
> http://www.ietf.org/mail-archive/web/netlmm/current/msg04144.html

This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in 
April 2007 had the following

    However, the local mobility anchor MUST allow only authorized mobile
    access gateways to create binding cache entries on behalf of the
    mobile nodes.  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
    sending a query to the policy store such as by using AAA
    infrastrucure.

See http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-00

AD review happened in Jan 2008.

>>>  Before the MAG can create a binding, the LMA is required to check
>>>  if the given MAG is authorized to perform such an operation. The
>>>  same goes for dereg, its enforced indirectly, there is a check
>>>  for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the
>>>  dereg is allowed.
>>
>> When the MAG de-registers a mobile node's session, there is no 
>> authorization check. The LMA only makes sure that it the same MAG that 
>> is responsible for the binding.
>>
> No, there is a indirect check. The MAG before deregistering,
> will match the Proxy-CoA in the request to that present in
> the binding. Prior to that BCE creation, the LMA allowed only
> a authorized MAG to create that binding. So, this check at dereg
> will indirectly enforce the same.

This is NOT an indirect authorization check. As I have said in this 
thread many times, the MAG that created the binding is allowed to delete 
the binding. Simple. There is no authorization check when deleting the 
binding.

Sorry, I am not convinced that this authorization check is needed for 
bulk revocation from the MAG.

Vijay


>>>  Now, this check for bulk dereg spanning many MN's is for the
>>>  specific operation, if its allowed or not. This is a requirement
>>>  for a good system design, from OM perspective. Has no bearing
>>>  on protocol interop. I dont think this can be an issue, one
>>>  can always add a * rule to permit every MAG to perform such
>>>  operation.
>>
>> This does not make sense. If we are going to create a rule allowing 
>> all MAGs to perform bulk revocation, then why do we need the 
>> authorization check?
>>
> Building the rule into the system is for defining an authorization model,
> relaxing that rule in a given system deployment is a SDO/deployment
> choice. That's the operator's choice based on the security considerations
> in their operating environment.
> 
> 
>>>  If your concern is maintaing that list, we can always state in
>>>  a secure network, the MAG can just have one flat rule to allow
>>>  such operation from all the configured peers that it knows.
>>>  Will that work ?
>>
>> You mean the LMA, right? The LMA is the one that does this check.
>>
> 
> Yes, typo
> 
>> Your email does not address my question on how this list is created at 
>> the LMA. Why is one MAG special and allowed to do bulk revocation 
>> while another MAG is not allowed? The MAGs are all part of the same 
>> PMIPv6 domain.
>>
> 
> There is not much to address. We require the LMA to maintain a list
> of MAG's authorized to perform certain functions. We need a very similar
> list, or add an attribute to the above maintained list, with finer
> access control as who can perform bulk dereg operations.
> 
> 
> Sri
> 
> 
> 
>> Vijay
>>