Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend)

From: "Benjamin Lim" <[email-masked]>
Date: Sat, 17 May 2008 15:41:48 +0800

Sorry due to some formatting error in my client. I resend my  previous mail.

> -----Original Message-----
>  Hi Ahmad,
>  
> I snipped sections from the draft to reflect some comments (mostly 
> editorial).
> 
> Regards,
> Benjamin Lim
> 
> ----------
> 
> 3.1.  Binding Revocation Protocol
> 
> ...
> On the other hand, the mobility access gateway usually sends a de- 
> registration message by sending a Proxy BU with a lifetime of zero to 
> indicate to the local mobility anchor of the termination of the
> PMIPv6 mobile node binding registration.  In this case, the mobility 
> access gateway include the MN home network prefix option and the MN-ID 
> option as per [2] in order for the local mobility anchor to identify 
> the mobile node
> PMIPv6 binding.  However, in the case when the mobility access gateway 
> communicates a bulk termination of PMIPv6 sessions, the mobility 
> access gateway sends a BRI message with the G bit set and includes the 
> mobility access gateway identity in the MN-ID option.  When the local 
> mobility anchor receives such BRI message, it ensures that the 
> mobility access gateway is authorized to send such bulk termination 
> message and then process the BRI message accordingly.  If the local 
> mobility anchor processes the BRI message successfully and the (A) bit 
> is set in the BRI, the local mobility anchor responds to the mobile 
> access gateway by sending a BRA message.
> Aditionally, the initiator of the binding revocation
  
[Ben] s / Aditionally/ Additionally
>  
> procedure include an indication in the Revocation Trigger field to 
> indicate to the receiving node the cause for the revocation procedure.
> 
> ...
>  
> 3.3.1.  Termination of Multiple Care-of Addresses Bindings
> 
> In the case of multiple care-of addresses, the home agent maintains 
> different binding for each pair of care-of address and home address.
> These bindings are also indexed and identified during the mobile node 
> registration using a new Binding ID mobility option [5].  In this 
> case, the home agent may revoke any binding, more than one binding, or 
> all of the bindings for the same mobile node home address.
> 
[Ben] Suggest reword above sentence to "In this case, the home agent may
revoke either one or multiple of the mobile node's binding associated to the
mobile node's home address."
> 
> ...
>  
> Figure 2: Home Agent Revokes MN's Specific Registered Care-of 
> Addresses Bindings
> 
[Ben] What is 'Cause' specified in the BRA from MN to HA?
> 
> ...
> 
> 3.4.1.  Local Mobility Anchor Revokes A PMIPv6 Binding
> 
> The local mobility anchor may send a BRI message to the mobile access 
> gateway, hosting a specific proxy mobile IPv6 session, with the 
> appropriate value in the revocation trigger field to indicate that the 
> mobile node binding has been terminated and the mobile access gateway 
> can clean up the applicable resources.  When the mobile access gateway 
> receives a BRI message, the MAG identify the respected
                                                                        
[Ben]  s /respected /respective
>  
> binding and if the A bit was set in the received BRI message, the MAG 
> sends a BRA message to the LMA.  In this case, the MAG could send a 
> Router Advertisement message to the MN with the home network prefix 
> lifetime is set to zero.
>  
> As an example, Figure 3, illustrates the message sequence for revoking 
> a mobile node binding at the source MAG during the MN inter- MAG 
> handoff.
> During the inter-MAG handoff, the mobile node moves from the source 
> MAG to the target MAG.  The target MAG sends a PBU with the new 
> care-of-address to the LMA to update the mobile node point of 
> attachement.  Since the MN binding at the LMA

[Ben] s /attachement / attachment
> 
> points to the
> source MAG and upon receiving the PBU from the target MAG, LMA updates 
> the MN BCE and send a PBA to the target MAG.  LMA can send a BRI 
> message with the appropriate revocation trigger value, e.g.
> inter-MAG handoff indication, to the source MAG in order to clean up 
> the applicable resources reserved for the specified MN.  The MAG 
> acknowledges the BRI message by sending a BRA message to indicate the 
> success or failure of the termination of the mobile node binding.
>  
> The process identified above can also be used by the LMA in scenarios 
> other than the inter-MAG handoff with the propoer

[Ben] s / propoer / proper
> 
> revocation trigger
> value to indicate to the peer MAG that a specific proxy mobile IPv6 
> binding or bindings have been revoked.
>  
> Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff
>  
[Ben] What is 'Cause' specified in the BRA from sMAG to LMA?
>  
> ...
>  
> 3.4.3.  Mobile Access Gateway Revoke Bulk PMIPv6 Bindings
>  
> The mobile access gateway send a de-registration PBU with lifetime of 
> zero as described in [2] to indicated to the LMA the termination of a 
> mobile node registration binding.
> However, the mobile access gateway sends a BRI message with the G bit 
> is set to indicate that all mobility sessions which are registered at 
> the LMA and attached to the MAG are being revoked as in Section 9.2.1.
> When the LMA receives a BRI message with the G bit is set from a 
> specified MAG, the LMA checks if the MAG is authorized to use global 
> revocations and responds with the approporiate status code by sending

[Ben] s/ approporiate / appropriate
>  
> a BRA message as in Section 8.2.2.
>  
> ...
> 
> 5.1.  Binding Revocation Indication Message
>  
> ...
> Binding ID mobility option [5].  This option is mandatory if the 
> sending mobility entity request to terminate one binding of a multi 
> care-of addresses bindings for the same mobile node.
> 
[Ben] Suggest reword above sentence to "This option is mandatory if the
sending mobility entity request to terminate a multiple care-of address
registered binding of a mobile node."
>  
> The sending Mobility entity may include more than one of these 
> mobility options.
>  
> ...
>  
> 6.1.  Sending Binding Revocation Messages
>  
> When a mobility entity initiate the binding revocation process by 
> sending a Binding Revocation Indication, the initiator MUST construct 
> the BRI message as described in Section 5.1.  In the BRI message, the 
> initiator MUST set the Sequence Number field to the next sequence 
> number available for Binding Revocation.  Since sending Binding 
> Revocation Indication messages is not done on a regular basis, a 16 
> bit sequence number field is large enough to allow the initiator to 
> match the Binding Revocation Acknowledgement to the outstanding 
> Binding Revocation Indication with (A) bit set using the seqeuence

[Ben] s / seqeuence / sequence
>  
> number field only.
>  
> ...
>  
> 6.3.  Retransmission of Binding Revocation Indication
>  
> If the sending mobility entity does not receive a Binding Revocation 
> Acknowledgement in response to the outstanding Binding Revocation 
> Indication before the MINDelayBRIs timer expires, the mobility entity, 
> e.g.  LMA, may retransmit the same BRI message upto the

[Ben] s/ upto / up to
>  
> BRIMaxRetriesNumber as defined in Section 11.  If the revoking 
> mobility entity does not receive a BRA message after the maximum 
> number of retrasmits have been sent, the revoking
                 
[Ben] s/ retrasmits have been sent / retransmissions

> 
> mobility entity can
> clean the mobile node binding cache and all resources associated with 
> this binding.  The revoking mobility entity may log the event.
> 
> ...
> 
> 7.2.  Receiving Binding Revocation Acknowledgement
> 
> ...
> 
> If the Status field indicates any value other than success, the home 
> agent SHOULD examine any mobility options included in the Binding 
> Revocation Acknowledgement.  The home agent MAY log the approriate

[Ben] s / approriate / appropriate
> 
> event to reflect the status of the received BRA.
>  
> ...
> 
> 8.1.1.  Sending Binding Revocation Indication
> 
> ...
> 
> When the local mobility anchor needs to revoke all mobile nodes proxy 
> BCE that belong to a specific realm, e.g.
> @companyabc.com, and are registered with the local mobility anchor and 
> hosted at the mobile access gateway,
>  
[Ben] Suggest reword the above to "When the local mobility anchor needs to
revoke all currently registered mobile nodes proxy BCE that  belong to a
specific realm ([email-masked]) at a particular mobile access gateway,"
>  
> the local mobility anchor MUST set the Global (G) bit and the value of 
> the Revocation Trigger field to Local Policy.  In this case, the local 
> mobility anchor MUST include a mobility option to identify the 
> impacted bindings, e.g.  MN-ID option with a wildcard NAI, e.g.
> [email-masked], to identify all the mobile nodes BCEs that need to 
> be removed.
>  
[Ben] Is there such a thing as a wildcard NAI? Why can't the LMA just
include every single affect MN-ID as an option in the BRI?
>  
> ...
>  
> 8.2.1.  Receiving Binding Revocation Indication
>  
> ...
>  
> The Revocation Trigger field value in the received Binding Revocation 
> Indication could be used by the local mobility anchor to log an event 
> or update some local parameters which tracks the satate of the peer

[Ben] s / satate / state  
>  
> mobile access gateway.
>  
> ...
>  
> 9.1.2.  Sending Binding Revocation Acknowledgement
>  
> ...
> 
> When the mobile access gateway receive a valid Binding Revocation

[Ben] s / receive / receives
>  
> Indication with the (A) bit is set and after processing the BRI 
> message, the mobile access gteway sends a packet to the local

[Ben] s/ gteway / gateway
>  
> mobility anchor containing a Binding Revocation Acknowledgement 
> according to the procedure in Section 6.1 and the following:
> 
> ...
>  
> 9.2.1.  Sending Binding Revocation Indication
>  
> ...
>  
> The mobile access gateway send a Binding Revocation Indication when it 
> needs to use global revocation, i.e. when the G bit is set.  In this 
> case when an event occurs which requires the mobile access gateway to 
> inform the local mobility anchor to terminate all mobile nodes 
> bindings that are registered at the local mobility anchor and the 
> mobile access gateway, the mobile access gateway send a Binding 
> Revocation Inidcation message following Section 6.1 and the

[Ben] s / Inidcation / Indication
follwoing:

[Ben] s / follwoing / following:
>  
> ...
>  
> 9.2.2.  Receiving Binding Revocation Acknowledgement
> 
> ...
> 
> If the Status field indicates (Global Revocation NOT Authorized), the 
> mobile access gateway is not authorized to participate in a Per-Peer 
> Global Revocation.  The mobile access gateway SHOULD NOT retry sending 
> a Binding Revocation Inidication with the Global (G)

[Ben] s / Inidication / Indication
>  
> bit is set to the same local mobility agent.  The mobile access 
> gateway should raise an alarm or log an event to indicate this 
> rejection.
>  
> ...
> 
> 10.1.  Receiving Binding Revocation Indication
> 
> ...
> 
> If the mobile node has registered multiple care-of addresses with its 
> home agent, the mobile node MUST verify which binding is being revoked 
> by examining the content of the BRI message.  If the mobile node 
> received a Binding Revocation Indication with a single or more than 
> one BID options and its home adress is in the Home Address option,
>  
[Ben] Suggest reword above to "If the mobile node receives a Binding
Revocation Indication containing either a single or multiple BID options
that is associated to its home address specified in the Home Address
option,"
> 
> the mobile node MUST consider its bindings identified in the Binding 
> ID options are being revoked.

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 20 May 2008 07:10:03 -0500

Hi Ben,

Thanks for the review, Appreciate it! please see comments inline.

Regards,
Ahmad

> From: Benjamin Lim [mailto:[email-masked]] 
> Sent: Saturday, May 17, 2008 2:42 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: RE: [MEXT] FW: I-D 
> Action:draft-muhanna-mext-binding-revocation-01.txt (Resend)
> 

[Ahmad]
Thx.
> [Ben] Suggest reword above sentence to "In this case, the 
> home agent may revoke either one or multiple of the mobile 
> node's binding associated to the mobile node's home address."
> >
[Ahmad]
Thanks. That is a better choice of words.
 
> [Ben] What is 'Cause' specified in the BRA from MN to HA?

[Ahmad]
Thanks for spotting this! That actually should be status=success.

> [Ben]  s /respected /respective
[Ahmad]
Ok.

> [Ben] s /attachement / attachment
[Ahmad]
Ok.

> [Ben] s / propoer / proper
[Ahmad]
I am not sure how that slipped the spell check. It seems that many did:)

> [Ben] What is 'Cause' specified in the BRA from sMAG to LMA?
[Ahmad]
Thx. Similar to the above, status= success.

> [Ben] s/ approporiate / appropriate
[Ahmad]
Ok. Thx.

> [Ben] Suggest reword above sentence to "This option is 
> mandatory if the sending mobility entity request to terminate 
> a multiple care-of address registered binding of a mobile node."
[Ahmad]
Thx. Will adopt the proposed text.

> [Ben] s / seqeuence / sequence
[Ahmad]
Ok.

> > e.g.  LMA, may retransmit the same BRI message upto the
[Ahmad]
Ok.

> [Ben] s/ retrasmits have been sent / retransmissions
[Ahmad]
Thanks!
> [Ben] s / approriate / appropriate
[Ahmad]
Ok.

> [Ben] Suggest reword the above to "When the local mobility 
> anchor needs to revoke all currently registered mobile nodes 
> proxy BCE that  belong to a specific realm 
> ([email-masked]) at a particular mobile access gateway,"
[Ahmad]
Thanks again, will adopt the text.

> [Ben] Is there such a thing as a wildcard NAI? Why can't the 
> LMA just include every single affect MN-ID as an option in the BRI?
[Ahmad]

What I meant by wildcard NAI is something like "[email-masked]". I believe
allowing this is useful. If the LMA would like to revoke all mobile
nodes by including multiple MN-IDs, I believe that is allowed, if the
text is not clear, we will fix it.

> > or update some local parameters which tracks the satate of the peer
[Ahmad]
Thanks.

> [Ben] s / receive / receives
[Ahmad]
Ok.
> [Ben] s/ gteway / gateway
[Ahmad]
Ok.

> [Ben] s / Inidcation / Indication
[Ahmad]
Ok.

> [Ben] s / follwoing / following:
[Ahmad]
Ok.

> [Ben] s / Inidication / Indication
[Ahmad]
Ok.

> [Ben] Suggest reword above to "If the mobile node receives a 
> Binding Revocation Indication containing either a single or 
> multiple BID options that is associated to its home address 
> specified in the Home Address option,"
[Ahmad]
Thanks.

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 22 May 2008 10:24:15 +0800

Hi Ahmad,

Reply to one of your comment. I snip out the part. 

=8==8<=8==  
> What I meant by wildcard NAI is something like 
> "[email-masked]". I believe allowing this is useful. If the LMA 
> would like to revoke all mobile nodes by including multiple 
> MN-IDs, I believe that is allowed, if the text is not clear, 
> we will fix it.
[Ben] Ok I get your idea. Meaning a NAI that represent a group of MNs belong
to a particular domain. I suggest the following wording then.

...

...
<Old text>

In this case, the local mobility anchor MUST include a mobility option to
identify the impacted bindings, e.g.  MN-ID option with a wildcard NAI, e.g.
[email-masked], to identify all the mobile nodes BCEs that need to be
removed.

<New Text>

In this case, the local mobility anchor MUST include a mobility option to
identify the impacted bindings. For example, if the local mobility anchor
wants to revoke the bindings of all mobile nodes from a particular domain
(companyabc.com), the local mobility anchor would include multiple MN-ID
options to reflect the NAI of the affect mobile nodes. Another way for the
local mobility anchor to revoke all bindings from companyabc.com would be to
use a special NAI that represent mobile nodes from this domain. For this,
the local mobility anchor would only include a single MN-ID option
containing this special NAI to identify all the mobile nodes BCEs that need
to be removed.

How does this sound?

Regards,
Benjamin Lim

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 22 May 2008 07:59:43 -0500

Hi Ben,

The text looks good. In the next revision, "hopefully as a wg document"
I will make sure that the intent of the text is captured.

Again, Many thanks for your review.

Regards,
Ahmad

> Sent: Wednesday, May 21, 2008 9:24 PM
> > What I meant by wildcard NAI is something like "[email-masked]". I 
> > believe allowing this is useful. If the LMA would like to 
> revoke all 
> > mobile nodes by including multiple MN-IDs, I believe that 
> is allowed, 
> > if the text is not clear, we will fix it.
> [Ben] Ok I get your idea. Meaning a NAI that represent a 
> group of MNs belong to a particular domain. I suggest the 
> following wording then.
> 
> ...
> 
> In this case, the local mobility anchor MUST include a 
> mobility option to identify the impacted bindings, e.g.  
> MN-ID option with a wildcard NAI, e.g.
> [email-masked], to identify all the mobile nodes BCEs that 
> need to be removed.
> 
> <New Text>
> 
> In this case, the local mobility anchor MUST include a 
> mobility option to identify the impacted bindings. For 
> example, if the local mobility anchor wants to revoke the 
> bindings of all mobile nodes from a particular domain 
> (companyabc.com), the local mobility anchor would include 
> multiple MN-ID options to reflect the NAI of the affect 
> mobile nodes. Another way for the local mobility anchor to 
> revoke all bindings from companyabc.com would be to use a 
> special NAI that represent mobile nodes from this domain. For 
> this, the local mobility anchor would only include a single 
> MN-ID option containing this special NAI to identify all the 
> mobile nodes BCEs that need to be removed.
> 
> How does this sound?
> 
> Regards,
> Benjamin Lim
> 
> 
>

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 28 May 2008 17:07:58 +0800

Hi Ahmad, 

Ok. I will await the next revision then. Base on my review, I feel that this
draft should be ready for WG call. I leave it up to the chairs and WG to
decide.

Regards,
Benjamin Lim

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2008 9:00 PM
> To: Benjamin Lim
> Cc: [email-masked]
> group of MNs 
> > belong to a particular domain. I suggest the following wording then.
> > 
> > ...
> > 
> mobility option 
> > to identify the impacted bindings. For example, if the 
> local mobility 
> > anchor wants to revoke the bindings of all mobile nodes from a 
> > particular domain (companyabc.com), the local mobility anchor would 
> > include multiple MN-ID options to reflect the NAI of the 
> affect mobile 
> > nodes. Another way for the local mobility anchor to revoke all 
> > bindings from companyabc.com would be to use a special NAI that 
> > represent mobile nodes from this domain. For this, the 
> local mobility 
> > anchor would only include a single MN-ID option containing this 
> > special NAI to identify all the mobile nodes BCEs that need to be 
> > removed.
> > 
> > How does this sound?
> > 
> > Regards,
> > Benjamin Lim
> > 
> > 
> > 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 28 May 2008 07:58:25 -0500

Thanks Ben!
Will make sure the proposed changes is captured in the new revision.

On adopting this draft as a wg doc; Yes, we are waiting for the chairs
guidance on the next step.

Thanks again.

Regards,
Ahmad

> Sent: Wednesday, May 28, 2008 4:08 AM
> Ok. I will await the next revision then. Base on my review, I 
> feel that this draft should be ready for WG call. I leave it 
> up to the chairs and WG to decide.
> 
> Regards,
> Benjamin Lim
> 
> "[email-masked]". I 
> > > to identify the impacted bindings, e.g.

---

From: Frank Xia <[email-masked]>
Date: Wed, 28 May 2008 09:19:07 -0500

Hi Ahmad

I think the draft is good enough to advance.

Just one question,  is the draft  applicable to
WiMAX(or 3GPP2) in which IPsec is not mandatory?

BR
Frank

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 28 May 2008 09:33:56 -0500

Hi Frank,

Yes. It is applicable.

The intent of the draft is that BRI and BRA are secured using the same
security association that was used for protecting the BU/BA. If it is
not clear, we will make sure that it is captured.

Regards,
Ahmad

> From: Frank Xia [mailto:[email-masked]] 
> Sent: Wednesday, May 28, 2008 9:19 AM
> Just one question,  is the draft  applicable to WiMAX(or 
> 3GPP2) in which IPsec is not mandatory?
> 
> BR
> Frank
> 
> 
> >> Ok. I will await the next revision then. Base on my review, I feel 
> >> that this draft should be ready for WG call. I leave it up to the 
> >> chairs and WG to decide.
> >>
> >> Regards,
> >> Benjamin Lim
> >>