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

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

Hi Vijay,

> draft-ietf-mext-binding-revocation-03.txt
> 
> Hi Ahmad,
> 
> On 3/10/09 3:45 PM, "Ahmad Muhanna" <amuhanna at nortel.com> wrote:
> 
> 
> >> 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?
> > 
> > [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.
> 
> 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.
> 
>           128  Binding Does NOT Exist
>           129  IPv4 HoA Binding Does NOT Exist
>           130  IPv4 HoA Option Required
>           131  Global Revocation NOT Authorized
>           132  CAN NOT Identify Binding
>           133  Revocation Failed, MN is Attached
> 
> 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.


> 
> >>>    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?
> > 
> > [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.
> 
> Ok, but what is meant by "... dynamically allow the user ..."?

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

> 
> 
> >>>    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.
> > 
> > [Ahmad]
> > Is the idea NOT to mention the inclusion of HoA in Type 2 
> header as it 
> > 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.

[Ahmad]
Sure, will update accordingly.

> 
> >>>    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?
> > 
> > [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.
> 
> The above paragraph says nothing about "per-peer policy". It 
> says for any bulk termination, the LMA must perform this 
> additional authorization check.
[Ahmad]
Sure, what about the following:

   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?

> 
> > 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.
> 
> 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.
> 
> > This case is much more severe and impact all bindings and I 
> believe it 
> > worth having this validation.
> 
> 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? 

> 
> >>> 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?
> > 
> > [Ahmad]
> > BRI should use the source port of the PBU which is saved in the BCE.
> 
> Ok. Please mention this explicitly.

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


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

> 
> >>>    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.
> >> 
> > [Ahmad]
> > That what the "next sequence number" means.
> > 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. 
[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?

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

>  
> >>>    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.
> > [Ahmad]
> > See the above comment?
> 
> I think the LMA should reject the PBU. Lets not complicate 
> things by bringing in this new "local policy" concept.

[Ahmad]
Please see above.

> 
> >>> 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.
> > 
> > [Ahmad]
> > OK.
> > Please see a re-write for the whole section below.
> > 
> >> 
> >> 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
> > 
> > [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.
> 
> 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!

> 
> Looks good.
> 
> Vijay
> 
>