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

[[e-mail] (Arnaud Ebalard)]

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?


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

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

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

     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?
                                     

> 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

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

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?

> 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

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

> 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
> 11.2.  Sending Binding Revocation Acknowledgement
> 
>    When the mobile node receive a valid Binding Revocation Indication

                          ^^^^^^^
                          receives

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

                      ^^
                 to be removed



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.

Cheers,

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