Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02

["Ahmad Muhanna" <[e-mail]>]

Hi Arnaud,
Thanks for the review, please see responses inline.

Regards,
Ahmad
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Arnaud Ebalard
> Sent: Thursday, December 18, 2008 1:08 AM
> To: IETF MEXT WG ML
> Cc: Julien Laganier
> Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02
> 
> Hi,
> 
> I have reviewed draft-ietf-mext-binding-revocation-02. My 
> comments are below. Note that I did not covered parts related 
> to PMIPv6 (RFC5213).
> 
> > 3.2.  Client MIPv6 and DSMIP6 Use Case
> > 
> >    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 not have an unexpectedly interrupted mobile 
> IPv6 services.
> 
> Well, when it receives the information, it's already too 
> late, isn't it?

[Ahmad]
What is meant here, the MN will have an instant but graceful indication
that its mobility service is being revoked. At that time, the MN will be
able to make an out of scope communication to check/enable/etc. the
service with its provider, for example. This case is meant to
replace/"be compared" the case when the HA deletes the binding and the
tunnel without informing the MN. 


> 
> 
> > 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
> 
>      ^^^^^^^^^^^                                              
>      ^^^^
> 
>                       "so that it can be" or "to be used"

[Ahmad]
I do not see any normative text here but, I think "can be used" is used
to give more flexibility; but changing the text to "to be used" is fine
with me if necessary.


> 
> > 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 SPD of the respected IPsec SA MUST allow the Binding
> >    Revocation Signaling MH type <IANA-TBD> in order to 
> allow BRI and BRA
> >    messages to be exchanged.

> 
>      What about replacing last sentence by following text:
> 
>      "If IPsec is used, the traffic selectors associated with the SP
>      protecting BU and BA MUST be extended to include Binding 
> Revocation
>      Signaling MH type <IANA-TBD>."

[Ahmad]
Looks good to me.

> 
>      What about also including some rationale for this choice, w/ sth
>      like the following ? :
> 
>      "Extending the traffic selectors of the SP in order to 
> reuse the SA
>      protecting BU and BA (instead of creating new ones) provides the
>      insurance that those SA will be up and running when the revoking
>      entity will need to send a Binding Revocation Signaling message".
> 
[Ahmad]
This is good to me too. 
However, I would make a minor change: replace "provides insurance" with
"ensures" and "will need" to "needs"
The suggested text would read as follows:

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


>      If you decide to keep current text, "respected" should 
> be replaced
>      by "respective", IMO.
> 
>      Last question on that paragraph: The last sentence start with
>      "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6?
> 
> > 6.  Binding Revocation Message
> > 
> >    This section defines a Binding Revocation Message that 
> use a MH type
> >    <IANA-TBD> with a Binding Revocation type field that 
> follow the MH
> >    format described in section 6.1.  [RFC3775].  The value in the
> 
>                                  ^^^^^^^^^^^^^^^^
>                           6.1 of [RFC3775] or just 6.1?
> 
[Ahmad]
Sure we can reference [RFC3775].
                                     
> 
> > 6.1.  Binding Revocation Indication Message
> > 
> >    The Binding Revocation Indication (BRI) message is a Binding
> >    Revocation Message which has a MH type <IANA-TBD> and a Binding
> >    Revocation Type value of 1.  It is used by the revoking 
> mobility node
> >    to inform the receiving mobility entity that the IP 
> mobility service
> >    of a specific binding or bindings have been revoked.  Binding
> >    Revocation Indication message is sent as described in 
> Section 8.1,
> >    Section 9.1.1, and Section 10.2.1.
> > 
> >    When the value 1 is indicated in the B. R. type field of 
> the Binding
> >    Revocation Message, the format of the Binding Revocation 
> Message Data
> >    follows the Binding Revocation Indication message as in Figure 5
> > 
> > 
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
> >                                        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                                        | B.R. Type = 1 |  
> R. Trigger   |
> >        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Sequence #           |P|A|G|       
> Reserved          |
> >        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                        Mobility options            
>            .
> >        |                                                    
>            |
> >        
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> > 
> > 
> >               Figure 5: Binding Revocation Indication Message
> > 
> > 
> >    Revocation Trigger
> > 
> >       8-bit unsigned integer indicting the event which triggered the
> 
>                               ^^^^^^^^^^
>                               indicating

[Ahmad]
Ok. Thx.

> 
> > 6.2.  Binding Revocation Acknowledgement Message
> > 
> >    The Binding Revocation Acknowledgement (BRA) message is a Binding
> >    Revocation Message which has a MH type <IANA-TBD> and a Binding
> >    Revocation Type value of 2.  It is used to acknowledge 
> the receipt of
> >    a Binding Revocation Indication message described in Section 6.1.
> >    This packet is sent as described in Section 9.2.2, 
> Section 10.1.2,
> >    and Section 11.2.
> > 
> >    When the value 2 is indicated in the Binding Revocation 
> type field of
> >    the Binding Revocation Message, the format of the 
> Binding Revocation
> >    Message Data follows the Binding Revocation 
> Acknowledgement message
> >    as in Figure 6
> > 
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
> >                                        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                                        | B.R. Type = 2 |    
> Status     |
> >        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |            Sequence #         |P|G|         
> Reserved          |
> >        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                        Mobility options            
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |
> >        
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> > 
> >            Figure 6: Binding Revocation Acknowledgement Message
> > 
> > 
> >    Status
> > 
> >       8-bit unsigned integer indicating the result of processing the
> >       Binding Revocation Indication message by the 
> receiving mobility
> >       entity.  The following status values are currently defined.
> > 
> >           0  success.
> >           1  partial success.
> >           2  Binding Does NOT Exist.
> >           3  IPv4 HoA Binding Does NOT Exist.
> >           4  Global Revocation NOT Authorized.
> >           5  CAN NOT Identify Binding.
> >           6  Revocation Failed, MN is Attached.
> 
> The Binding Revocation Trigger values in Section 6.1 look 
> more self-explanatory. They are also mainly informational, right?

[Ahmad]
Yes, it is mainly informational. However, whenever any R. Trigger value
means a specific action is needed on the side of the receiving mobility
node, IMO, it needs to be documented. If we missed any of these, we can
go back and do it.

> 
> Here, it is not clear what "partial success" (1) or 
> "Revocation failed, MN is attached" mean, and what both 
> entities should expect when those are sent. Maybe the 
> rationale that were associated with those values when the 
> list was first created should be included in the document, 
> along with the expected behaviors (Are those status value just
> informational?)
>  
> Or did I missed some other section that provides that in the draft?

[Ahmad]
I agree it is mainly informational but some of these status is
appropriate with certain scenarios. I believe those status values
meanings and use are mentioned when these specific scenario are
discussed later on. 
 
> 
> > 8.  Home Agent Operation
> > 
> > 8.1.  Sending Binding Revocation Indication
> > 
> >    When an event requires the home agent to terminate a mobile node
> >    mobile IPv6 registration, e.g. for administrative 
> reason, the home
> >    agent sends a Binding Revocation Indication message to the mobile
> >    node to inform the mobile node that its specified 
> binding has been
> >    revoked and it will no longer be able to receive an IP 
> connectivity
> >    via its binding with the home agent.
> > 
> >    To terminate a mobile node registration and its current 
> binding with
> >    the home agent, the home agent sends a packet to the mobile node
> >    containing a Binding Revocation Indication, with the packet
> >    constructed as follows:
> > 
> >    o  The Acknowledge (A) bit MAY be set in the BRI to request the
> >       mobile node to send a Binding Revocation Acknowledgement upon
> >       receipt of the BRI.
> > 
> > 
> > 
> > 
> > 
> > Muhanna, et al.           Expires May 29, 2009              
>    [Page 18]
> > > 
> > Internet-Draft    Binding Revocation for IPv6 Mobility     
> November 2008
> > 
> > 
> >    o  The Revocation Trigger field MUST be set in the 
> Binding Revocation
> >       Indication to indicate to the mobile node the reason 
> for revoking
> >       its IP mobility binding with the home agent.  The Revocation
> >       Trigger may be used by the mobile node to take 
> further steps if
> >       necessary.
> > 
> >    o  The Binding Revocation Indication MUST be sent using a type 2
> >       routing header which contains the mobile node's 
> registered home
> >       address for the binding being revoked.
> > 
> >    o  The care-of address for the binding MUST be used as the
> >       destination address in the packet's IPv6 header, unless an
> >       Alternate Care-of Address mobility option is included in the
> >       Binding Revocation Indication.
> > 
> >    o  The packet MAY contain an IPv4 Home Address option 
> which contains
> >       the mobile node's registered IPv4 home address for the binding
> >       being revoked.
> > 
> > 
> >    The Acknowledge (A) bit in the Binding Revocation 
> Indication requests
> >    the mobile node to return a Binding Revocation Acknowledgement in
> >    response to this Binding Revocation Indication.  As described in
> >    Section 7.3, the home agent SHOULD retransmit this 
> Binding Revocation
> >    Indication to the mobile node before terminating its IP 
> connection
> >    until it receives a matching Binding Revocation 
> Acknowledgement or
> >    the BRIMaxRetransmitNumber has been reached.
> > 
> >    When the home agent send a BRI to the mobile node with 
> the (A) bit 
> > is
> 
>                          ^^^^
>                          sends
[Ahmad]
Ok. Thx.

> 
> >    set, the home agent sets a flag in the mobile node BCE 
> to indicate
> >    that revocation is in progress and starts the MINDelayBRIs timer.
> >    The home agent maintains the mobile node BCE in this 
> state until it
> >    receives a Binding Revocation Acknowledgement or the
> >    BRIMaxRetransmitNumber is reached.
> 
> What does "maintains the node BCE in this sate"? I mean, does 
> this mean that the mobile node is not able to perform 
> movement during that time?

[Ahmad]
We are talking about a race condition here which should be addressed
based on the reason of the BRI and HA local policy. If the MN
registration is being revoked for administrative reason, for example,
then, IMO, it does not make sense to allow the mobile node to move
anyway.

> If the revoking entity sends a BRI just when the mobile node 
> perform a handover (i.e. sends a BU), then locking the BCE 
> state will prevent the CoA update to happen on the revoking 
> entity and the retransmitted packets to be sent to the MN.

[Ahmad]
The revocation in progress flag is set until the HA receives a BRA or
the BRIMaxRetransmitNumber expires. We could add some text to address
this race condition and mention what the HA may do when this race
condition occurs.

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

> 
> > 9.  Local Mobility Anchor Operation
> 
> not reviewed.
> 
> > 10.  Mobile Access Gateway Operation
> 
> nott reviewed.
> 
> > 11.  Mobile Node Operation
> > 
> > 11.1.  Receiving Binding Revocation Indication
> > 
> >    Upon receiving a packet carrying a Binding Revocation 
> Indication, the
> >    mobile node MUST validate the packet according to 
> Section 7.2 and the
> >    following tests:
> > 
> >    o  The mobile node MUST verify that the IP address in the type 2
> >       routing header is its Home Address.
> > 
> >    o  If the Acknowledgement (A) bit is set in the Binding 
> Revocation
> >       Indication and the MN has the BCE in registered 
> state, the mobile
> >       node MUST send a Binding Revocation Acknowledgement.  
> However, in
> >       all other cases when the (A) bit is set in the BRI, the mobile
> >       node SHOULD send a Binding Revocation Acknowledgement.  In all
> >       cases, the mobile node MUST follow Section 11.2 when 
> send a BRA
> >       using the appropriate status code.
>                                                         ^^^^^^^^^^
>                                                         and send

[Ahmad]
Yes. Thx.

> > 11.2.  Sending Binding Revocation Acknowledgement
> > 
> >    When the mobile node receive a valid Binding Revocation 
> Indication
> 
>                           ^^^^^^^
>                           receives
[Ahmad]
Ok.

> 
> >    with the (A) bit is set from its home agent and while having this
> >    BCE
> 
>                       ^^
>                  to be removed

[Ahmad]
Ok.
> 
> 
> 
> General comment: in the draft, the few times "Type 2 Header" 
> is used, it should probably be replaced by "Type 2 Routing 
> Header" for consistency.

[Ahmad]
Sure.

> 
> Cheers,
> 
> a+
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext