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

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Mar 2009 17:21:18 -0800

Hello,

I reviewed this document. It needs some work before it can be sent to 
the IESG. Comments follow.

> Abstract
> 
>    This document defines the revocation semantics for terminating a
>    mobile node's mobility session and associated resources.  

How about saying

   This document defines a binding revocation mechanism to terminate a
   mobile node's mobility session and release the associated resources.

>    In the case of Mobile IPv6 and for administrative reason, sometimes
>    it becomes necessary to inform the mobile node that its registration
>    has been revoked and the mobile node is no longer able to receive IP
>    mobility service using its Home Address.  In some networks where
>    Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4
>    registration revocation mechanism has been specified [RFC3543].

The MIPv4 registration mechanism was specified in the IETF, not in the 
networks where Mobile IPv4 has been deployed. :) I think the last 
sentence needs to be re-worded.

>    This document defines the semantics of the revocation mechanism of a
>    mobile node registration binding, which could have been established
>    using a Client Mobile IPv6 or any of its extensions, e.g.  Proxy
>    Mobile IPv6 signaling.  

Re-write as

   This document specifies the binding revocation mechanism to remove
   a mobile node's mobility sessions. The same mechanism can be used to
   revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy
   Mobile IPv6 [RFC 5213].

We don't use "Client Mobile IPv6" in the IETF. :) And we need references 
to RFC 3775 and 5213, since they are mentioned here for the first time 
in this document.

> 2.2.  Terminology
> 
>    All the general mobility related terminology and abbreviations are to
>    be interpreted as defined in Mobile IPv6 specification [RFC3775] and
>    Proxy Mobile IPv6 specification [RFC5213].

Maybe you should define the term "mobility agent" here. Basically, it 
would be the Home Agent, LMA and the MAG. You have used "mobility node" 
throughout the document. A "mobility node" is kind if vague. Suggest 
replacing all occurrences with "mobility agent".

>    In the case of Client Mobile IPv6, the revocation procedure can be
>    initiated by the home agent.  

"can be"? It is always the home agent right? Suggest re-wording to

   In the case of Mobile IPv6, the revocation procedure is initiated by
   the home agent.

If the home network decides to
>    terminate the service of the mobile node, the home agent sends a
>    Binding Revocation Indication (BRI) message to the mobile node.  The
>    home agent includes the HoA in the type 2 routing header as specified
>    in [RFC3775] to indicate the impacted mobile node binding.  When the
>    mobile node receives a BRI message with its HoA included and the
>    Acknowledge (A) bit is set, the mobile node responds by sending a
>    Binding Revocation Acknowledgement (BRA) message.

hmm... Won't the mobile node delete the binding first before sending the 
BRA message?

>    In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also
>    be initiated by the home agent.  

Again, it is always the home agent that initiates the revocation 
mechanism. Who else can do it in DS-MIPv6?

If the home network decides to
>    terminate the service of the mobile node, the home agent sends a BRI
>    message to the mobile node to indicate the termination of the mobile
>    node IP Mobility service.  The home agent may include the HoA option

s/HoA option/IPv4 Home Address Option/

I don't know of any other option that carry the IPv4 home address.

>    with the mobile node assigned home IPv4 address.  After receiving the
>    BRI message with the Acknowledge (A) bit is set, the mobile node
>    responds by sending a BRA message.

Again, the mobile node would delete the binding first, I guess.

> 3.2.  Client MIPv6 and DSMIP6 Use Case

s/Client MIPv6/Mobile IPv6/

> 
>    Binding revocation mechanism is applicable to Client Mobile IPv6 and
>    DSMIPv6 session(s) when the home agent needs to inform the mobile
>    node that its binding registration has been revoked, e.g. for an
>    administrative reason.  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.

What does the last sentence mean? Isn't the mobile node required to do 
something when it gets a revocation message? The mobile node has to find 
another home agent, right? How can its services not be interrupted?

>    In this case, the home agent sends a BRI message to indicate to the
>    mobile node that its current mobile IPv6 binding has been revoked and
>    it no longer can receive IP mobility service.  The home agent
>    includes the mobile node home address in Type 2 routing header as
>    used in [RFC3775] and sets the Revocation Trigger field to a proper
>    value, e.g.  Administrative Reason.  In the case of DSMIPv6 session,
>    the home agent may additionally include the mobile node assigned IPv4
>    Home Address in the IPv4 Home Address Option.  When the mobile node
>    receives the BRI message, it sends a BRA message as described in
>    Section 11.2 to the home agent.  Figure 1 illustrates the message
>    sequencing when home agent revokes a mobile node binding
>    registration.
> 
> 
>          MN                                         HA
>          |                                           |
>          |  HoA in Type 2 Hdr + BRI [seq.#, A bit]   |
>          |<------------------------------------------|
>          |                                           |
>          |                                           |
>          |                                           |
>          |  HoA in Destination Option BRA[seq.#]     |
>          |------------------------------------------>|
>          |                                           |
>          |                                           |

Why is the HoA required in a destination option? The BRA message can 
just be sent from the CoA with no home address option in it. The Home 
Agent just needs to match the BRA to the BRI message using the sequence 
number field.

BTW, in figure 2, there is no HoA destination option in the BRA message.

> 3.3.1.  Termination of Multiple Care-of Addresses Bindings
> 
>    In the case of multiple care-of addresses, the home agent maintains
>    different binding for each pair of care-of address and home address.
>    These bindings are also indexed and identified during the mobile node
>    registration using a Binding ID mobility option [ID-MCoA].  In this
>    case, the HA may revoke any binding, more than one binding, or all of
>    the bindings for the same mobile node home address.

Re-phrase the last sentence as

   In this case, the HA may revoke one or more bindings for the same
   mobile node home address.

>    In the case when home agent revokes a single binding for a mobile

s/In the case when/In case/

>    node with multiple care-of addresses registration, the home agent
>    sends a BRI message to the mobile node with the corresponding BID
>    option included and the HoA is in the Type 2 routing header.  

Rephrase as

   node with multiple care-of addresses registration, the home agent
   sends a BRI message to the mobile node with the corresponding BID
   option included.

> If the
>    home agent needs to revoke more than one of the mobile node
>    registered care-of addresses, the home agent includes all the
>    corresponding Binding ID options which reference these care-of
>    addresses in the same BRI message.  

Rephrase as

   If the
   home agent needs to revoke more than one of the mobile node
   registered care-of addresses, the home agent includes all the
   corresponding Binding ID options in the same BRI message.

> 3.4.  Proxy MIPv6 Use Case
> 
>    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
>    with respect to the status of the existing proxy mobile IPv6
>    bindings.  The binding revocation mechanism is generic enough that
>    can be used in all applicable PMIPv6 scenarios and deployment
>    options.  For example, this revocation mechanism is still applicable
>    and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports
>    and when the mobile node uses IPv4 or IPv6 address as specified in
>    [ID-PMIP6-IPv4].

Thats a tall claim. We don't really where all PMIPv6 might be used. 
Suggest replacing the last two sentences with the following.

   The binding revocation mechanism is generic enough that can be
   used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4].

> 3.4.1.  Local Mobility Anchor Revokes A PMIPv6 Binding
> 
>    The local mobility anchor may send a BRI message to the mobile access
>    gateway, hosting a specific proxy mobile IPv6 binding, with the
>    appropriate value in the revocation trigger field to indicate that
>    the mobile node binding has been terminated and the MAG can clean up
>    the applicable resources.  When the MAG receives a BRI message, the
>    MAG identify the respected binding and if the (A) bit was set in the

s/identify/identifies/

>    The process identified above can also be used by the LMA in scenarios
>    other than the inter-MAG handoff with the proper revocation trigger
>    value to indicate to the peer MAG that a specific proxy mobile IPv6
>    binding or bindings have been revoked.
> 
> 
>                sMAG         tMAG                          LMA

Can we call this oldMAG and newMAG? We have traditionally used these 
terms in the IETF.

> 4.  Security Model
> 
>    The binding revocation protocol described here uses the same security
>    association between the MN and the HA or the MAG and the LMA that has
>    been used to exchange the corresponding Client MIPv6 or Proxy MIPv6
>    BU and BA when the mobile node binding was created.  If IPsec is
>    used, the traffic selectors associated with the SP protecting BU and

s/SP/SPD entry/

There are few places where this needs to be replaced.

>    BA MUST be extended to include Binding Revocation Signaling MH type
>    <IANA-TBD>.  Extending the traffic selectors of the SP in order to
>    reuse the SA protecting BU and BA (instead of creating new ones)
>    ensures that those SA will be up and running when the revoking entity
>    needs to send a Binding Revocation Signaling message.
> 
>    Additionally, in the case when the LMA receives a BRI which indicates
>    a bulk termination, i.e., the (G) bit is set, the LMA MUST verify
>    that the MAG sending the binding revocation indication message is
>    authorized to invoke Global revocation.

Why require this? It is after all the MAG that created all these 
bindings. And now the MAG wants to delete the bindings it created at the 
LMA. So why does this alone require an additional authorization step?

> 5.  Exchanging Binding Revocation Messages over an IPv4 Transport
>     Network
> 
>    In some deployments, the network between the MAG and the LMA may only
>    support IPv4 transport.  In this case, the Binding Revocation
>    messages (BRI and BRA) are tunneled over IPv4.  If the Proxy Binding
>    Update and Proxy Binding Acknowledgment messages are sent using UDP
>    encapsulation to traverse NATs, then the Binding Revocation messages
>    are sent using the same UDP encapsulation.  The same UDP port that
>    was used for the Proxy Binding Update and Proxy Binding
>    Acknowledgement messages will also be used when transporting Binding

Is the destination port in the BRI set to the DS-MIPv6 port or the 
source UDP port seen on the PBU from the MAG to the LMA? The NAT on the 
path might have changed the source UDP port on the PBU. So do you want 
the BRI to be sent to that port?

>    The following options are valid in a Binding Revocation Indication:
> 
>    o  Home Network Prefix option [RFC5213].  This option MAY be used
>       when the (P) bit is set.  This option MUST be present when the BRI
>       is used to revoke a single PMIP binding cache entry.
> 
>    o  Mobile Node Identifier Option [RFC4283].  This option is mandatory
>       when the (P) bit is set.  Additionally, If the (G) bit is set by
>       the mobile access gateway, this option carries the MAG identity.
> 
>    o  Binding ID mobility option [ID-MCoA].  This option is mandatory if
>       the sending mobility entity request to terminate one binding of a
>       multi care-of addresses bindings for the same mobile node.  The
>       sending mobility entity may include more than one of the Binding
>       ID mobility options.
> 
>    o  IPv4 Home Address option which contains the mobile node home IPv4
>       address [ID-DSMIP6].  This option is included only when the IPv4
>       HoA Binding only (V) bit is set.
> 
>    o  Alternate Care-of Address mobility option [RFC3775].  This option
>       MAY be included to indicate the Care-of Address of the mobile
>       node's binding that is being revoked.  In the case when the Global
>       (G) bit set, this option identifies all the mobility bindings that
>       share the same care-of address.  Additionally, if the Global (G)
>       bit set, more than one Alternate Care-of Address mobility options
>       MAY be present in the BRI message.

I don't understand the last one. Why is this needed? If Mobile IPv6 is 
used, the home address would identify the right binding that needs to be 
deleted. If MCoA is used, then the BID would identify the right binding. 
If PMIPv6 is used, the home network prefix option, MN ID option and the 
IPv4 home address options are sufficient to identify the right binding. 
So what is the last one used for?

> 7.1.  Sending Binding Revocation Messages
> 
>    When sending a Binding Revocation message, the sending mobility node,
>    initiator, follows the rules of constructing a Mobility Header as in
>    Section 9.2 of [RFC3775] with the exception of setting the MH Type
>    field to <IANA-TBD and the appropriate value of the Binding
>    Revocation Type field.

Section 9.2 of RFC 3775 talks about processing Mobility Headers. Perhaps 
you meant some other section from RFC 3775.

>    The mobility entity which initiates the revocation process,
>    initiator, MUST use the underlying IPsec security association that

You have already introduced the term "initiator" to refer to the 
"sending mobility node" in the first paragraph. It is repeated here.

>    When a mobility entity initiate the binding revocation process by
>    sending a Binding Revocation Indication message, the initiator MUST
>    construct the BRI message as described in Section 6.1.  In the BRI
>    message, the initiator MUST set the Sequence Number field to the next
>    sequence number available for Binding Revocation.  

Why? It can be any random number, right? It is only used for matching 
BRA messages to BRI messages. You don't normally sending a sequence of 
BRI messages to a mobile node right? Not like sending binding updates 
with increasing sequence numbers.

>    On the other hand, when the responder acknowledge the BRI message by

"On the other hand" of what? Just say "When the responder..."

> 7.2.  Receiving Binding Revocation Messages
> 
>    When receiving a Binding Revocation message, the receiving mobility
>    node MUST verify the Mobility Header as in [RFC3775].  

I think here you should mention section 9.2 of RFC 3775.

> If the packet
>    is dropped due to failing any of the Mobility Headers test check, the
>    receiving node MUST follow the processing rules as in Section 9.2 of
>    [RFC3775].  For example, it MUST send a Binding Error message with
>    the Status field set to 2 (unrecognized MH Type value) if it does not
>    support the received binding revocation message type.

The "MUST" here does not make sense. Re-word the last sentence to,

   If the receiving node does not support the Binding Revocation
   Indication message and does not recognize the new MH type, it sends
   a Binding Error message with the Status field set to 2, as described
   in [RFC3775].

>    Since some mobility entities, e.g.  LMA and MAG, are allowed to
>    receive and possibly send a BRI or a BRA for different cases, IPsec
>    mechanism will prevent any possible man in the middle reflection
>    attack.

Not sure what this means. What is IPsec is not used? You have indicated 
in a number of places in the document that there could be other mechanisms.

>    Upon receiving a packet carrying a Binding Revocation Indication, the
>    receiving mobility entity, responder, validates that the packet was
>    received protected with the underlying IPsec protection with the
>    responding mobility entity.

Here we are mandating IPsec protection for the BRI message. Is this the 
intention? If yes, a few other places need to be fixed.

>    Upon receiving a packet carrying a Binding Revocation
>    Acknowledgement, the receiving mobility entity, initiator, MUST
>    validate that Sequence Number field matches the Sequence Number of an
>    outstanding Binding Revocation Indication that was sent by the
>    initiator.  If the Sequence Number does not match any sequence number
>    of any of the outstanding BRI, the receiving node MUST ignore the
>    message but MAY log the event.

s/ignore/silently drop/

> 7.3.  Retransmission of Binding Revocation Indication
> 
>    If the sending mobility entity does not receive a Binding Revocation
>    Acknowledgement in response to the outstanding Binding Revocation
>    Indication before the MINDelayBRIs timer expires, the mobility
>    entity, e.g.  LMA, may retransmit the same BRI message up to the
>    BRIMaxRetriesNumber as defined in Section 12.  If the revoking
>    mobility entity does not receive a BRA message after the maximum
>    number of retransmits have been sent, the revoking mobility entity
>    can clean the mobile node binding cache and all resources associated
>    with this binding.  The revoking mobility entity may log the event.

Is it a simple re-transmit scheme or do we have to exponentially backoff 
for subsequent BRI messages?

>    In a race condition case, the home agent may receive a BU from the
>    mobile node while the mobile node's BCE has the revocation in
>    progress flag set, the home agent should handle this case based on
>    the reason for sending the Binding Revocation Indication message and
>    its local policy.  In this case, if the home agent accepts the BU, it
>    needs to update the mobile node BCE accordingly, e.g. removing the
>    revocation in progress flag.

Why is this needed? Shouldn't the home agent just reject the BU based on 
the fact that it in the process of revoking the binding? Why should this 
  be subject to "a local policy"? If you do want to multiple options 
here, you have to recommend a default one.

>    In a race condition case, the local mobility anchor may receive a PBU
>    from the mobile access gateway while the mobile node's proxy BCE has
>    the revocation in progress flag set, the LMA should handle this case
>    based on the reason for sending the Binding Revocation Indication
>    message and its local policy.  In this case, if the LMA accepts the
>    PBU, it needs to update the mobile node proxy BCE accordingly, e.g.
>    removing the revocation in progress flag.

Same as before. I think the LMA should just reject the PBU.

I didn't review much of the text in sections 9.1, 9.2, 10.1, 10.2, 11.1 
and 11.2. These sections have too much repetitive text

> 13.  IANA Considerations
> 
>    This document defines two new messages BRI and BRA, as described in
>    Section 6.1 and Section 6.2 by using Binding Revocation types of 1
>    and 2 of the Binding Revocation Message which is defined in in
>    Section 6 and uses a MH type <IANA-TBD>.  The new Mobility Header
>    type value needs to be assigned from the same numbering space as
>    allocated for the other Mobility Header types.

This section is not complete. Needs a re-write.

We define one new mobility header message - the binding revocation message.

Then we need to create a new namespace for the "Binding Revocation Type" 
field with the current assignments.

           0  Reserved
           1  Binding Revocation Indication Message
           2  Binding Revocation Acknowledgement Message
           All other values are reserved

Then we need to create another namespace for the "Revocation Trigger" in 
the Binding Revocation Message. I think IANA should manage this field too.

Then we need yet another namespace for the "Status" field in the BRA 
message. I think this should also be managed by IANA.

So you need to request all of these from the IANA.

Hope this helps.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 7 Mar 2009 01:23:30 -0600

Hi Vijay,

Thanks for your detailed review and comments. 
Will go through them and respond back, hopefully over the weekend.

Cheers!

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Friday, March 06, 2009 7:21 PM
> To: [email-masked]
> Cc: Julien Laganier; mext
> Subject: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
> 
> Hello,
> 
> I reviewed this document. It needs some work before it can be 
> sent to the IESG. Comments follow.
> 
> > Abstract
> > 
> The MIPv4 registration mechanism was specified in the IETF, 
> not in the networks where Mobile IPv4 has been deployed. :) I 
> think the last sentence needs to be re-worded.
> 
> We don't use "Client Mobile IPv6" in the IETF. :) And we need 
> references to RFC 3775 and 5213, since they are mentioned 
> here for the first time in this document.
> 
> > 2.2.  Terminology
> > 
> Maybe you should define the term "mobility agent" here. 
> Basically, it would be the Home Agent, LMA and the MAG. You 
> have used "mobility node" 
> throughout the document. A "mobility node" is kind if vague. 
> Suggest replacing all occurrences with "mobility agent".
> 
> hmm... Won't the mobile node delete the binding first before 
> sending the BRA message?
> 
> Again, it is always the home agent that initiates the 
> revocation mechanism. Who else can do it in DS-MIPv6?
> 
> What does the last sentence mean? Isn't the mobile node 
> required to do something when it gets a revocation message? 
> The mobile node has to find another home agent, right? How 
> can its services not be interrupted?
> 
> Why is the HoA required in a destination option? The BRA 
> message can just be sent from the CoA with no home address 
> option in it. The Home Agent just needs to match the BRA to 
> the BRI message using the sequence number field.
> 
> Can we call this oldMAG and newMAG? We have traditionally 
> used these terms in the IETF.
> 
> > 4.  Security Model
> > 
> Why require this? It is after all the MAG that created all 
> these bindings. And now the MAG wants to delete the bindings 
> it created at the LMA. So why does this alone require an 
> additional authorization step?
> 
> Is the destination port in the BRI set to the DS-MIPv6 port 
> or the source UDP port seen on the PBU from the MAG to the 
> LMA? The NAT on the path might have changed the source UDP 
> port on the PBU. So do you want the BRI to be sent to that port?
> 
> I don't understand the last one. Why is this needed? If 
> Mobile IPv6 is used, the home address would identify the 
> right binding that needs to be deleted. If MCoA is used, then 
> the BID would identify the right binding. 
> Section 9.2 of RFC 3775 talks about processing Mobility 
> Headers. Perhaps you meant some other section from RFC 3775.
> 
> You have already introduced the term "initiator" to refer to 
> the "sending mobility node" in the first paragraph. It is 
> repeated here.
> 
> Why? It can be any random number, right? It is only used for 
> matching BRA messages to BRI messages. You don't normally 
> sending a sequence of BRI messages to a mobile node right? 
> Not like sending binding updates with increasing sequence numbers.
> 
> >    On the other hand, when the responder acknowledge the 
> BRI message 
> > by
> 
> Not sure what this means. What is IPsec is not used? You have 
> indicated in a number of places in the document that there 
> could be other mechanisms.
> 
> Indication, the
> Here we are mandating IPsec protection for the BRI message. 
> Is this the intention? If yes, a few other places need to be fixed.
> 
> Is it a simple re-transmit scheme or do we have to 
> exponentially backoff for subsequent BRI messages?
> 
> Why is this needed? Shouldn't the home agent just reject the 
> BU based on the fact that it in the process of revoking the 
> binding? Why should this
>   be subject to "a local policy"? If you do want to multiple 
> options here, you have to recommend a default one.
> 
> I didn't review much of the text in sections 9.1, 9.2, 10.1, 
> 10.2, 11.1 and 11.2. These sections have too much repetitive text
> 
> > 13.  IANA Considerations
> > 
> Then we need to create another namespace for the "Revocation 
> Trigger" in the Binding Revocation Message. I think IANA 
> should manage this field too.
> 
> Then we need yet another namespace for the "Status" field in 
> the BRA message. I think this should also be managed by IANA.
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 10 Mar 2009 18:45:33 -0500

Hi Vijay,
Thanks for all the comments. Please see responses inline.
Sorry for the late reply.

Regards,
Ahmad

> sent to the IESG. Comments follow.
[Ahmad]
Okay, no problem, these comments improve readability of the draft.  
we will go over them and all others and address them before it is sent
to IESG.

>    mobile node's mobility session and release the associated 

[Ahmad]
Looks good. Thx.

> think the last sentence needs to be re-worded.

[Ahmad]
What about the following:

   In the case of Mobile IPv6 and for administrative reason, sometimes
   it becomes necessary to inform the mobile node that its registration
   has been revoked and the mobile node is no longer able to receive IP
   mobility service using its Home Address.  A similar Mobile IPv4
   registration revocation mechanism [RFC3543] has been specified by
   IETF for providing a revocation mechanism for sessions that were
   established using Mobile IPv4 registration [RFC3344].

> here for the first time in this document.

[Ahmad]
What about the following text:

   This document specifies a binding revocation mechanism that can be
   used to revoke a mobile node's mobility session(s). The same
   mechanism can be used to revoke bindings created using Mobile IPv6
   [RFC3775] or any of its extensions, e.g.  Proxy Mobile IPv6
   [RFC5213].

> Suggest replacing all occurrences with "mobility agent".

[Ahmad]
Good idea. 

I will replace the mobility node by mobility agent where it is
applicable. However, I do not see the need for having another definition
for the mobility agent term.

>    In the case of Mobile IPv6, the revocation procedure is 

[Ahmad]
Okay, please see the comment below.

> hmm... Won't the mobile node delete the binding first before 

[Ahmad]
It could, but this is implementation specific. Some implementation may
send BRA at the same time it starts the process of eliminating the
session binding or even before. IMO, We should not specify a specific
sequence of events. But, what about rewording the whole paragraph as
follows:

   In the case of Mobile IPv6, if the home network decides to terminate
   the service of the mobile node, the home agent sends a Binding
   Revocation Indication (BRI) message to the mobile node.  The home
   agent includes the HoA in the type 2 routing header as specified in
   [RFC3775] to indicate the impacted mobile node binding.  When the
   mobile node receives a BRI message with its HoA included and the
   Acknowledge (A) bit is set, the mobile node responds by sending a
   Binding Revocation Acknowledgement (BRA) message.

> revocation mechanism. Who else can do it in DS-MIPv6?

[Ahmad]
Will fix it as above.

> I don't know of any other option that carry the IPv4 home address.
[Ahmad]
Sure. Done.

> Again, the mobile node would delete the binding first, I guess.

[Ahmad]
Similar to the response above.

> s/Client MIPv6/Mobile IPv6/
[Ahmad]
Sure, will take it as a global comment.
 
> can its services not be interrupted?

[Ahmad]
Hmmm.. I guess that what the sentence says. "to recover from its
interrupted mobile IPv6 services"
So, I guess we are on the same page.

> the BRI message using the sequence number field.

[Ahmad]
This was based a good discussion and comment from Christian back in
Sept. 2008 on rev 00. Since the BRI and the BRA use the same IPsec SA
that is used for the BU/BA, then we need to follow the same mechanism
when sending BRI and BRA.

> BTW, in figure 2, there is no HoA destination option in the 

[Ahmad]
Will fix it accordingly.

>    mobile node home address.

[Ahmad]
Thx. Done.

> s/In the case when/In case/

[Ahmad]
Ok.

>    sends a BRI message to the mobile node with the corresponding BID

[Ahmad]
Is the idea NOT to mention the inclusion of HoA in Type 2 header as it
is understood or there is another reason.

>    corresponding Binding ID options in the same BRI message.
[Ahmad]
Ok.

>    used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4].

[Ahmad]
Sure, what about the following:

"
   ............ The binding revocation mechanism is generic enough that
   can be used for all Proxy Mobile IPv6 scenarios that follow [RFC5213]
   and [ID-PMIP6-IPv4] specifications.
"

> >    MAG identify the respected binding and if the (A) bit was set in 

[Ahmad]
Ok.

> used these terms in the IETF.

[Ahmad]
No problem. Fixed.

> There are few places where this needs to be replaced.

[Ahmad]
Thx. Done.
 
> additional authorization step?

[Ahmad]
Actually, the intention was for the case when the (G) bit set and the R.
T. is set to "Per-Peer policy", which means all binding between the MAG
and the LMA to be deleted. Additionally, I see your point, but something
could have happened to the MAG between the time it created all of these
session and time of terminating them. Even in the case of creating a
single binding, RFC5213 left the door open for the LMA to make sure that
the MAG is authorized for sending the PBU on behalf of the mobile node.
This case is much more severe and impact all bindings and I believe it
worth having this validation.

> port on the PBU. So do you want the BRI to be sent to that port?

[Ahmad]
BRI should use the source port of the PBU which is saved in the BCE.

> So what is the last one used for?

[Ahmad]
This was discussed during the wg LC. The point here is the following:
In case the Global revocation, currently the LMA does not, for example,
keep track of the MAG ID or any parameter which is shared among all of
these bindings. However, if the Care-of-Address is included, then the
LMA will revoke all of the bindings that share this Care-of-Address. If
the MAG uses more than one pCoA for the mobility sessions that reside on
the LMA, the MAG needs to include each pCoA in a separate Alternate
Care-of Address option.

> Headers. Perhaps you meant some other section from RFC 3775.

[Ahmad]
What about the following updated text:

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

> the "sending mobility node" in the first paragraph. It is 

[Ahmad]
sure; removed.

> Not like sending binding updates with increasing sequence numbers.
[Ahmad]
That what the "next sequence number" means. 
We did not say that this sequence number is monotonic, for example.
 
> "On the other hand" of what? Just say "When the responder..."
[Ahmad]
Okay :) replaced by However, ....

> I think here you should mention section 9.2 of RFC 3775.

[Ahmad]
Ok.

>    a Binding Error message with the Status field set to 2, as 
[Ahmad]
Ok.

> could be other mechanisms.

[Ahmad]
What this means is: If IPsec is used, then there is no room for
reflection attack.
Text modified as follows:

"
   Since some mobility entities, e.g.  LMA and MAG, are allowed to
   receive and possibly send a BRI or a BRA for different cases,
   therefore, if IPsec is used to secure signaling between the MAG and
   the LMA, it prevents any possible man in the middle reflection
   attack.
"

> Is this the intention? If yes, a few other places need to be fixed.

[Ahmad]
I do not think Binding Revocation should mandate more protection than
what is already mandated in PMIPv6 or MIPv6. So I guess we can rephrase
the above as follows:

   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 responding mobility entity and used during
   the registration signaling phase, e.g., IPsec SA.

Actually there is another instance under sending section which I also
fixed similarly, as follows:

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

> >    message but MAY log the event.

[Ahmad]
Sure, will use silently discard.

> exponentially backoff for subsequent BRI messages?

[Ahmad]
It should be a simple re-transmit scheme. 
I guess it does not have the characteristics of BU/BA as it does not
happen that frequent.

> options here, you have to recommend a default one.

[Ahmad]
I guess this text was added to address the case when the HA sends a BRI
message to the MN when the mobile node just made a handoff and sent a BU
with a new care-of address. IMO, the HA handling should be based on the
reason for sending the BRI. However, if we allow the HA to reject the
BU, which Status Code should we use?

> Same as before. I think the LMA should just reject the PBU.
[Ahmad]
See the above comment?

> 10.2, 11.1 and 11.2. These sections have too much repetitive text

[Ahmad]
Thx. for all the comments. 
If you have any specific ones on these sections, please let us know so
we can address them.

> This section is not complete. Needs a re-write.

[Ahmad]
OK.
Please see a re-write for the whole section below.

>            All other values are reserved

[Ahmad]
I do not think we need to reserve a name space for this. 
In case that is needed in the future, we can do that then.

> So you need to request all of these from the IANA.

{Ahmad]
What about the following updated IANA section?

"
13.  IANA Considerations

   This document defines a new Binding Revocation Message using a new
   Mobility Header Type <IANA-TBD>, as described in Section 6.  The new
   Mobility Header type value needs to be assigned from the same
   numbering space as allocated for the other Mobility Header types.

   In addition, this document also creates a new namespace for the
   Binding Revocation Trigger Field defined in Binding Revocation
   Indication message as described in Section 6.1, and are the
   following:

       0  Reserved
       1  Unspecified
       2  Administrative Reason
       3  Inter-MAG Handoff - same Access Types
       4  Inter-MAG Handoff - different Access Types
       5  Inter-MAG - Unknown Handoff
       6  Per-Peer Policy
       7  Revoking Node Local Policy
       8  User Initiated Session(s) Termination
       9  Access Network Session(s) Termination
       10  IPv4 HoA Lease Expires
       11  Possible Out-of Sync BCE State
       250-255 Reserved For Testing Purposes only
       All other values are Reserved

   Future values of the Option Type can be allocated using Standards
   Action or IESG Approval [RFC2434].

   Furthermore, this document creates a third new name space "Status
   Code" for the Status field in the Binding Revocation Acknowledgement
   message.  The current values are described in Section 6.2, and are
   the following:

       0  success
       1  partial success
       128  Binding Does NOT Exist
       129  IPv4 HoA Binding Does NOT Exist
       130  IPv4 Home Address Option Required
       131  Global Revocation NOT Authorized
       132  CAN NOT Identify Binding
       133  Revocation Failed, MN is Attached

   Future values of the Status field can be allocated using Standards
   Action or IESG Approval [RFC2434].

   All fields labeled "Reserved" are only to be assigned through
   Standards Action or IESG Approval.
"

> Hope this helps.

[Ahmad]
Of course. thanks!

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 10 Mar 2009 23:22:58 -0800

Hi Ahmad,

>    established using Mobile IPv4 registration [RFC3344].

Looks ok.

Ok.

> sequence of events.

That does not make sense. You always perform the necessary action and then
send a response message. You don't send a response first. In addition you
have the following status values.

          130  IPv4 HoA Option Required

How can you send these status values without first attempting delete the
binding? :)

> So, I guess we are on the same page.

Ok, but what is meant by "... dynamically allow the user ..."?

> when sending BRI and BRA.

That's a good point. Fine with me.

> is understood or there is another reason.

You have already mentioned earlier that the routing header needs to be
included whenever a home agent sends a BRI message to a mobile node. No need
to repeat it. What is crucial in the above paragraph is to mention the
inclusion of the BID option, since this is specific to an MCoA revocation.

> and the LMA to be deleted.

The above paragraph says nothing about "per-peer policy". It says for any
bulk termination, the LMA must perform this additional authorization check.

> Additionally, I see your point, but something
> session and time of terminating them.

Like what?

> Even in the case of creating a

I don't agree with this analogy. When the MAG creates a proxy binding cache
entry for the mobile node, it is altering the routing for the mobile node.
It is directing the packets to be tunneled to the MAG. This is not the same
as the MAG deleting the binding it created.

> worth having this validation.

Sorry, I don't see why this authorization check is required. I suggest
removing it.

> BRI should use the source port of the PBU which is saved in the BCE.

Ok. Please mention this explicitly.

> the LMA, the MAG needs to include each pCoA in a separate Alternate

You are talking about bulk revocation from the MAG. But the above section is
about valid options in a BRI message. Why would LMA include this? How does
including the altCoA option help the MAG when it receives the BRI message?
Am I missing something?

> We did not say that this sequence number is monotonic, for example.

Hmm... It can even pick a less value than the one used in the last BRI
message. So I don't follow. The text in the above paragraph should just say,
it is a random number used only for matching the BRA message to the BRI
message.

>    the LMA, it prevents any possible man in the middle reflection

Ok, good.

Ok.

Ok.

> BU, which Status Code should we use?

If you are using Mobile IPv6 and the home agent has already decided to
revoke a mobile node's binding, why should it accept a BU from the new CoA?
It should just reject the BU. For the status code, you can perhaps use
"Administrative Reason".
 
>> Same as before. I think the LMA should just reject the PBU.

I think the LMA should reject the PBU. Lets not complicate things by
bringing in this new "local policy" concept.

> In case that is needed in the future, we can do that then.

Why not create the registry now and say new values can only be assigned by
"Standards Action"? This would create a bar sufficiently high to create new
type values. Having this hard coded now in the spec and creating a registry
later on is much harder, IMO.

>    Standards Action or IESG Approval.

Looks good.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 11 Mar 2009 12:14:56 -0500

Hi Vijay,

> draft-ietf-mext-binding-revocation-03.txt
> 
> Hi Ahmad,
> 
> >> hmm... Won't the mobile node delete the binding first 
> before sending 
> >> the BRA message?
> > 
> > [Ahmad]
> That does not make sense. You always perform the necessary 
> action and then send a response message. You don't send a 
> response first. In addition you have the following status values.
> 
> How can you send these status values without first attempting 
> delete the binding? :)

[Ahmad]
IMO, If we recommend one way of doing all of this, it will be
inefficient and I would recommend that we leave it up-to the
implementation to address each case accordingly. For example:

1. In the case of "Global Authorization Not Authorized", there is no
need even to find which bindings are affected.
2. In some cases, the status code does not change anything from the
expected behavior of the initiator point view.
3. I believe where it is necessary for recommending what the receiving
node SHOULD do, the draft should capture the text at the appropriate
place, for example:

Under section 11.1, it says:

   o  If the IPv4 HoA Binding Only (V) bit is set in the received BRI
      message, the MN MUST verify that there is an IPv4 Home Address
      option in the received BRI and the IPv4 address included in the
      IPv4 Home Address option is the same as its IPv4 HoA that is
      assigned to the mobile node.  If this verification is successful,
      the MN MUST consider this BRI as an indication to release the
      mobile node IPv4 HoA binding ONLY to its current Care-of Address.
...
...

It continues to say:

      Consequently, the MN MUST continue to maintain its IPv6 HoA
      binding to the current CoA as part of the mobile node binding in
      the BUL entry and release all resources associated with the MN
      IPv4 HoA binding.  In this case, the MN MUST send a BRA message
      with the status field is set to success.  On the other hand, if
      the IPv4 Home Address Option was NOT included in the received BRI
      with the (V) bit set, the MN SHOULD send a BRA message with the
      status field set to "IPv4 Home Address Option Required".
      Additionally, if the IPv4 HoA received in the IPv4 Home Address
      Option is NOT the one assigned to the MN, the MN SHOULD send a BRA
      with the status field set to "IPv4 HoA Binding Does NOT Exist".

So, IMO, the text here is normative which covers what you want to have.
However, adding text at the pointed place would suggest a global
restriction of sequence of events in an area that is not normative :)
Please take a look at sections 9.2.1, 10.1.1., and 11.1. they also
captures what the LMA, MAG, and MN should do when receiving a BRI
message.

> required to 
> >> do something when it gets a revocation message?
> >> The mobile node has to find another home agent, right? How can its 
> >> services not be interrupted?
> > 
> > [Ahmad]

[Ahmad]
The intention is: by using the Binding Revocation mechanism, it is
considered a dynamic mechanism compares to if we let the mobile node to
figure out that on its own that it lost mobility service after trying to
connect to the internet and then timing out. Any better wording, will be
happy to include.

> You have already mentioned earlier that the routing header 
> needs to be included whenever a home agent sends a BRI 
> message to a mobile node. No need to repeat it. What is 
> crucial in the above paragraph is to mention the inclusion of 
> the BID option, since this is specific to an MCoA revocation.

[Ahmad]
Sure, will update accordingly.

> >> bindings. And now the MAG wants to delete the bindings it 
> created at 
> >> the LMA. So why does this alone require an additional 
> authorization 
> >> step?
> > 
> > [Ahmad]
> > T. is set to "Per-Peer policy", which means all binding between the 
> > MAG and the LMA to be deleted.
> 
> The above paragraph says nothing about "per-peer policy". It 
> says for any bulk termination, the LMA must perform this 
> additional authorization check.
[Ahmad]

   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.

> 
> > Additionally, I see your point, but something could have 
> happened to 
> > the MAG between the time it created all of these session 
> and time of 
> > terminating them.
> 
> Like what?

[Ahmad]
The same reason which was behind allowing the LMA to validate that the
MAG is allowed to send the PBU and the MN is present at the access side
associated with the MAG. I do not see any problem to demote "MUST" to
"SHOULD", would that address your concern?

> > single binding, RFC5213 left the door open for the LMA to make sure 
> > that the MAG is authorized for sending the PBU on behalf of 
> the mobile node.
> 
> I don't agree with this analogy. When the MAG creates a proxy 
> binding cache entry for the mobile node, it is altering the 
> routing for the mobile node.

[Ahmad]
And when it send a bulk revocation it does not alter the routing of a
BUNCH of MNs?

> It is directing the packets to be tunneled to the MAG. This 
> is not the same as the MAG deleting the binding it created.
> 
> Sorry, I don't see why this authorization check is required. 
> I suggest removing it.

[Ahmad]
This has been discussed several times before on the ml already. Would
the demotion above address the concern? 

> >> source UDP port seen on the PBU from the MAG to the LMA? 
> The NAT on 
> >> the path might have changed the source UDP port on the 
> PBU. So do you 
> >> want the BRI to be sent to that port?
> > 
> > [Ahmad]

[Ahmad]
Sure, what about the following text:

   In some deployments, the network between the MAG and the LMA may only
   support IPv4 transport.  In this case, the Binding Revocation
   messages (BRI and BRA) are tunneled over IPv4.  If the Proxy Binding
   Update and Proxy Binding Acknowledgment messages are sent using UDP
   encapsulation to traverse NATs, then the Binding Revocation messages
   are sent using the same UDP encapsulation.  The same UDP port that
   was used for exchanging the Proxy Binding Update and Proxy Binding
   Acknowledgement messages will also be used when transporting Binding
   Revocation messages over IPv4 using UDP encapsulation.  In other
   words, the destination UDP port of the BRI message MUST be set to the
   source UDP port of the latest successfully processed Proxy Binding
   Update message which is already saved in the mobile node BCE.  For
   more details on tunneling Proxy Mobile IPv6 signaling messages over
   IPv4, see [ID-PMIP6-IPv4].

> Mobile IPv6 
> >> is used, the home address would identify the right binding 
> that needs 
> >> to be deleted. If MCoA is used, then the BID would 
> identify the right 
> >> binding.
> >> If PMIPv6 is used, the home network prefix option, MN ID 
> option and 
> >> the
> > In case the Global revocation, currently the LMA does not, for 
> > example, keep track of the MAG ID or any parameter which is shared 
> > among all of these bindings. However, if the Care-of-Address is 
> > included, then the LMA will revoke all of the bindings that 
> share this 
> > Care-of-Address. If the MAG uses more than one pCoA for the 
> mobility 
> > sessions that reside on the LMA, the MAG needs to include 
> each pCoA in 
> > a separate Alternate Care-of Address option.
> 
> You are talking about bulk revocation from the MAG. But the 
> above section is about valid options in a BRI message. Why 
> would LMA include this? How does including the altCoA option 
> help the MAG when it receives the BRI message?
> Am I missing something?

[Ahmad]
If it is a valid case when the MAG sends a bulk revocation, does not
that mean that it is a valid option in BRI message?

> >> BRA messages to BRI messages. You don't normally sending a 
> sequence 
> >> of BRI messages to a mobile node right?
> Hmm... It can even pick a less value than the one used in the 
> last BRI message. 
[Ahmad]
Where in the above text it says that is NOT possible?

> So I don't follow. The text in the above 
> paragraph should just say, it is a random number used only 
> for matching the BRA message to the BRI message.
> 

[Ahmad]
That is well understood and I do not see anything in the above text
which conflicts what you just said. 
For example: Here is the definition of the sequence number field:
Under BRI, it says:

   Sequence #

      A 16-bit unsigned integer used by the sending mobility node to
      match a returned Binding Revocation Acknowledgement with this
      Binding Revocation Indication.

Under BRA, it says:

   Sequence #

      The sequence number in the Binding Revocation Acknowledgement is
      copied from the Sequence Number field in the Binding Revocation
      Indication.  It is used by the revoking mobility entity, e.g.  HA,
      LMA, in matching this Binding Revocation Acknowledgement with the
      outstanding BRI.

Additionally, We can modify the sequence number text under BRI to say it
could be a random number, like the following:

Under BRI, it says:

   Sequence #

      A 16-bit unsigned integer used by the sending mobility node to
      match a returned Binding Revocation Acknowledgement with this
      Binding Revocation Indication. It could be a random number.

Would that be ok?

> >> Why is this needed? Shouldn't the home agent just reject 
> the BU based 
> >> on the fact that it in the process of revoking the binding? Why 
> >> should this
> > I guess this text was added to address the case when the HA sends a 
> > BRI message to the MN when the mobile node just made a handoff and 
> > sent a BU with a new care-of address. IMO, the HA handling 
> should be 
> > based on the reason for sending the BRI. However, if we 
> allow the HA 
> > to reject the BU, which Status Code should we use?
> 
> If you are using Mobile IPv6 and the home agent has already 
> decided to revoke a mobile node's binding, why should it 
> accept a BU from the new CoA?
> It should just reject the BU. For the status code, you can 
> perhaps use "Administrative Reason".

[Ahmad]
I thought about that BUT I do not think that is a good option. Because,
if the MN receives a BA with Administrative reason, the MN MAY get
confused and stop trying to connect. IMO, leaving the existing text
probably safer, However, there is another option, MAY be the LMA would
ignore the BU until it receives BRA or timeout. That would guarantee
that the MN will continue to try to connect. The problem here, is in the
case of handoff, it may cause some unnecessary delay. 

-OR-

If possible, we can define a new BA Status Code?

> I think the LMA should reject the PBU. Lets not complicate 
> things by bringing in this new "local policy" concept.

[Ahmad]
Please see above.

> Why not create the registry now and say new values can only 
> be assigned by "Standards Action"? This would create a bar 
> sufficiently high to create new type values. Having this hard 
> coded now in the spec and creating a registry later on is 
> much harder, IMO.

[Ahmad]
Sure we can add that, what about the following:

   This document also creates a new name space "Binding Revocation Type"
   which indicates the type of the binding revocation message.  The
   current binding revocation message types are described in Section 6.1
   and Section 6.2, and are the following:

       0  Reserved
       1  Binding Revocation Indication
       2  Binding Revocation Acknowledgement
       All other values are reserved

   Future values of the Binding Revocation Type can be allocated using
   Standards Action or IESG Approval [RFC2434].

Again, Many thanks Vijay for your review and comments!

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Mar 2009 12:53:21 -0800

> implementation to address each case accordingly. For example:

hmm... let me try once more. I don't think this is so complicated. When 
you receive a message (BRI in this case), you try to execute what the 
message told you to do (revoking a binding in this case), and then send 
a response with the status in it (BRA, in this case). Why would you send 
a response first and then try to remove the binding?

> restriction of sequence of events in an area that is not normative :)

It is not about restricting what the recipient of the BRI message can 
do. The only possible sequence of events, is to first process the 
message, attempt to the remove the binding and then respond. There is no 
other option. :)

>    authorized to invoke Global revocation.

Now comes the additional question. What is special about "Per-Peer 
Policy"? The MAG should still be allowed to revoke the bindings it 
created. Why require an additional authorization step?

> associated with the MAG. 

In your reply you said something about "something could have happened to 
the MAG". What is that? What you wrote above is not a response to that. 
As I said in the earlier email, the analogy is not correct.

> I do not see any problem to demote "MUST" to

Well, I would still like to get rid of this additional authorization step.

> And when it send a bulk revocation it does not alter the routing of a

hmm... the MAG created the bindings, so it can delete them. The MAG can 
always send a de-registration PBU for each of those bindings without an 
extra authorization step. So not clear why it is required for binding 
revocation.

>    IPv4, see [ID-PMIP6-IPv4].

Sounds good.

> that mean that it is a valid option in BRI message?

In that case, I think we should explicitly say that this is valid only 
in a BRI sent by the MAG for bulk registration.

>       Binding Revocation Indication. It could be a random number.

Excellent. This works for me.

> If possible, we can define a new BA Status Code?

How about using "Insufficient Resources", instead? This tells the mobile 
node that the current home agent is not usable and it should find 
another one.

Looks good.

> Again, Many thanks Vijay for your review and comments!

No problem.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 15:43:23 -0500

> Subject: Re: [MEXT] Review of 
> action and 
> >> then send a response message. You don't send a response first. In 
> >> addition you have the following status values.
> >>
> >> How can you send these status values without first 
> attempting delete 
> >> the binding? :)
> > 
> > [Ahmad]
> hmm... let me try once more. 
[Ahmad]
Vijay,

You may be frustrated with this but me too. 
I am trying to address your comments as best I could. All of your
comments are basically opinions that open for interpretations. Although,
I appreciate the comments because they improve the readability of the
draft, however, if the issue is NOT TECHNICALLY wrong, then, I respect
your view but, on the other hand, these issues have been discussed
before and agreed upon and the wg LC has been concluded. It is very
frustrating to keep arguing the same points that we have addressed on
the ml long time ago. That requires a lot of time that sometime is not
available. 

However, let me try to address your concern one more time.

> I don't think this is so 
> complicated. When you receive a message (BRI in this case), 
> you try to execute what the message told you to do (revoking 
> a binding in this case), and then send a response with the 
> status in it (BRA, in this case). Why would you send a 
> response first and then try to remove the binding?

[Ahmad]
>From implementation prospective, implementers want to have the freedom
of the sequence of events. The END result is the same. I do NOT
understand what else I need to say.

If that is NOT clear, then nothing will make this clearer.

A MN may receive BRI and responds with a BRA and then delete the entry
in the BUL. What IS WRONG with that?
There is NO NEED to specify the sequence of events globally. However, if
you find a specific case that requires a specific sequence of events and
IS NOT documented, we will be very happy to adjust.

Let me say the following: If A MN receives a BRI and the BRI have R.T.
value of "Administrative Reason" and the MN responds back immediately
with BRA with Status SUCCESS. Even if the MN maintained its entry in the
BUL for a while before deleting it. WHAT IS THE PROBLEM?

As long as the MN stops completely from using the respected HoA binding,
I do not see any problem. 

> It is not about restricting what the recipient of the BRI 
> message can do. The only possible sequence of events, is to 
> first process the message, attempt to the remove the binding 
> and then respond. There is no other option. :)

[Ahmad]
Please see above comment:)

> >> The above paragraph says nothing about "per-peer policy". 
> It says for 
> >> any bulk termination, the LMA must perform this additional 
> >> authorization check.
> > [Ahmad]
> Now comes the additional question. What is special about 
> "Per-Peer Policy"? The MAG should still be allowed to revoke 
> the bindings it created. Why require an additional authorization step?

[Ahmad]
Please see the responses below.

> > MAG is allowed to send the PBU and the MN is present at the access 
> > side associated with the MAG.
> 
> In your reply you said something about "something could have 
> happened to the MAG". What is that? What you wrote above is 
> not a response to that. 
[Ahmad]
Please see the responses below.

> 
> > I do not see any problem to demote "MUST" to "SHOULD", would that 
> > address your concern?
> 

[Ahmad]
Sure, that is your view, but please see the response below.

> >> I don't agree with this analogy. When the MAG creates a 
> proxy binding 
> >> cache entry for the mobile node, it is altering the 
> routing for the 
> >> mobile node.
> > 
> > [Ahmad]
> hmm... the MAG created the bindings, so it can delete them. 
> The MAG can always send a de-registration PBU for each of 
> those bindings without an extra authorization step. So not 
> clear why it is required for binding revocation.

[Ahmad]
Okay. I remember very well that a similar topic while PMIPv6 is
developed generated a lot of heated discussion. In any case, let me say
the following:

1. In PMIPv6 [RFC3215], it says the following under section 4:

   The Mobile IPv6 specification [RFC3775] requires the home agent to
   prevent a mobile node from creating security associations or creating
   binding cache entries for another mobile node's home address.  In the
   protocol described in this document, the mobile node is not involved
   in creating security associations for protecting the signaling
   messages or sending binding updates.  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.

2. If per PMIPv6 specification, the LMA needs to make sure that the MAG
is always authorized to send a PBU message on behalf of any mobile node
at any time, why it is NOT acceptable, if the MAG sends a BRI which
requires deleting all Bindings between the LMA-MAG Pair, to require the
LMA to check if the MAG is authorized to do such action.

[BTW: This has been in the draft since inception and has been discussed
many times and was approved during the wg LC]

3. If there is a Peer Authorization Database already as per PMIPv6, why
it is TOO difficult to add the authorization for the Global Revocation.

4. You keep saying that the MAG created these bindings and it should
have the right to delete them. Just a minor correction, not necessarily
CREATED by the same MAG, it could just have been updated after Handover;
the analogy here is like some one who have a pistol and the other has
WMD [:-)))]. It is MUCH easier for people to get licensed for carrying a
pistol, BUT when it come of WMD, a NATION could be occupied and wiped
out man:) NOT only that BUT it may cost billions of Dollars!

Hope this makes it a little clearer. 

> >> You are talking about bulk revocation from the MAG. But the above 
> >> section is about valid options in a BRI message. Why would LMA 
> >> include this? How does including the altCoA option help 
> the MAG when 
> >> it receives the BRI message?
> >> Am I missing something?
> > 
> > [Ahmad]
> In that case, I think we should explicitly say that this is 
> valid only in a BRI sent by the MAG for bulk registration.
> 
> >> So I don't follow. The text in the above paragraph should 
> just say, 
> >> it is a random number used only for matching the BRA 
> message to the 
> >> BRI message.
> >>
> > 
> > [Ahmad]
> > Additionally, We can modify the sequence number text under 
> BRI to say 
> > it could be a random number, like the following:
> > 
> > Under BRI, it says:
> > 
> >    Sequence #
> > 

[Ahmad]
Oh.. Thanks GOD! :)
> >> If you are using Mobile IPv6 and the home agent has 
> already decided 
> >> to revoke a mobile node's binding, why should it accept a 
> BU from the 
> >> new CoA?
> >> It should just reject the BU. For the status code, you can perhaps 
> >> use "Administrative Reason".
> > 
> > [Ahmad]
> > I thought about that BUT I do not think that is a good option. 
> > Because, if the MN receives a BA with Administrative reason, the MN 
> > MAY get confused and stop trying to connect. IMO, leaving 
> the existing 
> > text probably safer, However, there is another option, MAY 
> be the LMA 
> > would ignore the BU until it receives BRA or timeout. That would 
> > guarantee that the MN will continue to try to connect. The problem 
> > here, is in the case of handoff, it may cause some 
> unnecessary delay.
> > 
> > -OR-
> > 
> How about using "Insufficient Resources", instead? This tells 
> the mobile node that the current home agent is not usable and 
> it should find another one.

[Ahmad]
Okay, since the wg agreed to the current behaviors and the proposed one
is quite very different from the one captured in the draft, I will send
a separate email and ask if the group agrees to the change. If there is
a consensus for the change, then we can adopt it.

> 
> >> Why not create the registry now and say new values can only be 
> >> assigned by "Standards Action"? This would create a bar 
> sufficiently 
> >> high to create new type values. Having this hard coded now in the 
> >> spec and creating a registry later on is much harder, IMO.
> > 
> > [Ahmad]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Mar 2009 14:01:45 -0800

Hi Ahmad,

> understand what else I need to say.

The end result would not be same, if the entity that receives the BRI 
messages responds with a BRA message without first attempting to delete 
the binding. You can't have a freedom of sequence of events on this. :)

> in the BUL. What IS WRONG with that?

You have status codes that don't always say, "Binding removed". So you 
have to send the BRA message after trying to deleting the binding.

> LMA to check if the MAG is authorized to do such action.

Ahmad, if there is a security threat by a MAG deleting the binding it 
created, let me know. Otherwise the authorization check is unnecessary. 
Please remove it.

> many times and was approved during the wg LC]

Has it been discussed specifically?

> it is TOO difficult to add the authorization for the Global Revocation.

Are you talking about IPsec PAD?

> a consensus for the change, then we can adopt it.

Ok, please do so.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 16:37:21 -0500

Hi Vijay,

> 
> Ahmad, if there is a security threat by a MAG deleting the 
> binding it created, let me know. Otherwise the authorization 
> check is unnecessary. 
> Please remove it.

[Ahmad]
The simple answer is yes. IMO, compromised MAG is applicable here as it
was applicable in PMIPv6.
The problem with Global revocation is: the consequences is much more
sever. One single message impact all bindings between the MAG and the
LMA. Adding this authorization check, is NOT a huge overhead. It ensures
that this MAG is authorized to participate in such activity, which MAY
NOT happen that frequently anyway. Also, it gives LMA the freedom  to
NOT allow some MAG(s) to do such activity.

As an example: let us assume that MAG1 will send a Global Revocation at
time (t1) and MNx will attach at time (t1+ 30 seconds). Why it is
acceptable for the LMA to make sure that the MAG1 is authorized to send
a PBU on behalf on MNx while it is not needed to validate that it is
authorized to delete 10k sessions (for example) in a single message.

> 
> > [BTW: This has been in the draft since inception and has been 
> > discussed many times and was approved during the wg LC]
> 

[Ahmad]
Yes. We did. In several occasions. 
Please check exchanges with Domagoj, Patrick, and others.

> 
> > 3. If there is a Peer Authorization Database already as per PMIPv6, 
> > why it is TOO difficult to add the authorization for the 
> Global Revocation.
> 

[Ahmad]
That could be used too. I do not see any problem with that.

> >> How about using "Insufficient Resources", instead? This tells the 
> >> mobile node that the current home agent is not usable and 
> it should 
> >> find another one.
> > 
> > [Ahmad]
> > Okay, since the wg agreed to the current behaviors and the proposed 
> > one is quite very different from the one captured in the 
> draft, I will 
> > send a separate email and ask if the group agrees to the change. If 
> > there is a consensus for the change, then we can adopt it.
> 
> Ok, please do so.
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Mar 2009 14:58:26 -0800

> authorized to delete 10k sessions (for example) in a single message.

This is a wrong analogy. Currently RFC 5213 does not require the LMA to 
perform an extra authorization check when deleting a binding when it 
receives a de-registration PBU from the LMA. So why require the 
authorization check for bulk revocation? It is the MAG that created the 
bindings.

In addition, the authorization check that is described in 
draft-ietf-mext-binding-revocation-03.txt seems to be saying that the 
LMA must check if the MAG is authorized to do bulk revocation. Not about 
  the MAG being authorized to modify the binding related to mobile node 
session. Why do you want the LMA to maintain a list of MAGs that are 
authorized for bulk revocation? How is this list configured on the LMA?

> Please check exchanges with Domagoj, Patrick, and others.

I couldn't find anything on this. Can you please give me a pointer?

> That could be used too. I do not see any problem with that.

See section 4.4.3 of RFC 4301 for the PAD definition. How can this be 
used by the LMA to check if the MAG is authorized for bulk revocation?

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 17:38:27 -0500

> > 
> > [Ahmad]
> > The simple answer is yes. IMO, compromised MAG is 
> applicable here as 
> > it was applicable in PMIPv6.
> > LMA. Adding this authorization check, is NOT a huge overhead. It 
> > ensures that this MAG is authorized to participate in such 
> activity, 
> > which MAY NOT happen that frequently anyway. Also, it gives LMA the 
> > freedom  to NOT allow some MAG(s) to do such activity.
> > 
> > As an example: let us assume that MAG1 will send a Global 
> Revocation 
> > at time (t1) and MNx will attach at time (t1+ 30 seconds). 
> Why it is 
> > acceptable for the LMA to make sure that the MAG1 is authorized to 
> > send a PBU on behalf on MNx while it is not needed to 
> validate that it 
> > is authorized to delete 10k sessions (for example) in a 
> single message.
> 
> This is a wrong analogy. Currently RFC 5213 does not require 
> the LMA to perform an extra authorization check when deleting 
> a binding when it receives a de-registration PBU from the 
> LMA. So why require the authorization check for bulk 
> revocation? It is the MAG that created the bindings.

[Ahmad]
That is understood. Also, single revocation does not require any
authorization.
Probably the critical word here is "Global". 

> draft-ietf-mext-binding-revocation-03.txt seems to be saying 
> that the LMA must check if the MAG is authorized to do bulk 
> revocation. Not about
>   the MAG being authorized to modify the binding related to 
> mobile node session. Why do you want the LMA to maintain a 
> list of MAGs that are authorized for bulk revocation? How is 
> this list configured on the LMA?
> 
> See section 4.4.3 of RFC 4301 for the PAD definition. How can 
> this be used by the LMA to check if the MAG is authorized for 
> bulk revocation?
> 
> Vijay
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 17:49:19 -0500

Hello Vijay,

There have been consensus on the ml for the following issues that you
disagree with and I strongly believe that is NOT a good practice to keep
opening issues that have been addressed, consensus on them have been
reached, and closed. For the simple reason, those who accepted these
issues as resolved, probably have implemented them already. Any change
which is NOT related to a clear technical issue, should not be granted,
IMHO.

Therefore, I am yielding to the Chairs to make a decision on the
following issues. I also copied Netlmm wg.

ISSUE No. 1:
============
In the case of MAG's initiated Global revocation, is authorization of
the MAG by the LMA is Needed or NOT.

This has been in the draft since inception and discussed many times and
agreed upon, however, it seems that Vijay disagree and finds that a huge
implementation overhead.

ISSUE N. 2:
=============
The draft currently is written with the following in mind:

When the receiving node receives a BRI message, It is NOT necessarily
that the receiving node holds the BRI until it does the following:

i. Allocate all the BCE(s).
ii. Delete all the BCE(s).
iii. Send the BRA.

However, In every applicable scenario which requires the receiving node
to follow the above sequence, it is CLEARLY documented. The whole idea
is: specifying and mandating the above sequence GLOBALLY means that we
are specifying how this needs to be impregnated rather than define the
functionality where the end result is the same; I already used the
following examples but it seems they are not convincing to Vijay:

I. When the MN receives a BRI with R.T. is set to "Administrative
Reason", the MN could respond back with BRA status success and then
delete its binding from the BUL. As long as the MN does not use that HoA
binding, WHY in the WORLD this is a PROBLEM?

II. Global Revocation: Since this is allowed currently, if the MAG sends
a Global revocation which impacts 20k sessions, for examples, WHY the
LMA needs to hold sending BRA until it deletes all resources associated
with these 20k sessions. An implementation could do that. Nothing WRONG
with that BUT what is WRONG if another implementation sends that BRA and
then executes all the deletion. 

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, March 12, 2009 5:58 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]; Julien 
> Laganier; mext; Sri Gundavelli
> binding it

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Mar 2009 16:47:24 -0800

Hi Ahmad,

Ahmad Muhanna wrote:
> issues as resolved, probably have implemented them already. 

This is something we can't avoid. If you implement a draft before it 
completes a WG last call, then you need to be prepared to make changes 
to your implementation.

> Any change

We don't have such a thing in the IETF. If you are saying we shouldn't 
make a change to a Proposed Standard RFC without there being an issue, 
then I agree. But not to an Internet Draft.

> following issues. I also copied Netlmm wg.

Let me clarify a bit. I am not sure if folks have read through all the 
emails. More than it being an implementation overhead, it is difficult 
to implement this authorization check based on the current document. 
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.

> ISSUE N. 2:

I find this very weird. When you receive a message, you try to process 
it and carry about what the message told you to. Then you send a 
response. In this specific example, when you receive a revocation 
message, you first try to delete the binding and then send a BRA message.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 23:49:10 -0500

Hi Vijay,

> > disagree with and I strongly believe that is NOT a good practice to 
> > keep opening issues that have been addressed, consensus on 
> them have 
> > been reached, and closed. For the simple reason, those who accepted 
> > these issues as resolved, probably have implemented them already.
> 
> This is something we can't avoid. If you implement a draft 
> before it completes a WG last call, then you need to be 
> prepared to make changes to your implementation.
> 
[Ahmad]
That is NOT TRUE. 
The WGLC has already been completed. This partial LC is restricted to
the Alternate-CoA use, which apparently you do NOT have a problem with.
Please check the chairs messages.

> > Any change
> > which is NOT related to a clear technical issue, should not be 
> > granted, IMHO.
> 
> We don't have such a thing in the IETF. If you are saying we 
> shouldn't make a change to a Proposed Standard RFC without 
> there being an issue, then I agree. But not to an Internet Draft.

[Ahmad]
Also, NOT on an internet draft after completing wglc. I believe
attempting to reopen issues that have been concluded and achieved
consensus is a waste of time and should not be the common practice,
especially if there is NO technical issue and it is nothing but one
person's preference and opinion. Again, IMHO, that is a waste of time.

> > This has been in the draft since inception and discussed many times 
> > and agreed upon, however, it seems that Vijay disagree and 
> finds that 
> > a huge implementation overhead.
> 
> Let me clarify a bit. I am not sure if folks have read 
> through all the emails. More than it being an implementation 
> overhead, it is difficult to implement this authorization 
> check based on the current document. 

[Ahmad]
This has been discussed before and agreed upon.
Authorization is NOT a new thing. It is already captured and documented
in RFC5213 under section 5.3. and it is needed for each PBU. Nothing
special in here.

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

[Ahmad]
Again, What about authorization as per section 5.3. in PMIPv6
specification? Why is that possible for PBU?
There are many ways to do this and that is why it is left for the
creativity of Architect to find the best that fits their product
architecture.

> > However, In every applicable scenario which requires the receiving 
> > node to follow the above sequence, it is CLEARLY 
> documented. The whole 
> > idea
> > delete its binding from the BUL. As long as the MN does not 
> use that 
> > HoA binding, WHY in the WORLD this is a PROBLEM?
> > 
> > II. Global Revocation: Since this is allowed currently, if the MAG 
> > sends a Global revocation which impacts 20k sessions, for examples, 
> > WHY the LMA needs to hold sending BRA until it deletes all 
> resources 
> > associated with these 20k sessions. An implementation could 
> do that. 
> > Nothing WRONG with that BUT what is WRONG if another implementation 
> > sends that BRA and then executes all the deletion.
> 
> I find this very weird. When you receive a message, you try 
> to process it and carry about what the message told you to.
[Ahmad]
Probably you need to get out of the mode of BU/BA. It is a little
different. Smart implementations MAY schedule the processing of messages
based on their priorities. There is nothing wrong by sending the BRA and
starting the deletion process at the same time. As I said many times
already there is scenarios that the receiving node MAY choose to send
the BRA and complete the deletion later on, especially Bulk Revocation.
Capturing a restriction that makes ALL implementation do the same thing
is NOT a smart nor a creative way.

BOTTOM LINE:
DO you have any SINGLE scenario that needs to follow your sequence of
event and it is NOT documented in the draft?

> Then you send a response. In this specific example, when you 
> receive a revocation message, you first try to delete the 
> binding and then send a BRA message.

[Ahmad]
That could be one way of implementing it. That is absolutely fine, BUT
it should NOT be mandated on every other implementation.

---

From: Joel Hortelius <[email-masked]>
Date: Fri, 13 Mar 2009 09:27:44 +0000

Resending my questions in brief form;

1; Since some triggers do require specific actions, and the draft uses
the word "currently defined" for trigger definitions indicating new
triggers may be added - how is an implementation supposed to deal with
future triggers that may or may not require specific action?

2; What combinations are possible? What triggers may be used with the
'G' bit? Some triggers have been indicated that they should be used with
'G', but others do not. Some combinations do not make sense. Does 'G'
ONLY work with those explicitly specified? If so, what should one do
with the other combinations if they appear?

3; Since you define your own namespace regarding revocation trigger
message types (BRI, BRA), it would have made sense to me to split the
messages even further and have a Global BRI and Global BRA instead of
the 'G' bit, AND separate the trigger reason values into a global and
per binding trigger namespaces. Mixing global trigger reasons with
per-binding session reason, where the global "namespace" requires
specific actions based on trigger reason quickly gets complex. Having
them separated would remove the most obscure combinations, which are
either meaningless or invalid. 

4; Just remembered that the per-session revocation do require specific
action on some triggers (unknown handoff). Perhaps splitting the trigger
values:
< 128  -"soft" triggers; revoke and log - may use reason for for
undefined action to restore connectivity. This would be
"administrative", "user initiated", etc.
>= 128 -"hard" trigger. If unknown, reply with "unsupported trigger",
otherwise do the actions defined by the trigger. This would be
"per-peer", "node-local", "unknown handoff" etc.

5; What is one supposed to do if both 'G' and 'V' bit are set in a BRI?

6; The partial success on MAG is hazy; When is it supposed to be used?

7; The out of sync BCE state trigger, when is it supposed to be used? I
can't find any reference to it in the doc.

Regards,
Joel Hortelius

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 13 Mar 2009 12:05:10 -0400

Hello, 

> 3; Since you define your own namespace regarding revocation 
> trigger message types (BRI, BRA), it would have made sense to 
> me to split the messages even further and have a Global BRI 
> and Global BRA instead of the 'G' bit, AND separate the 
> trigger reason values into a global and per binding trigger 
> namespaces. Mixing global trigger reasons with per-binding 
> session reason, where the global "namespace" requires 
> specific actions based on trigger reason quickly gets 
> complex. Having them separated would remove the most obscure 
> combinations, which are either meaningless or invalid. 

This is a good idea. I would also like to see this change done.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 13 Mar 2009 13:00:54 -0500

Hi Joel,
Please see responses inline.

Regards,
Ahmad

> From: Joel Hortelius [mailto:[email-masked]] 
> Sent: Friday, March 13, 2009 4:28 AM
> Cc: mext; [email-masked]
> 1; Since some triggers do require specific actions, and the 
> draft uses the word "currently defined" for trigger 
> definitions indicating new triggers may be added - how is an 
> implementation supposed to deal with future triggers that may 
> or may not require specific action?
>
 
[Ahmad]
I believe the safest approach is to allow the receiving node to reject
such message with a proper status code, "Revocation Trigger NOT
Supported" or we can make it more generic "Specific Revocation
Functionality NOT Supported"

> 2; What combinations are possible? What triggers may be used 
> with the 'G' bit? Some triggers have been indicated that they 
> should be used with 'G', but others do not. Some combinations 
> do not make sense. Does 'G'
> ONLY work with those explicitly specified? If so, what should 
> one do with the other combinations if they appear?

[Ahmad]
Yes, Global Revocation is meant to communicate a Mass revocation which
impact all mobility sessions between the pair MAG-LMA. Another use case
was discussed to allow the LMA, for example, to revoke multiple sessions
that belong to all MN(s) which share a specific criteria, e.g., MN-ID
belong to a certain realm. The receiving node need to be able to
differentiate between the two cases. Thus, there was two different
Revocation Triggers.

Any other combinations of (G) bit and other R. T. is NOT supported. IMO,
the receiving node should reject that BRI.
We can add text for this one. 

> combinations, which are either meaningless or invalid. 

[Ahmad]
Good point. I see what you are saying about the separation of the
triggers. However I do not see any value in creating different message
type for Global revocation. It is the same message and duplication
should be eliminated as much as possible.

> 
> 4; Just remembered that the per-session revocation do require 
> specific action on some triggers (unknown handoff). Perhaps 
> splitting the trigger
> values:
> < 128  -"soft" triggers; revoke and log - may use reason for 
> for undefined action to restore connectivity. This would be 
> otherwise do the actions defined by the trigger. This would 
> be "per-peer", "node-local", "unknown handoff" etc.

[Ahmad]
Okay, this means that we will have the following combination:

Per-MN Soft,
Per-MN Hard,

Global, Soft, and
Global, hard

That is probably too much. I believe separating the triggers to per-MN
and Global will suffice. Introducing Status code of "Unsupported
Trigger" is a good idea too.

> 5; What is one supposed to do if both 'G' and 'V' bit are set 

[Ahmad]
I actually thought about this one but I was not able to come up with a
usecase that justifies it. In other words, why the LMA, for example,
would send a Global BRI to revoke all IPv4 binding only?
If there is a valid usecase, we could add it.

> 6; The partial success on MAG is hazy; When is it supposed to be used?
[Ahmad]
The original intention was: If the MAG, for example, received a BRI
which impacts multiple sessions and one of these sessions for a reason
or another was already removed because of race condition, for example,
the MAG would set the status Code to either "success" or "partial
success". However, it seems that this "partial success" opens the door
for a lot of interpretations. If the group thinks that is problematic,
we can actually remove it completely.

> 
> 7; The out of sync BCE state trigger, when is it supposed to 
> be used? I can't find any reference to it in the doc.

[Ahmad]
Hmmm... I guess we missed the text for this one. Will add it.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 13 Mar 2009 11:14:00 -0700 (PDT)

Hi Vijay,

Some comments on this.

>> addition, I think this authorization step is unnecessary and

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

Now, this check for bulk dereg spanning many MN's is for the
specific operation, if its allowed or not. This is a requirement
for a good system design, from OM perspective. Has no bearing
on protocol interop. I dont think this can be an issue, one
can always add a * rule to permit every MAG to perform such
operation.

If your concern is maintaing that list, we can always state in
a secure network, the MAG can just have one flat rule to allow
such operation from all the configured peers that it knows.
Will that work ?

Sri

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Mar 2009 11:56:02 +0800

Hello,
>We can add text for this one. 

Sound good to me, But I wonder whether multiple sessions reovocation for Proxy MIPv6 use case  is covered in the draft?
Because in the section 3.4.2, only global revocation is covered.

Regards!
-Qin

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Mar 2009 01:46:36 -0500

Hi, Qin,

> >> 'G' bit? Some triggers have been indicated that they 
> should be used 
> >> with 'G', but others do not. Some combinations do not make sense. 
> >> Does 'G'
> >was discussed to allow the LMA, for example, to revoke multiple 
> >sessions  that belong to all MN(s) which share a specific criteria, 
> >e.g., MN-ID  belong to a certain realm. The receiving node 
> need to be 
> >able to  differentiate between the two cases. Thus, there was two 
> >different  Revocation Triggers.
> >Any other combinations of (G) bit and other R. T. is NOT supported. 
> >IMO, the receiving node should reject that BRI.
> Sound good to me, But I wonder whether multiple sessions 
> reovocation for Proxy MIPv6 use case  is covered in the draft?

[Ahmad]
It is covered. 
If the (G) bit is set and the R. T. is set to "Revoking Node Local
Policy", then you need to include more information that are common to
all BCE, for example: you could send the MN-ID to "[email-masked]". This
means that the sending node is requesting that all BCE with the MN-ID
that match the MN-ID above should be revoked.

Here is the related text:

1. under section 6.1:

   Global (G)

      The Global (G) bit is set by the sending mobility node, LMA or
      MAG, to request the termination of all Per-Peer mobility Bindings
      or Multiple Bindings which share a common identifier that are
      served by the sending and receiving mobility entities as in
      Section 9.1.1 and Section 10.2.1. 

2. Under section 9.1.1:

   When the LMA needs to revoke all mobile nodes proxy BCE that belong
   to a specific realm, e.g. @companyabc.com, and are registered with
   the LMA and hosted at the MAG, the local mobility anchor MUST set the
   Global (G) bit and the value of the Revocation Trigger field to
   "Revoking Node Local Policy".  In this case, the local mobility
   anchor MUST include a mobility option to identify the impacted
   bindings, e.g.  MN-ID option with a wildcard NAI, e.g.
   [email-masked], to identify all the mobile nodes BCEs that need to
   be removed.

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Mar 2009 17:23:23 +0800

Hi, Ahmad:
Please see the followup comments.
-Qin
----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Joel Hortelius" <[email-masked]>
Cc: <[email-masked]>; "mext" <[email-masked]>
Sent: Monday, March 16, 2009 2:46 PM
Subject: RE: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt

Hi, Qin,

[Ahmad]
It is covered. 

1. under section 6.1:

   Global (G)

[Qin]: Just As you said, the multiple bindings revocation has already been included in the definition of Global(G).
However the multiple bindings revocation is quite different from multiple per-peer bindings revocation what I understand. Let me give you one exmaple on multiple per-peer bindings revocation.

 One mobile device owning three interfaces which share the same NAI registers to the same LMA, if the LMA want to revoke two per-Peer bindings associated with two interfaces of the mobile devices.What should the LMA do using bulk PMIP6 binding revocation? 

 I wonder whether this example can be viewed as multiple bindings revocation and whether this use case should be considered in this binding revocation draft.

2. Under section 9.1.1:

[Qin] If all mobile nodes BCEs belong to the same specific realm and are hosted at the different  MAGs which register to the same LMA,
what should this LMA do using multiple bindings revocation mechanism? It seems multiple BRA messages to the different MAG are required.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Mar 2009 07:34:44 -0500

Hi, Qin,
Please see inline.

> 
> [Qin] If all mobile nodes BCEs belong to the same specific 
> realm and are hosted at the different  MAGs which register to 
> the same LMA,
> what should this LMA do using multiple bindings revocation 
> mechanism? It seems multiple BRA messages to the different 
> MAG are required.
> 

[Ahmad]
This is NOT allowed and NOT supported. When MAG1 sends a BRI to revoke
multiple binding for a specific realm, it ONLY revokes those bindings
which are registered using a pCoA that belong to MAG1. In other words,
MAG1 is not supposed to remove binding(s) that registered through MAG2,
for example.

That is why LMA always sends a single BRA to MAG1.

Regards,
Ahmad

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Mar 2009 17:49:42 -0700

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

> for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the

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.

> can always add a * rule to permit every MAG to perform such

This does not make sense. If we are going to create a rule allowing all 
MAGs to perform bulk revocation, then why do we need the authorization 
check?

> such operation from all the configured peers that it knows.

You mean the LMA, right? The LMA is the one that does this check.

Your email does not address my question on how this list is created at 
the LMA. Why is one MAG special and allowed to do bulk revocation while 
another MAG is not allowed? The MAGs are all part of the same PMIPv6 domain.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Mar 2009 18:25:11 -0700 (PDT)

On Mon, 16 Mar 2009, Vijay Devarapalli wrote:

> 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

See this below snipper from Jari.

"Here's a potential rewrite:

Therefore, the local mobility anchor MUST restrict the creation
and manipulation of proxy bindings to specifically authorized
mobile access gateways, mobile nodes, and prefixes."

> 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 does not make sense. If we are going to create a rule allowing all MAGs 
> to perform bulk revocation, then why do we need the authorization check?
>

Building the rule into the system is for defining an authorization model,
relaxing that rule in a given system deployment is a SDO/deployment
choice. That's the operator's choice based on the security considerations
in their operating environment.

> You mean the LMA, right? The LMA is the one that does this check.

Yes, typo

> Your email does not address my question on how this list is created at the 
> LMA. Why is one MAG special and allowed to do bulk revocation while another 
> MAG is not allowed? The MAGs are all part of the same PMIPv6 domain.
>

There is not much to address. We require the LMA to maintain a list
of MAG's authorized to perform certain functions. We need a very similar
list, or add an attribute to the above maintained list, with finer
access control as who can perform bulk dereg operations.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Mar 2009 18:32:11 -0700

Hi Sri,

Sri Gundavelli wrote:
>> 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.
>>
> 

This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in 
April 2007 had the following

    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.

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

Sorry, I am not convinced that this authorization check is needed for 
bulk revocation from the MAG.

Vijay

>> This does not make sense. If we are going to create a rule allowing 
>> all MAGs to perform bulk revocation, then why do we need the 
>> authorization check?
>>
>> the LMA. Why is one MAG special and allowed to do bulk revocation 
>> while another MAG is not allowed? The MAGs are all part of the same 
>> PMIPv6 domain.
>>
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Mar 2009 18:48:36 -0700 (PDT)

Hi Vijay,

On Mon, 16 Mar 2009, Vijay Devarapalli wrote:

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

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

> 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

---

From: Yungui Wang <[email-masked]>
Date: Tue, 17 Mar 2009 10:57:55 +0800

Hello

Sorry for jumping in. 
A MAG deletes 30,000 bindings continuously (via 30,000 messages), 
whose impact is the same as deleting 30,000 bindings via 1 message. 
I can't find its difference too. That's, 'impact many sessions' seems not 
very convinced.
In my mind, if a MAG is not allowed to delete binding, it can't delete
any binding, vice versa.

> to pass additional authorization, as that can impact many sessions.

B.R.
Yungui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Mar 2009 22:14:35 -0500

Hi, Yungui,

Does this mean if a guy has a license for carrying a pistol, he
automatically CAN gain access to weapons of mass destruction, WMD?

-OR-

Does a field support guy who is authorized to change the datafill of a
single mobile node, automatically has the authorization to REBOOT the
whole BOX.

Similarly, in order for a MAG to have the capabilities to delete
thousands of sessions in a single message needs an additional
authorization.

Hope these examples help us realize the difference in the two cases.

Regards,
Ahmad

> Behalf Of Yungui Wang
> Sent: Monday, March 16, 2009 9:58 PM
> To: 'Sri Gundavelli'; 'Vijay Devarapalli'
> Cc: 'mext'; 'Julien Laganier'
> A MAG deletes 30,000 bindings continuously (via 30,000 
> messages), whose impact is the same as deleting 30,000 
> bindings via 1 message. 
> I can't find its difference too. That's, 'impact many 
> sessions' seems not very convinced.
> In my mind, if a MAG is not allowed to delete binding, it 
> can't delete any binding, vice versa.
> 
> > 
> > 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.
> >  
> 
> B.R.
> Yungui
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Mar 2009 20:20:50 -0700 (PDT)

Hi Yungui,

The authorization check is for a specific case of bulk revoc
operation. A single dereg message and a bulk revocation
messages, have different impact scope and so are the
authorization checks which need to define finer access
controls matching the specific impact scope.

Sri

---

From: Yungui Wang <[email-masked]>
Date: Tue, 17 Mar 2009 15:02:11 +0800

Hello

I understand your concerns. A MAG should be carefully implemented 
to send a bulk revocation message. 
But I am wondering if it is necessary/meaningful that the LMA checks the
authorization.
For example, if a non-authorized MAG wants to implement the bulk de-reg
function, 
it can send a big lower-layer frame encapsulated with many single dereg
messages 
(assume that possible) to bypass that authorization check. In this case,
does the 
LMA check the authorization?

B.R.  /Yungui Wang

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, March 17, 2009 11:21 AM
> To: Yungui Wang
> Cc: 'Vijay Devarapalli'; 'Julien Laganier'; 'mext'
> Subject: RE: [MEXT] Review of