Re: [MEXT] Binding Revocation almost ready for IESG

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

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

Regards,
Ahmad

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

[Ahmad]
Sure.

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

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

> 
> In 3.2
> ------
> 
>    This mechanism enables the home domain to dynamically allow
>    the user to act upon the revocation message in order to recover its
>    interrupted mobile IPv6 services.
> 
> => How about:
> 
>    This mechanism enables the user to react to the revocation, e.g.,  
>    reinstate its interrupted Mobile IPv6 services.
[Ahmad]
That is good. Will use that.

> 
> In 3.4
> ------
> 
>    Since the Mobile node does not participate in the mobility 
> mechanism
>    in the case of PMIPv6, there are many scenarios where Binding
>    Revocation mechanism is needed to clean resources and make 
> sure that
>    the mobility entities, e.g.  MAG and LMA, are always synchronized
> 
> => Should be i.e. instead of e.g.
> 
[Ahmad]
Ok.

> In 3.4.1.
> ---------
> 
>    In this case, the MAG could send a Router Advertisement message to
>    the MN with the home network prefix lifetime set to zero.
> 
> => the PIO for the home network prefix has two lifetime, here 
> I think you're talking about the valid lifetime. If so, please fix. 
[Ahmad]
Sure.

> 
> In 4.
> -----
> 
>    Additionally, in the case when the LMA receives a BRI 
> which indicates
>    a bulk termination where the (G) bit is set and the Revocation
>    Trigger field is set to "Per-Peer Policy", the LMA MUST verify that
>    the MAG sending the binding revocation indication message is
>    authorized to invoke Global revocation.
> 
> => What sort of authorization do you have in mind here? Do 
> you mean the LMA MUST verify that the MAG sending the binding 
> revocation indication message is the one who currently owns 
> the binding as per the BCE? If so better to be spelled out.
>
[Ahmad]
That is given, a MAG which does not have or previously had created a BCE
for the MN is allowed to send a BRI for that MN. However, what is meant
here: is that MAG allowed to participate in Bulk revocation? We
discussed this on the ML quite a bit and agreed that for a MAG to issue
a global revocation which presumably impacts  all sessions between the
MAG and the LMA is something needs authorization and agreement between
the two nodes.
 
> In 6.1.
> -------
> 
>       Reserved and Per-MN Revocation Trigger:
>           0  Reserved
>           1  Unspecified
>           2  Administrative Reason
>           3  Inter-MAG Handover
>           4  User Initiated Session(s) Termination
>           5  Access Network Session(s) Termination
>           6  Possible Out-of Sync BCE State
> 
> => What is Possible Out-of Sync BCE State? The others are 
> self-explaining, but this one I am unclear when it shall be 
> sent, neither what it mean when I receive... Could we be more precise?

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

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



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

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

> 
> In 7.
> -----
> 
> 7.  Binding Revocation Process Considerations
> 
>    The following subsections describe the details of the binding
>    revocation generic process by the different mobility entities.
> 
> => I do not like the title, the subsections contain normative 
> text, thus these are everything but "considerations". Please 
> change to something straightforward and relevant: "Generic 
> Mobile Entity Operation" or sthg else.
[Ahmad]
No problem, will do.

> 
> In 7.1.
> -------
> 
>    When sending a Binding Revocation message, the sending 
> mobility node,
>    initiator, constructs the packet as it would any other Mobility
>    Header with the exception of setting the MH Type field to 
> <IANA-TBD>.
> 
> => but later it says:
> 
>    When a mobility entity initiates the binding revocation process by
>    sending a Binding Revocation Indication message, the initiator MUST
>    construct the BRI message as described in Section 6.1. 
> 
> => and:
> 
>    However, when the responder acknowledges the BRI message 
> by sending a
>    BRA, the responder MUST construct the Binding Revocation
>    Acknowledgement as described in Section 6.2. 
> 
> => so which one is it, as any other mobity header, or as per 
> 6.1 and 6.2?
[Ahmad]
I guess we need to have the text tweaked a little. But, the Binding
Revocation message is a mobility header and BRI format is defined in
section 6.1. and for BRA in section 6.2. so It is built as any other
mobility header + following the format specified in 6.1 or 6.2.

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

[Ahmad]
Perfect. Thanks!

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

> In 14.
> ------
> 
>    However, in the case when the MAG sends a BRI message with 
> the Global
>    (G) bit is set and the Revocation Trigger field is set to "Per-Peer
>    policy", the LMA MUST verify that the MAG is authorized to use Per-
>    Peer Global Revocation.
> 
> => Again I'd appreciate a better scoping of authorization in 
> the above.
> 
> Hope that helps to improve the document before it hits IESG.
[Ahmad]
Indeed. Thanks for the comments Julien! 
I will start working on the update and hopefully will be able to spin a
quick one soon.

> 
> --julien
>