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

[[e-mail] (Arnaud Ebalard)]

Hi,

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


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

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

>> > 3.4.  Proxy MIPv6 Use Case
>> >
>> >    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.

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

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

ack.

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

ack.

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

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


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

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

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

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

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

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.

ack. thanks

Cheers,

a+

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