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

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

Hi Ahmad,

Now to the other issue...

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

Vijay