Re: [MEXT] Binding Revocation almost ready for IESG

[Vijay Devarapalli <vijay at wichorus.com>]

Hi Ahmad,

On 5/19/09 11:01 PM, "Ahmad Muhanna" wrote:

>> I have a couple of comments on version 10
>> 
>> You explained to me that 3GPP2 wants to differentiate between
>> the two following triggers.
>> 
>>   3  Inter-MAG Handover - same Access Type
>>   4  Inter-MAG Handover - different Access Type
>>    
>> That's fine. 
> [Ahmad]
> Thanks for agreeing on adding these two back! :)
> 
>> But what should the MAG behavior be when it
>> receives the following trigger?
>> 
>>  5  Inter-MAG Handover - Unknown
>> 
> [Ahmad]
> The MAG will reject the BRI with code "MN still attached" :)
> I mean, the MAG is supposed to check whether the mobile node is attached
> or not and based on its finding, it should reply back either success or
> failure, e.g., "MN still attached".

Ok.

So what does the LMA do now? The new MAG is saying the MN attached to it and
the handoff state is "unknown". The old MAG is saying the MN is still
attached? Shouldn't this result in a new mobility session being setup for
the attachment through the new MAG? It won't be treated as a handover
anymore. This probably needs to be explained.

>> 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. Here is another
suggestion. Remove all text related to the authorization check when the MAG
sends a bulk revocation message in the draft. 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. Therefore the
  LMA should check if the MAG is authorized to send a bulk revocation
  message before processing the message. To implement this check, the LMA
  should be configured with the information about which MAGs are allowed to
  perform bulk revocation. For example, all the MAGs in a particular
  PMIPv6 domain can be authorized for bulk revocation, while othes are not.
  If the LMA decides to reject the bulk revocation message from the MAG,
  it should send a BRA message with status set to '130' (Global Revocation
  NOT Authorized).

Feel free to modify the above text.

In section 3.1, delete
   
   When the local mobility anchor
   receives such Binding Revocation Indication message, it ensures that
   the mobile access gateway is authorized to send such bulk termination
   message and then processes the Binding Revocation Indication message
   accordingly. 

In section 3.4.2, replace

   When the local mobility anchor
   receives a Binding Revocation Indication message with the (G) bit is
   set from a specified mobile access gateway, the local mobility anchor
   first checks if the mobile access gateway is authorized to use global
   revocations and then responds with the appropriate status code by
   sending a Binding Revocation Acknowledgement message as in
   Section 9.2.2.

With

   When the local mobility anchor
   receives a Binding Revocation Indication message with the (G) bit
   set from a specified mobile access gateway, the local mobility anchor
   first processes the message and then responds with the appropriate
   status code by sending a Binding Revocation Acknowledgement message
   as in Section 9.2.2.

In section 4, delete

   Additionally, in the case when the local mobility anchor receives a
   Binding Revocation Indication which indicates a bulk termination
   where the (G) bit is set and the Revocation Trigger field is set to
   "Per-Peer Policy", the local mobility anchor MUST verify that the
   mobile access gateway sending the binding revocation indication
   message is authorized to invoke global revocation.

In section 9.2.1, delete

      The local mobility anchor MUST verify that
      the identified mobile access gateway as per the value in the MN-ID
      option is authorized to use the Global revocation.  The mechanism
      the local mobility anchor uses to verify the mobile access gateway
      authorization is out of scope of this document.

Hope this works for you..

Vijay