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

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 17 Dec 2008 23:08:01 -0800

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 18 Dec 2008 09:19:02 -0600

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

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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).
> 

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

>      ^^^^^^^^^^^                                              

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

>      Signaling MH type <IANA-TBD>."

[Ahmad]
Looks good to me.

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

> >    format described in section 6.1.  [RFC3775].  The value in the
[Ahmad]
Sure we can reference [RFC3775].
                                     
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                        Mobility options            
>            .
> >        |                                                    
>            |

[Ahmad]
Ok. Thx.

> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                        Mobility options            
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |
> 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, 

[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. 
 
> > > 
> >    When the home agent send a BRI to the mobile node with 
> the (A) bit 
> > is
> 
>                          ^^^^
>                          sends
[Ahmad]
Ok. Thx.

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

> >       using the appropriate status code.

[Ahmad]
Yes. Thx.

> >    When the mobile node receive a valid Binding Revocation 
[Ahmad]
Ok.

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

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

---

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 21 Dec 2008 11:30:51 -0800

Hi,

> tunnel without informing the MN. 

What about that instead of the last sentence:

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

> to give more flexibility; but changing the text to "to be used" is fine

What I meant is that the structure of the sentence look strange, but
maybe it's just my english.

>>      Signaling MH type <IANA-TBD>."

ack.

> to send a Binding Revocation Signaling message".

ack.

> Sure we can reference [RFC3775].

it's not what I meant. I meant that "[RFC3775]" sits there in the middle
of the sentence. Is it expected?

> meanings and use are mentioned when these specific scenario are

I may have missed them but "partial success" and "Revocation failed, MN
is attached" (at least) are not.

> then, IMO, it does not make sense to allow the mobile node to move

I understand your point, but the way it is specified in the draft does
not leave room for the reverse scenario: the extension provides the
ability to warn the user that his access *has been* interrupted but not
that it *will be* interrupted soon (i.e. no possible grace period). 

> mobile node BCE accordingly, e.g. removing the revocation in progress

ok.

>> is used, it should probably be replaced by "Type 2 Routing 

ack. thanks

Cheers,

a+

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 22 Dec 2008 19:56:56 -0600

Hi Arnaud,

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

[Ahmad]
Ok.

> it's not what I meant. I meant that "[RFC3775]" sits there in 
> the middle of the sentence. Is it expected?

[Ahmad]
I see what you meant.

What about the following:

   This section defines the Binding Revocation Message format using a MH
Type 
   <IANA-TBD> as illustrated in Figure 4. The value in the Binding
Revocation Type 
   field defines whether the Binding Revocation message is a BRI or BRA.
If the 
   Binding Revocation type field is set to 1, the Binding Revocation
Message is 
   a Binding Revocation Indication message as in Section 6.1. However,
if the 
   value is 2, it is a Binding Revocation Acknowledgement message as in
Section 6.2.

> > 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?)
> >>  
> I may have missed them but "partial success" and "Revocation 
> failed, MN is attached" (at least) are not.

[Ahmad]
Sure. We will make sure that all of these values are described and
documented in the new revision.

In the meantime, in bthe case of "Partial success", it is the case when
the MAG for example, receives a BRI that impact multiple bindings while
some of them have been released already, for example. The MAG may set
the status to success or partial success. 

In the case of "Revocation failed, MN is attached", in the case of
inter-MAG HO, the LMA may send a BRI message with a Revocation Trigger
value of "Inter-MAG HO". In this case, the MAG may need to ensure that
the MN is no longer attached. If the MN is still attached, then the MAG
could send a BRA with this status value.

For example, one of the bullets under section 10.1.1. says:

      If the Revocation Trigger field value in the received Binding
      Revocation Indication message indicates an inter-MAG handover and
      the (A) bit is set, the MAG use the mobility option(s) included in
      the BRI message to identify the mobile node binding.  The mobile
      access gateway MAY validate that the mobile node is no longer
      attached to the mobile access gateway before sending a successful
      Binding Revocation Acknowledgement message to the LMA.  However,
      if the Revocation Trigger field is set to "Inter-MAG - Unknown
      Handoff", the MAG MUST validate that the mobile node is no longer
      attached to the MAG before sending a successful BRA message and
      deleting the resources associated with the mobile node binding. 

We could add some text to the above to read as follows:

      .....................................................  However,
      if the Revocation Trigger field is set to "Inter-MAG - Unknown
      Handoff" and the (A) bit is set, the MAG MUST validate that the 
      mobile node is no longer attached to the MAG before sending a 
      successful BRA message and deleting the resources associated 
      with the mobile node binding. Otherwise, if the MAG verified that 
      the MN is still attached, the MAG MUST set the status field in the

      BRA to "Revocation failed - MN is attached"

Regards,
Ahmad

> >> is used, it should probably be replaced by "Type 2 Routing Header" 
> >> for consistency.
> >
> > [Ahmad]
> > Sure.
> 
> ack. thanks
> 
> Cheers,
> 
> a+
> 
>

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 22 Dec 2008 22:50:20 -0800

Hi Ahmad,

"Ahmad Muhanna" <[email-masked]> writes:

>    This section defines the Binding Revocation Message format using a
>    MH Type <IANA-TBD> as illustrated in Figure 4. The value in the
>    Binding Revocation Type field defines whether the Binding
>    Revocation message is a BRI or BRA. If the Binding Revocation type
>    field is set to 1, the Binding Revocation Message is a Binding
>    Revocation Indication message as in Section 6.1. However, if the
>    value is 2, it is a Binding Revocation Acknowledgement message as
>    in Section 6.2.

fine with me. thanks.

>       BRA to "Revocation failed - MN is attached"

Thanks for the clarification. But note that I'm not familiar enough w/
PMIPv6 to be helpful and comment that.

Cheers,

a+