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

[Vijay Devarapalli <vijay at wichorus.com>]

Ahmad Muhanna wrote:

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

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?

> 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 :)

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

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?

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

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
> "SHOULD", would that address your concern?

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

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

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.

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

Sounds good.

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

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]
> 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?

Excellent. This works for me.

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

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.

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

Looks good.

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

No problem.

Vijay