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

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

> Subject: Re: [MEXT] Review of 
> draft-ietf-mext-binding-revocation-03.txt
> 
> 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. 
[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. 


> 
> > 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]
Please see above comment:)

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

[Ahmad]
Please see the responses below.

> 
> >>> 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.
[Ahmad]
Please see the responses below.

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

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

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

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

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

[Ahmad]
Oh.. Thanks GOD! :)
> 
> >>>>>    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.

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