Re: [MEXT] Authorization check for bulk revocation (was Re: Binding Revocation almost ready for IESG)

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hi Vijay,

> Subject: Authorization check for bulk revocation (was Re: 
> Binding Revocation almost ready for IESG)
> 
> Hi Ahmad,
> 
> Now to the other issue...
[Ahmad]
Yes; indeed:)

> 
> Ahmad Muhanna wrote:
> 
> >>>> On authorization for bulk revocation, we need some text
> >> that explains
> >>>> how the LMA is supposed to check if a particular MAG is
> >> authorized to
> >>>> perform bulk revocation. Is this list of 
> >>>> "MAGS-authorized-for-bulk-revocation"
> >>>> manually created on the LMA? If not, how is this populated?
> >>>>
> >>>> (FWIW, I still think this authorization check should be
> >> removed from
> >>>> the draft).
> >>> [Ahmad]
> >>> I think we keep coming back to this point:) It is based 
> on the home 
> >>> domain policy.
> >>>
> >>> 1. Some home domain probably wont allow this across
> >> different domain
> >>> period. Example: only between MAG(s) and LMA(s) that 
> belong to the 
> >>> same operator.
> >>>
> >>> 2. It could be as simple as all MAGs which IDs matches a
> >> simple string
> >>> of "wildcard at xyz.com"
> >>>
> >>> 3. It could be as simple as "every MAG which is able to
> >> establish an
> >>> IPsec SA for protecting PMIP signaling is authorized for Global 
> >>> revocation; I guess this matches your views to some extent.
> >>>
> >>> 4. etc.
> >>>
> >>> Leaving the details out of scope gives the flexibility 
> for the home 
> >>> domain to enforce its own policy freely.
> >>>
> >>> I hope this address your concern.
> >> No, it doesn't. In general, you can't require some behavior on the 
> >> LMA and then not specify how the LMA is supposed to implement it.
> > 
> > [Ahmad]
> > Vijay,
> > 
> > This behavior is NO different than what is currently required in 
> > RFC5213. I believe we discussed this offline before and now we are 
> > going back again. :)
> 
> We never resolved this, though. :)
> 
> > What I meant by out of scope is: out-of-scope of this 
> document because
> > RFC5213 contains very similar requirement already. Why it is NOT an 
> > issue in RFC5213 when the LMA needs to ensure that the MAG is 
> > authorized to send a PBU on behalf of the mobile node and a 
> specific 
> > prefix? This is exactly similar.
> > If you like, I could cut and paste the text from RFC5213 
> and include 
> > it this draft or add a pointer to section 4.0 of RFC5213.
> > 
> > Here the related text:
> > "
> >    ...................................... Therefore, the 
> local mobility
> >    anchor MUST restrict the creation and manipulation of 
> proxy bindings
> >    to specifically authorized mobile access gateways and 
> prefixes.  The
> >    local mobility anchor MUST be locally configurable to 
> authorize such
> >    specific combinations.  Additional mechanisms, such as a 
> policy store
> >    or Authentication, Authorization, and Accounting (AAA) may be
> >    employed, but these are outside the scope of this specification.
> > "
> 
> The above text addresses very specific issue - that of a MAG 
> modifying the routing state for a mobile node. One of the 
> concerns that was brought up at the time of RFC 5213 
> standardization was that the MAG could be modifying the 
> routing state for a Mobile IPv6 mobile node. So we had to add 
> explicit text about the LMA checking if the MAG is authorized 
> to create/delete/modify the binding for a mobile node. This 
> text was a result of extensive discussions, basically a sort 
> of compromise...
> 
> I am not going to agree to using this for adding more 
> specification text along these lines... Having something like 
> the above in RFC 5213 does not justify adding more similar 
> authorization checks in the binding revocation document.

[Ahmad]
I absolutely understand where you are coming from, Although, I do not
recall being part of that discussion or remembering if it was on the
mailing list, but I could be wrong and that is not the point.

RFC5213 is NOW a standard specification and most of implementations will
NOT remember or pay attention to what was the discussion which took
place before adopting a specific requirement NOR people care who
compromised what. Implementers read what in the RFC and try their best
to comply with its content and implement it.

Having said that, I believe the following (some of this may have been
said before):

1.  Bulk revocation potentially impacts all sessions between a pair
MAG-LMA and consequently needs to be handled carefully and addressed
properly.

2. If we do not specify a mechanism for this, we will end up with two
models: 
2.1. Some deployment will disable this feature completely and hence as
if we did not add this functionality to start with. But let us remember,
this was added from day one because there was a need for it.

2.2. some deployment may not pay enough attention and allow this to
happen without the proper validation and they properly will realize its
negative impact after they go through a major problem and then start
looking for patching or disabling a good functionality that they need or
looking for a quick solution after the fact which is very painful!

3. Since, RFC5213 already has a mechanism similar to this, why NOT we
point to that mechanism and move on.

4. You started by saying that we can not define a function which impact
the LMA behavior and NOT specify how the LMA will be able to do it. I
understand that part; But, when we moved to specify a default mechanism
by pointing to what is already documented in RFC5213, now you are saying
NO way to specify a default mechanism or add anything to specify how the
LMA could do it! Do not you think that is a recipe and a proposal for
preventing any conclusion on this issue?



> 
> >> Here is another suggestion. Remove all text related to the 
> >> authorization check when the MAG sends a bulk revocation 
> message in 
> >> the draft.
> > 
> > [Ahmad]
> > No.
> > 
> > Again, this is no different than what is mentioned above. No. 1. 
> > No. 2. This functionality has been in the draft since day 
> one and all 
> > of a sudden it becomes a problem without a clear reason.
> 
> Sorry, you can't use the text in RFC 5213 to justify the 
> authorization check for bulk revocation.
> 
> >> Instead, add the following
> >> text to the Security Considerations sections
> >>
> >>   An LMA implementation should be careful in processing bulk 
> >> revocation
> >>   messages from the MAGs. Bulk revocation, when used 
> inappropriately, 
> >> can
> >>   deny mobility service to a large number of mobile nodes. 
> > 
> > [Ahmad]
> > This is an interesting statement to add in the security section! If 
> > you admit there is a problem why removing the solution to 
> start with? 
> > If you have a problem handling this, then you probably have 
> a problem 
> > with RFC5213.
> 
> Mandating something on the LMA is different from describing a 
> possible security threat in the security considerations 
> section and suggesting solutions to mitigate that threat. 
> They are *NOT* the same.
[Ahmad]
Hmmm.. Well, if we follow this logic, we could live without ever
mandating or specifying any solution and turn this specification to a
big fat security section! while letting people figure a way to solve it.
Not only that, but at the end we also claim that we have a standard
specification.

The key question here:
Is this functionality needed to be part of this specification or NOT?
My reading for all of your reasoning on this threat, is yes you agree
and you want us to specify a default mechanism to handle it. Sure; We
have one that is supposed to be already in place.

Regards,
Ahmad

> 
> Vijay
>