[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Vijay,



On Mon, 16 Mar 2009, Vijay Devarapalli wrote:


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 



We are not discussing about the check related to a MN attachment at
a given MAG. We are discussing about the LMA requiring to maintain
MAG authorization list, that's exactly Ahmad is talking about for
allowing/dis allowing Bulk Authorization list. How is this below check
relevant to this discussion ? The text I quoted with respect to MAG
authorization list was provided by our AD and thats what we have in
5213.



   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.



Right. The quoted text in Security considerations that was there
from very begining is not about MAG authorization list, thats for
the proof of MN attachment at a given MAG.



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



MAG created a single binding and can very well delete a single binding
by sending a single request. That did not provide an explicit right
to delete all 30,000 bindings in a single message. That request needs
to pass additional authorization, as that can impact many sessions.
Sorry, I am not convinced that this authorization check is needed for bulk revocation from the MAG. 



Sorry, I'm not convinced with this argument either. I dont see a single
interop/implementation issue requring LMA maintain that list, 5213 already
maintains that list. If this is unnecessary in a given trusted secure network, one can very well relax that. But, from a protocol design 
perspective, this needs to be specified. I agree with Ahmad.


Sri