Subject: [MEXT] Binding Revocation almost ready for IESG

From: Julien Laganier <[email-masked]>
Date: Thu, 7 May 2009 11:32:35 +0200

Folks,

I have reviewed the draft as a document shepherd and I believe it would 
be ready for IESG provided the comments below are addressed. 

Throughout the document
-----------------------

=> Inconsitent usage of capitalized/uncapitalized Mobile IPv6 and Proxy 
Mobile IPv6. I think everything should be capitalized.

=> Inconsistent use of abbreviation and expanded forms in the text, e.g. 
MAG vs. mobile access gateway in the same sentence. I think you should 
choose, either define those upfront (e.g. by pointing to RFC5213) and 
stick to the abbreviation in rest of the text, or use the developped 
form everywhere. Includes MAG, LMA, BRI, BRA...

In 3.2
------

   This mechanism enables the home domain to dynamically allow
   the user to act upon the revocation message in order to recover its
   interrupted mobile IPv6 services.

=> How about:

   This mechanism enables the user to react to the revocation, e.g.,  
   reinstate its interrupted Mobile IPv6 services.

In 3.4
------

   Since the Mobile node does not participate in the mobility mechanism
   in the case of PMIPv6, there are many scenarios where Binding
   Revocation mechanism is needed to clean resources and make sure that
   the mobility entities, e.g.  MAG and LMA, are always synchronized

=> Should be i.e. instead of e.g.

In 3.4.1.
---------

   In this case, the MAG could send a Router Advertisement message to
   the MN with the home network prefix lifetime set to zero.

=> the PIO for the home network prefix has two lifetime, here I think 
you're talking about the valid lifetime. If so, please fix. 

In 4.
-----

   Additionally, in the case when the LMA receives a BRI which indicates
   a bulk termination where the (G) bit is set and the Revocation
   Trigger field is set to "Per-Peer Policy", the LMA MUST verify that
   the MAG sending the binding revocation indication message is
   authorized to invoke Global revocation.

=> What sort of authorization do you have in mind here? Do you mean the 
LMA MUST verify that the MAG sending the binding revocation indication 
message is the one who currently owns the binding as per the BCE? If so 
better to be spelled out.

In 6.1.
-------

      Reserved and Per-MN Revocation Trigger:
          0  Reserved
          1  Unspecified
          2  Administrative Reason
          3  Inter-MAG Handover
          4  User Initiated Session(s) Termination
          5  Access Network Session(s) Termination
          6  Possible Out-of Sync BCE State

=> What is Possible Out-of Sync BCE State? The others are 
self-explaining, but this one I am unclear when it shall be sent, 
neither what it mean when I receive... Could we be more precise?

     Global Revocation Trigger:
          128  Per-Peer Policy
          129  Revoking Mobility Node Local Policy

=> I find the names of these triggers confusing. I've looked at the 
descriptive text in the following section and I found it difficult to 
get a clear picture of what they are about. If I'm the only one 
confused I don't insist on any changes, but if not, maybe we could try 
to improve the description of global revocation...

In 7.
-----

7.  Binding Revocation Process Considerations

   The following subsections describe the details of the binding
   revocation generic process by the different mobility entities.

=> I do not like the title, the subsections contain normative text, thus 
these are everything but "considerations". Please change to something 
straightforward and relevant: "Generic Mobile Entity Operation" or sthg 
else.

In 7.1.
-------

   When sending a Binding Revocation message, the sending mobility node,
   initiator, constructs the packet as it would any other Mobility
   Header with the exception of setting the MH Type field to <IANA-TBD>.

=> but later it says:

   When a mobility entity initiates the binding revocation process by
   sending a Binding Revocation Indication message, the initiator MUST
   construct the BRI message as described in Section 6.1. 

=> and:

   However, when the responder acknowledges the BRI message by sending a
   BRA, the responder MUST construct the Binding Revocation
   Acknowledgement as described in Section 6.2. 

=> so which one is it, as any other mobity header, or as per 6.1 and 
6.2?

   The mobility entity which initiates the revocation process MUST use
   the underlying security association, e.g., IPsec SA, that has been
   used to secure the mobile node binding registration signaling in
   securing the BRI and BRA messages transmission with the responding
   mobility entity.

=> Why do you restrict to "which initiates the revocation process"? Does 
it mean the responder uses no security association?! I think what we 
want to say is: "A mobility entity MUST secure BRI and BRA message with 
the same underlying security association, e.g., IPsec SA, that has been 
used to secure the mobile node binding registration signaling." No?

In 7.2.
-------

   Upon receiving a packet carrying a Binding Revocation Indication, the
   receiving mobility entity, responder, validates that the packet was
   received protected with the security association that already has
   been established with the mobility entity, initiator, and used during
   the registration signaling phase, e.g., IPsec SA.

=> As above I think we'd get a clearer wording if we do not use 
responder neither initiator. Also the text doesn't cover the BRA. How 
about: "Upon receiving a packet carrying a BRI or BRA, the receiving 
mobility entity verifies that the packet was received protected with 
the security association that has been used during the binding 
registration signaling phase, e.g., an IPsec SA."

In 14.
------

   However, in the case when the MAG sends a BRI message with the Global
   (G) bit is set and the Revocation Trigger field is set to "Per-Peer
   policy", the LMA MUST verify that the MAG is authorized to use Per-
   Peer Global Revocation.

=> Again I'd appreciate a better scoping of authorization in the above.

Hope that helps to improve the document before it hits IESG.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 May 2009 14:50:52 -0500

Hello Julien,
Thanks for the review. Please see comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Thursday, May 07, 2009 4:33 AM
> To: [email-masked]
> Cc: Muhanna, Ahmad (RICH1:2H10); marcelo bagnulo braun
> Subject: Binding Revocation almost ready for IESG
> 
> Folks,
> 
> I have reviewed the draft as a document shepherd and I 
> believe it would be ready for IESG provided the comments 
> below are addressed. 
> 
> Throughout the document
> -----------------------
> 
> => Inconsitent usage of capitalized/uncapitalized Mobile IPv6 
> and Proxy Mobile IPv6. I think everything should be capitalized.

[Ahmad]
Sure.

> MAG vs. mobile access gateway in the same sentence. I think 
> you should choose, either define those upfront (e.g. by 
> pointing to RFC5213) and stick to the abbreviation in rest of 
> the text, or use the developped form everywhere. Includes 
> MAG, LMA, BRI, BRA...

[Ahmad]
Will follow what RFC5213 and other IP mobility RFCs by using the
expanded form.

>    reinstate its interrupted Mobile IPv6 services.
[Ahmad]
That is good. Will use that.

> => Should be i.e. instead of e.g.
[Ahmad]
Ok.

> => the PIO for the home network prefix has two lifetime, here 
> I think you're talking about the valid lifetime. If so, please fix. 
[Ahmad]
Sure.

> => What sort of authorization do you have in mind here? Do 
> you mean the LMA MUST verify that the MAG sending the binding 
> revocation indication message is the one who currently owns 
> the binding as per the BCE? If so better to be spelled out.
>
[Ahmad]
That is given, a MAG which does not have or previously had created a BCE
for the MN is allowed to send a BRI for that MN. However, what is meant
here: is that MAG allowed to participate in Bulk revocation? We
discussed this on the ML quite a bit and agreed that for a MAG to issue
a global revocation which presumably impacts  all sessions between the
MAG and the LMA is something needs authorization and agreement between
the two nodes.
 
> self-explaining, but this one I am unclear when it shall be 
> sent, neither what it mean when I receive... Could we be more precise?

[Ahmad]
At anytime the LMA suspect that the state of the respected BCE is
possibly out-of Sync at the MAG, the LMA sends this BRI to indicate
that. One possible scenario that was discussed is when the LMA receives
a BU which reference the same BCE. The MAG could either acknowledge,
reject the BRI or possibly sends a Binding Lifetime extension PBU.

Since we are at this, I would also bring the following:
Based on some discussion on the ml before the last update, we collapsed
all inter-MAG handoff B. R. Triggers in a single one "Inter-MAG
Handover" and forgot that the granularity we had in rev. 04 and earlier
is NEEDED for 3GPP2. Therefore, we need to bring those B. R. Triggers
back to life, i.e., 
 	    3  Inter-MAG Handoff - same Access Types
          4  Inter-MAG Handoff - different Access Types
          5  Inter-MAG - Unknown Handoff

Also, at one point, I believe Joel suggested a more granular Revocation
Triggers by classifying the B. R. Triggers as soft vs. Hard. It may be a
good idea to adopt that classification where soft Binding Revocation
Trigger indicates to the receiving node a possible update or a
synchronization of the BCE between the sending node and the receiving
one is required while the Hard means the receiving node will remove the
BCE. 
 
> => I find the names of these triggers confusing. I've looked 
> at the descriptive text in the following section and I found 
> it difficult to get a clear picture of what they are about. 
> If I'm the only one confused I don't insist on any changes, 
> but if not, maybe we could try to improve the description of 
> global revocation...

[Ahmad]
Sure, we will clarify that a little more. In general, the Per-Peer
Policy trigger is used ONLY when the BRI with the (G) bit set impacts
all current BCEs between the LMA and the MAG. On the other hand, the
Revoking Mobility Node Local Policy is used when the (G) bit is set but
the content of the BRI targets only a specific group of BCEs. For
example BCEs which share a specific realm in their MN-IDs, etc.

> => I do not like the title, the subsections contain normative 
> text, thus these are everything but "considerations". Please 
> change to something straightforward and relevant: "Generic 
> Mobile Entity Operation" or sthg else.
[Ahmad]
No problem, will do.

> => so which one is it, as any other mobity header, or as per 
> 6.1 and 6.2?
[Ahmad]
I guess we need to have the text tweaked a little. But, the Binding
Revocation message is a mobility header and BRI format is defined in
section 6.1. and for BRA in section 6.2. so It is built as any other
mobility header + following the format specified in 6.1 or 6.2.

> => Why do you restrict to "which initiates the revocation 
> process"? Does it mean the responder uses no security 
> association?! I think what we want to say is: "A mobility 
> entity MUST secure BRI and BRA message with the same 
> underlying security association, e.g., IPsec SA, that has 
> been used to secure the mobile node binding registration 
> signaling." No?

[Ahmad]
Perfect. Thanks!

> => As above I think we'd get a clearer wording if we do not 
> use responder neither initiator. Also the text doesn't cover 
> the BRA. How
> about: "Upon receiving a packet carrying a BRI or BRA, the 
> receiving mobility entity verifies that the packet was 
> received protected with the security association that has 
> been used during the binding registration signaling phase, 
> e.g., an IPsec SA."
> 
[Ahmad]
Thx. Again!

> Hope that helps to improve the document before it hits IESG.
[Ahmad]
Indeed. Thanks for the comments Julien! 
I will start working on the update and hopefully will be able to spin a
quick one soon.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 20 May 2009 01:01:56 -0500

Hi Vijay,
Please see inline.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, May 19, 2009 5:40 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: mext; Julien Laganier
> Subject: Re: Binding Revocation almost ready for IESG
> 
> Hi Ahmad,
> 
> 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".

> Instead, I suggest going with just two values
> 
>   3  Inter-MAG Handover
>   4  Inter-MAG Handover - different access types
> 
> '3' implicitly means it is the same access type. PMIPv6 after 
> all is supposed to be used for local mobility. :)
>
[Ahmad]
:)
No need to restate the definition of PMIP domain. 
I thought that you are the one who championed drafting that text:)
 
> 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 "[email-masked]"

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.

Cheers! 
> Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 May 2009 16:28:01 -0700

Hi Ahmad,

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.

> 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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 22 May 2009 10:31:48 -0500

Hi Vijay,

Regards,
Ahmad
> >> You explained to me that 3GPP2 wants to differentiate 
> between the two 
> >> following triggers.
> >> 
> >> But what should the MAG behavior be when it receives the following 
> >> trigger?
> >> 
> > 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 
> 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 
[Ahmad]
The LMA does nothing other than what is documented in RFC5213. 
This is exactly the same case as if the LMA did not receive a
de-registration from the previous MAG and the timer expired. I do not
think it is necessary to add anything, but we could add a pointer to
RFC5213 for this specific case when handling the AD comments.

> >> 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 
> removed from 
> >> the draft).
> > I think we keep coming back to this point:) It is based on the home 
> > domain policy.
> > 
> > period. Example: only between MAG(s) and LMA(s) that belong to the 
> > same operator.
> > 
> 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. :)

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

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

> Instead, add the following 
>   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.

> Therefore the

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 May 2009 10:56:19 -0700

Hi Ahmad,

I am going to split the emails into two, since we are dealing with two 
issues.

> RFC5213 for this specific case when handling the AD comments.

This doesn't make sense. RFC 5213 says if the LMA receives a PBU with HI 
set to "handoff state unknown", it should wait for 
MaxDelayBeforeNewBCEAssign amount of time for a deregistration PBU from 
the old MAG. If there is no such deregistration message from the old 
MAG, it would create a new mobility session.

The Binding revocation document suggests that the LMA must send a 
binding revocation message with the trigger set to "handoff state 
unknown". If the MN is still attached, the old MAG would reject the 
binding revocation. Then the LMA would proceed with creating a new 
mobility session.

How can these two be compatible?

IMO, the binding revocation document should say that it is updating RFC 
5213 when it comes to the LMA behavior when it receives a PBU with HI 
set to "handoff state unknown". If the LMA and the MAG implement binding 
revocation, they should follow the mechanism described in the binding 
revocation document rather than the one in RFC 5213.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 May 2009 11:05:09 -0700

Hi Ahmad,

Now to the other issue...

> RFC5213. I believe we discussed this offline before and now we are going

We never resolved this, though. :)

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

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

> have a problem handling this, then you probably have a problem with

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 23 May 2009 07:22:21 -0500

Hi Vijay,

Regards,
Ahmad

> Sent: Friday, May 22, 2009 12:56 PM
> Subject: LMA behavior for HI status unknown (was Re: Binding 
> Revocation almost ready for IESG)
> 
> Hi Ahmad,
> 
> I am going to split the emails into two, since we are dealing 
> with two issues.
> 
> Ahmad Muhanna wrote:
> 
> 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.
> >>
> > [Ahmad]
> This doesn't make sense. RFC 5213 says if the LMA receives a 
> PBU with HI set to "handoff state unknown", it should wait 
> for MaxDelayBeforeNewBCEAssign amount of time for a 
> deregistration PBU from the old MAG. If there is no such 
> deregistration message from the old MAG, it would create a 
> new mobility session.
> 
> The Binding revocation document suggests that the LMA must 
> send a binding revocation message with the trigger set to 
> "handoff state unknown". If the MN is still attached, the old 
> MAG would reject the binding revocation. Then the LMA would 
> proceed with creating a new mobility session.

[Ahmad]
Where in the revocation draft it said that the LMA must send a BRI with
the trigger set to "handoff state unknown"?

> How can these two be compatible?
[Ahmad]
We can debate this offlist, I guess:)
Please see below.

> 5213 when it comes to the LMA behavior when it receives a PBU 
> with HI set to "handoff state unknown". If the LMA and the 
> MAG implement binding revocation, they should follow the 
> mechanism described in the binding revocation document rather 
> than the one in RFC 5213.

[Ahmad]
Although, I still believe that these two cases compatible but I agree
with the end result that you are proposing. I see your point when the
LMA support Binding Revocation and at the same time already support
RFC5213, we need to be clear on what the LMA needs to do if it decides
to send a BRI message to the old MAG rather than waits for a
de-registration to come.

Will come up with some text which address this option, i.e., when the
LMA uses BRI proactively to define if the MN is no longer attached to
the old MAG or not to be able to handle the PBU with HI unknown coming
from the new MAG.

Do we need a new revision for this or we can add the text during the AD
review and comments?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 23 May 2009 08:37:35 -0500

Hi Vijay,

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

> >> 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,
> > 
> > RFC5213. I believe we discussed this offline before and now we are 
> > going back again. :)
> 
> > 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:
> > "
> 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.
> > 
> > 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.
> 
> >>   messages from the MAGs. Bulk revocation, when used 
> inappropriately, 
> >> can
> > 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