Subject: [MEXT] review of the binding revocation draft

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2008 09:43:58 -0400

I read the draft. Its basically in good shape as far as the overall
approach goes, but there are a number of details that do need work:

>    One of the important scenarios that is applicable to Mobile IPv6
>    protocol [RFC-3775] is when a mobile node returns home.  According to
>    RFC3775, the mobile node is recommended to send a BU message with
>    lifetime of zero, however, RFC3775 did not mandate this behavior on
>    the mobile node.  In this case, if the home agent detects that the
>    mobile node has returned home but did not send a de-registration BU,
>    the home agent may send a BRI message to the mobile node using the
>    same security association that the mobile node and home agent
>    negotiated and used during the exchange of the initial BU and BA
>    messages.

Way too little information here. How does the home agent detect this?

And I'm not sure I understand what the security association details are
here. Looks like the mobile node was at another location previously,
with other addresses in the relevant SA fields?

> 4.  Revocation Signaling and Use Cases

This section has duplicated text for the various cases, e.g., around the
requirements for responding to BRIs with the A bit set. It seems that
the rules for responding to the BRIs are the same in any case. Focus on
explaining the use cases, not specifying behavior rules in this section.
'

>    If the mobile node processes
>    the BRI message, it SHOULD send a BRA message to the home agent if
>    the A bit in the BRI message is set.
>    Similarly if the
>    local mobility anchor receives and successfully process a BRI message
>    with the A bit is set, the local mobility anchor MUST send a BRA
>    message to the mobile access gateway.
>  If the LMA sets the A bit in the BRI and the MAG processes the
>    BRI message, the MAG MUST send a BRA message to indicate the success
>    or failure of the termination of the mobile node binding.

Inconsistent. If you remove the behavior rules from Section 4, this
won't be a problem any more.

Besides, are you sending a BRA only if it is successfully processed?
What about error cases?

> 6.  Home Agent Operation

Retransmission rules missing.

In general, I would rethink the organization of Sections 6 and onwards.
Focus on describing the behaviour for the BRI and BRA messages first,
and then have another level  of behaviour requirements for the different
application scenarios. Right now, it looks like the same messages have
completely different semantics in the different situations.

Jari

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Mar 2008 09:57:37 -0500

Hi Jari,
Many thanks for the review. Please see comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, March 13, 2008 9:44 AM
> To: [email-masked]; 
> [email-masked]
> Subject: review of the binding revocation draft
> 
> 
> I read the draft. Its basically in good shape as far as the 
> overall approach goes, but there are a number of details that 
> do need work:
> 
> And I'm not sure I understand what the security association 
> details are here. Looks like the mobile node was at another 
> location previously, with other addresses in the relevant SA fields?

[Ahmad]
I agree, we will address the details in the next revision which we are
planning to publish within the next two weeks.
In general, the LMA/HA may have an indication when the MN is coming back
home, for example in the case of multiple care-of-address with one
interface is connected to the home link. The other case, when LMA/HA are
co-located and the MN moves from Client MIPv6 area to PMIPv6 domain,
i.e. when LMA receives a PBU for an existing Client MIP BCE.

> This section has duplicated text for the various cases, e.g., 
> around the requirements for responding to BRIs with the A bit 
> set. It seems that the rules for responding to the BRIs are 
> the same in any case. Focus on explaining the use cases, not 
> specifying behavior rules in this section.

[Ahmad]
We will do. Thanks!

> Inconsistent. If you remove the behavior rules from Section 
> 4, this won't be a problem any more.
> 

[Ahmad]
We will address them in the new revision.

> Focus on describing the behaviour for the BRI and BRA 
> messages first, and then have another level  of behaviour 
> requirements for the different application scenarios. Right 
> now, it looks like the same messages have completely 
> different semantics in the different situations.

[Ahmad]
Again thanks for the review and feedback.  
We will spin a new revision hopefully within a week and at most 2 weeks.

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 14:21:31 +0200

Hi Ahmed:

You have already responded in following email and you are going to
explore furhter in future draft. But here I place what I was trying to
ask you during meeting. Perhaps you may like to consider or you may
clarify if I misunderstood something.

Draft:
'One of the important scenarios that is applicable to Mobile
IPv6protocol [RFC-3775] is when a mobile node returns home.  According
to RFC3775, the mobile node is recommended to send a BU message with
lifetime of zero, however, RFC3775 did not mandate this behavior on the
mobile node.  In this case, if the home agent detects that the mobile
node has returned home but did not send a de-registration BU, the home
agent may send a BRI message to the mobile node using the same security
association that the mobile node and home agent negotiated and used
during the exchange of the initial BU and BA messages.'

-> In addition to comment placed in following email from Jari A. + Do
you think the SA will last long once the BU message with lifetime of
zero is delivered and acked? If not then de-registration BU can not be
delivered securely. 

-> If MN has moved back to home network but HA is has not detected that
,  and by that time if revocation message sent by HA for previous
binding assuming that lifetime of this BU is not expired, then what will
happen? Such thing can also happen during handoff. 

Draft: subsection 4.2.1

-> If BID1....BID4 are sent in single message then there will be single
SA for all care of addresses? 
i.e. index value -> single SA -> multiple binding update. In this case
lifetime for all BU will remain same isn't it? If not then Or I am
missing something here. 

Appreciate your time for this. 

Thanks
Preeti 

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Jari Arkko
>Sent: 13 March, 2008 15:44
>To: [email-masked]; [email-masked]
>Subject: [MEXT] review of the binding revocation draft
>
>
>Inconsistent. If you remove the behavior rules from Section 4, 
>this won't be a problem any more.
>
>Focus on describing the behaviour for the BRI and BRA messages 
>first, and then have another level  of behaviour requirements 
>for the different application scenarios. Right now, it looks 
>like the same messages have completely different semantics in 
>the different situations.
>
>Jari
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Mar 2008 08:38:57 -0500

Hi Preeti,
Thanks for the comments, please see inline.

**** Oh my God! My sincere apology Preeti. I thought that I have sent
this reply but I just found it setting in my draft box. Sorry again.
*****

Regards,
Ahmad

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 19, 2008 7:22 AM
> Subject: RE: [MEXT] review of the binding revocation draft
> 
> Hi Ahmed:
> 
> You have already responded in following email and you are 
> going to explore furhter in future draft. But here I place 
> what I was trying to ask you during meeting. Perhaps you may 
> like to consider or you may clarify if I misunderstood something.
> 
> Draft:
> IPv6protocol [RFC-3775] is when a mobile node returns home.  
> According to RFC3775, the mobile node is recommended to send 
> a BU message with lifetime of zero, however, RFC3775 did not 
> mandate this behavior on the mobile node.  In this case, if 
> the home agent detects that the mobile node has returned home 
> but did not send a de-registration BU, the home agent may 
> send a BRI message to the mobile node using the same security 
> association that the mobile node and home agent negotiated 
> and used during the exchange of the initial BU and BA messages.'
> 
> you think the SA will last long once the BU message with 
> lifetime of zero is delivered and acked? If not then 
> de-registration BU can not be delivered securely.

[Ahmad]
Good question.

That is why, the mobile node SHOULD have sent a BU with lifetime of zero
to start with. However, if the HA has an indication that the mobile node
has returned home and did not send a BU with lifetime zero, then I
assume the HA can continue to use the same SA with the MN in sending the
BRI. Now, let us assume that the MN deleted the SA with the HA without
sending a de-registration and before receiving the BRI, I assume the MN
will drop the BRI and in that case, mission accomplished. All what we
are trying to do here is to make sure that the MN is informed that it no
longer has a Client MIPv6 BCE at the HA with the specified HoA. 

We could add some clarification to some of these race conditions in the
new revision.
 
> ,  and by that time if revocation message sent by HA for 
> previous binding assuming that lifetime of this BU is not 
> expired, then what will happen? Such thing can also happen 
> during handoff. 
> 
> Draft: subsection 4.2.1
> 
> i.e. index value -> single SA -> multiple binding update. In 
> this case lifetime for all BU will remain same isn't it? If 
> not then Or I am missing something here. 

[Ahmad]
I believe also Jari made similar comments on this section. We currently
reviewing the value of specifying special cases in this draft, The
inclination is to keep Binding revocation as generic as possible and let
either other drafts or SDOs top define these special scenario. We can
revisit this one when the new revision is published.

Again thanks for your comments.

Regards,
Ahmad
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >ext Jari Arkko
> details are 
> >This section has duplicated text for the various cases, e.g., around 
> >the requirements for responding to BRIs with the A bit set. It seems 
> >that the rules for responding to the BRIs are the same in any case. 
> >Focus on explaining the use cases, not specifying behavior rules in 
> >this section.
> >'
> >
> messages first, 
> >and then have another level  of behaviour requirements for the 
> >different application scenarios. Right now, it looks like the same 
> >messages have completely different semantics in the different 
> >situations.
> >
> >Jari
> >