Subject: [MEXT] comments on the binding revocation draft

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 21 Mar 2008 14:08:42 +0100

Hi Ahmad,

I reviewed the binding revocation draft, here are my comments:

The draft defines that when BRI message is sent to the MN to revoke a binding for a specific HoA, the HoA is included in the HoA option. The HoA option as used in RFC 3775 is set by the MN and consumed by the CN/HA. In the downlink direction the MN gets its home address from a type 2 RH. I guess the draft could specify a new semantics and behaviour for HoA option. OTOH, it would be more inline with RFC 3775 rules to use the type 2 RH in a BRI instead of the HoA option. Using type 2 RH would also mean less implementation effort as BRI/BRA processing could use the unmodified mobility option processing rules that are already there for BU/Back.

section 4.3.2 Local Mobility Anchor Revokes Bulk PMIPv6 Bindings
> In this case, the local mobility anchor includes the LMA
> IP address in the home address option.  Optionally, the LMA may also
> include its identity in the MN-ID option.

I'm not sure what is the benefit of including the LMA's address or NAI in a BRI message, could this be clarified in the spec?

section 4.3.3.  Mobile Access Gateway Revoke A PMIPv6 Binding
This section is about the MAG sending the PBU with a zero lifetime. I think this is described in other documents and that this document should describe only the handling of BRI/BRA messages. I would suggest to remove this section.

section 7.  Local Mobility Anchor Operation
>   o  In the case of mobile node handover from the source MAG to the
>      target MAG, LMA MAY receive a PBU from the target MAG to update
>      the MN BCE with the new CoA.  After LMA update the MN BCE, LMA
>      SHOULD send a BRI with the P and A bits set and include the mobile
>      node home network prefix in the HNP option and the MN-ID option to
>      indicate to the source MAG to clean up the resources associated
>      with the mobile node.

I think that "LMA SHOULD send a BRI" to an old MAG upon the handover is too strong. There are deployments where the old MAG is aware of MN's handover by means of other mechanisms. I think that MAY instead of SHOULD would be fine. 

section 10.1 Binding Revocation Indication Message
>  Global Per-Peer Bindings (G)
>      The Global Per-Peer Bindings (G) bit is set by the sending
>      mobility node, LMA or MAG, to request the receiving peer mobility
>      node to terminate all mobility sessions created between the two
>      mobility entities.

I guess that if the G bit is set, then no additional options identifiying individual bindings like HNP, BID, etc... should be allowed. Any such option should be either ignored or error indication should be returned to the sender. The exact behaviour should be described.

>  Mobility Options
>      A mobility option(s) that is used to identify a specific binding
>      or bindings that their registration(s) are being revoked; e.g. HNP
>      [PMIP6-SPEC], MN-ID [RFC-4283], Binding ID [Monami6-SPEC], and HoA
>      [RFC-3775] options.

It seems that a BRI message can include, for example, several HNP options. Some HNPs could be /32 thus affecting many MNs, while some other could be /64. In addition there could be a couple of MN-ID options in the same message, etc. This is my reading of this sentence, but it would help if this would be clearly spelled out in a normative language. Related to this, what happens if the recepient of the BRI message for some reason can not remove all of the requested bindings? Can it signal in BRA which bindings were removed and which not? Or is it supposed to remove either all of them or none at all?

section 10.2 Binding Revocation Acknowledgement Message
>  Mobility Options
>      The mobility option(s) usually match those received in the
>      corresponding BRI message.

Instead of the "usually match" formulation, I would like the spec to be more specific as to what mobility options and under which conditions are included in the BRA.

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Mar 2008 11:55:38 -0500

Hi Domagoj,
Thanks for your review and appreciate the comments. 
Please see more inline.

Regards,
Ahmad

> -----Original Message-----
> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Friday, March 21, 2008 8:09 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: [MEXT] comments on the binding revocation draft
> 
> Hi Ahmad,
> 
> The draft defines that when BRI message is sent to the MN to 
> revoke a binding for a specific HoA, the HoA is included in 
> the HoA option. The HoA option as used in RFC 3775 is set by 
> the MN and consumed by the CN/HA. In the downlink direction 
> the MN gets its home address from a type 2 RH. I guess the 
> draft could specify a new semantics and behaviour for HoA 
> option. OTOH, it would be more inline with RFC 3775 rules to 
> use the type 2 RH in a BRI instead of the HoA option. Using 
> type 2 RH would also mean less implementation effort as 
> BRI/BRA processing could use the unmodified mobility option 
> processing rules that are already there for BU/Back.

[Ahmad]
Makes sense. Will review this and make sure that it is addressed.

> > In this case, the local mobility anchor includes the LMA IP 
> address in 
> > the home address option.  Optionally, the LMA may also include its 
> > identity in the MN-ID option.
> 
> I'm not sure what is the benefit of including the LMA's 
> address or NAI in a BRI message, could this be clarified in the spec?

[Ahmad]
I guess we need to decide on this. Because, in order to allow this
Global revocation, we also mentioned that special authorization is
needed. It will be helpful to include the revoking entity identity to
facilitate that.

> This section is about the MAG sending the PBU with a zero 
> lifetime. I think this is described in other documents and 
> that this document should describe only the handling of 
> BRI/BRA messages. I would suggest to remove this section.

[Ahmad]
Well, we also need to allow the MAG to use the Global revocation "G bit"
and revoke multiple binding if necessary. Do not you think so?

> I think that "LMA SHOULD send a BRI" to an old MAG upon the 
> handover is too strong. There are deployments where the old 
> MAG is aware of MN's handover by means of other mechanisms. I 
> think that MAY instead of SHOULD would be fine.

[Ahmad]
No problem here too.
 
> I guess that if the G bit is set, then no additional options 
> identifiying individual bindings like HNP, BID, etc... should 
> be allowed. Any such option should be either ignored or error 
> indication should be returned to the sender. The exact 
> behaviour should be described.

[Ahmad]
I see what you are saying here. In case that the LMA would like to
remove multiple binding but not all, LMA should use the respected
options to communicate that.

> It seems that a BRI message can include, for example, several 
> HNP options. Some HNPs could be /32 thus affecting many MNs, 
> while some other could be /64. In addition there could be a 
> couple of MN-ID options in the same message, etc. This is my 
> reading of this sentence, but it would help if this would be 
> clearly spelled out in a normative language. Related to this, 
> what happens if the recepient of the BRI message for some 
> reason can not remove all of the requested bindings? Can it 
> signal in BRA which bindings were removed and which not? Or 
> is it supposed to remove either all of them or none at all?

[Ahmad]
I believe the main purpose of the revocation mechanism is to some extent
help keeping the different elements of the network in sync with respect
to the MN state. If the MAG, for example, receives a BRI for multiple
bindings and some of these bindings have been removed already, then
mission accomplished anyway. MAG can send a successful BRA. However, I
believe that the revocation mechanism should allow the MAG, for example,
to report certain errors if necessary. Moreover, to allow one BRA to
communicate the response for a single BRI even if it had several options
in it which impact multiple bindings. 

What I mean, a successful BRA, means everything is cool.
A BRA with a status that is related to a specific binding, for example,
is valid as a response for that binding and considered successful for
all other bindings as long as it has the same SQN of the respected BRI.
Does that make sense?

> Instead of the "usually match" formulation, I would like the 
> spec to be more specific as to what mobility options and 
> under which conditions are included in the BRA.

[Ahmad]
Agree. Will fix it.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 25 Mar 2008 17:57:00 +0100

Ahmad,

Please find my comments below, I removed some parts where were seem to be in sync...

[snip]
> address or NAI 
> > in a BRI message, could this be clarified in the spec?
> 
> [Ahmad]
> I guess we need to decide on this. Because, in order to allow 
> this Global revocation, we also mentioned that special 
> authorization is needed. It will be helpful to include the 
> revoking entity identity to facilitate that.

I was thinking that the security association protecting the revocation message is enough to identify the revoking entity. If there are use cases where the explicit notificaton of the LMA's NAI or address is useful, I'm fine with keeping this as an option.

[snip]
> > section 4.3.3.  Mobile Access Gateway Revoke A PMIPv6 Binding This 
> > section is about the MAG sending the PBU with a zero 
> lifetime. I think 
> > this is described in other documents and that this document should 
> > describe only the handling of BRI/BRA messages. I would suggest to 
> > remove this section.
> 
> [Ahmad]

A MAG sending a BRI with G bit set is described in the next section, 4.3.4. Section 4.3.3 talks about sending PBU with lifetime set to 0. Anyway, I have no strong opinion, it just seemed redundant to me.

[snip]
> > identifiying individual bindings like HNP, BID, etc... should be 
> > allowed. Any such option should be either ignored or error 
> indication 
> > should be returned to the sender. The exact behaviour should be 
> > described.
> 
> [Ahmad]
> I see what you are saying here. In case that the LMA would 
> like to remove multiple binding but not all, LMA should use 
> the respected options to communicate that.

Yes. And the other way around, if the G bit is set, then no other options identifying individual bindings should be allowed in the BRI message. 

[snip]
> > Related to this, what happens if the recepient of the BRI 
> > message for some reason can not remove all of the requested 
> > bindings? 
> A BRA with a status that is related to a specific binding, 
> for example, is valid as a response for that binding and 
> considered successful for all other bindings as long as it 
> has the same SQN of the respected BRI.
> Does that make sense?

OK, the sender of the BRA puts only those mobility options in the BRA for which it couldn't remove the corresponding bindings and puts an error indication in the status code. All bindings that were not removed share the same error code? Probably a cleaner approach would be to include a separate status code for each of the failed options, but I guess that for most of the practical scenarios the method you proposed will work just fine. 

domagoj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Mar 2008 14:45:32 -0500

Domagoj,
Comments inline, please.
> I was thinking that the security association protecting the 
> revocation message is enough to identify the revoking entity. 
> If there are use cases where the explicit notificaton of the 
> LMA's NAI or address is useful, I'm fine with keeping this as 
> an option.
> 
> [snip]

> A MAG sending a BRI with G bit set is described in the next 
> section, 4.3.4. Section 4.3.3 talks about sending PBU with 
> lifetime set to 0. Anyway, I have no strong opinion, it just 
> seemed redundant to me.

[Ahmad]
Hmmm that means the authorization for the ability to send a Global
revocation is tied to the IPsec SA. I would prefer to have an explicit
indication in the revocation message itself, because the IPsec between
the MAG and LMA could be used for multiple purposes and it is better to
keep the authorization for Global revocation limited to the revocation
signaling. Do not you think?

> Yes. And the other way around, if the G bit is set, then no 
> other options identifying individual bindings should be 
> allowed in the BRI message. 

[Ahmad]
That should work!

> 
> [snip]
> > > Related to this, what happens if the recepient of the BRI message 
> > > for some reason can not remove all of the requested bindings?
> > A BRA with a status that is related to a specific binding, for 
> > example, is valid as a response for that binding and considered 
> > successful for all other bindings as long as it has the same SQN of 
> > the respected BRI.
> > Does that make sense?
> 
> OK, the sender of the BRA puts only those mobility options in 
> the BRA for which it couldn't remove the corresponding 
> bindings and puts an error indication in the status code. All 
> bindings that were not removed share the same error code? 
> Probably a cleaner approach would be to include a separate 
> status code for each of the failed options, but I guess that 
> for most of the practical scenarios the method you proposed 
> will work just fine.

[Ahmad]
I guess this should be taken inline with the following thought, if the
action requested by the revokee has incidentally been executed by other
means, i.e. resources have been released inline with the revokee BRI,
then the MAG should not report any error about that binding.  If there
is an error to be reported, IMO, one status code should be enough.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 26 Mar 2008 11:01:22 +0100

Hi Ahmad,

> [Ahmad]
> Hmmm that means the authorization for the ability to send a 
> Global revocation is tied to the IPsec SA. I would prefer to 
> have an explicit indication in the revocation message itself, 
> because the IPsec between the MAG and LMA could be used for 
> multiple purposes and it is better to keep the authorization 
> for Global revocation limited to the revocation signaling. Do 
> not you think? 

My thinking was that authorization is tied to the proven identity, otherwise a compromised MAG/LMA could revoke all sessions of another MAG/LMA by simple putting the IP address/MN-ID of that another MAG/LMA in the BRI.

domagoj

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: 25. ozujak 2008 20:46
> To: Premec, Domagoj
> Cc: [email-masked]
> Subject: RE: [MEXT] comments on the binding revocation draft
> 
> Domagoj,
> Comments inline, please.
> > 
> > [snip]
> revocation 
> > message is enough to identify the revoking entity.
> > If there are use cases where the explicit notificaton of 
> the LMA's NAI 
> > or address is useful, I'm fine with keeping this as an option.
> > 
> > [snip]
> > > Well, we also need to allow the MAG to use the Global 
> revocation "G 
> > > bit"
> section, 
> > 4.3.4. Section 4.3.3 talks about sending PBU with lifetime 
> set to 0. 
> > Anyway, I have no strong opinion, it just seemed redundant to me.
> 
> [Ahmad]
> Hmmm that means the authorization for the ability to send a 
> Global revocation is tied to the IPsec SA. I would prefer to 
> have an explicit indication in the revocation message itself, 
> because the IPsec between the MAG and LMA could be used for 
> multiple purposes and it is better to keep the authorization 
> for Global revocation limited to the revocation signaling. Do 
> not you think?
> 
> > 
> > [snip]
> > Yes. And the other way around, if the G bit is set, then no other 
> > options identifying individual bindings should be allowed 
> in the BRI 
> > message.
> 
> [Ahmad]
> That should work!
> 
> > 
> > [snip]
> > OK, the sender of the BRA puts only those mobility options 
> in the BRA 
> > for which it couldn't remove the corresponding bindings and puts an 
> > error indication in the status code. All bindings that were not 
> > removed share the same error code?
> status code 
> > for each of the failed options, but I guess that for most of the 
> > practical scenarios the method you proposed will work just fine.
> 
> [Ahmad]
> I guess this should be taken inline with the following 
> thought, if the action requested by the revokee has 
> incidentally been executed by other means, i.e. resources 
> have been released inline with the revokee BRI, then the MAG 
> should not report any error about that binding.  If there is 
> an error to be reported, IMO, one status code should be enough.
>  
> > 
> > domagoj
> > 
> > 
>

---

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

> > the MAG and LMA could be used for multiple purposes and it 
> is better 
> > to keep the authorization for Global revocation limited to the 
> > revocation signaling. Do not you think?
> 
> My thinking was that authorization is tied to the proven 
> identity, otherwise a compromised MAG/LMA could revoke all 
> sessions of another MAG/LMA by simple putting the IP 
> address/MN-ID of that another MAG/LMA in the BRI.

[Ahmad]
Hi Domagoj,

BUT how that resolve the issue of a compromised MAG?
In this case, a compromised MAG will not be able to revoke any bindings
without, at least, having an IPsec already established with the LMA.
IMO, I do not think including the identity or not including it is going
to have any impact on the compromised MAG case.

Regards,
Ahmad

> > the MAG and LMA could be used for multiple purposes and it 
> is better 
> > to keep the authorization for Global revocation limited to the 
> > revocation signaling. Do not you think?
> > 
> > > 
> > > [snip]
> thought, if the 
> > action requested by the revokee has incidentally been executed by 
> > other means, i.e. resources have been released inline with 
> the revokee 
> > BRI, then the MAG should not report any error about that 
> binding.  If 
> > there is an error to be reported, IMO, one status code should be 
> > enough.
> >  
> > > 
> > > domagoj
> > > 
> > > 
> > 
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 26 Mar 2008 15:06:06 +0100

Ahmad,

I'm confused, I'm probably missing some details on the usage scenario. I was thinking of the following case: there are two MAGs, MAG1 and MAG2, and they are connected to the LMA1 and have valid IPsec SA with the LMA1. The MAG1 is compromised and sends BRI with G bit set and MN-ID option containing the ID of MAG2. Would the LMA remove bindings associated with MAG2? 

domagoj

> Sent: 26. ozujak 2008 14:30
> To: Premec, Domagoj
> Cc: [email-masked]
> > My thinking was that authorization is tied to the proven identity, 
> > otherwise a compromised MAG/LMA could revoke all sessions 
> of another 
> > MAG/LMA by simple putting the IP address/MN-ID of that 
> another MAG/LMA 
> > in the BRI.
> 
> [Ahmad]
> Hi Domagoj,
> 
> In this case, a compromised MAG will not be able to revoke 
> any bindings without, at least, having an IPsec already 
> established with the LMA.
> IMO, I do not think including the identity or not including 
> it is going to have any impact on the compromised MAG case.
> 
> Regards,
> Ahmad
> 
> > 
> > domagoj
> > 
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Mar 2008 00:57:49 -0500

Domagoj,

Oh, I see what you are saying now.

Hi Domagoj,

In my mind, the identity is to validate if the MAG is authorized to send
a Global revocation or not. However, that identity does not specify the
affected mobile nodes BCEs. To answer your question, MAG1 will not be
able to revoke Mobile Nodes that are attached to MAG2 by simply sending
a BRI from MAG1 with MAG2-ID included. BTW: If the consensus later not
to include anything and rely on the IPsec, that is absolutely fine with
me.

I am sure we need to have some text to be added to define how the LMA,
e.g. need to identify all of the affected MN BCEs when the G bit is set.

Regards,
Ahmad

> Sent: Wednesday, March 26, 2008 9:06 AM
> I'm confused, I'm probably missing some details on the usage 
> scenario. I was thinking of the following case: there are two 
> MAGs, MAG1 and MAG2, and they are connected to the LMA1 and 
> have valid IPsec SA with the LMA1. The MAG1 is compromised 
> and sends BRI with G bit set and MN-ID option containing the 
> ID of MAG2. Would the LMA remove bindings associated with MAG2? 
> 
> domagoj
> 
> 
> identity, 
> > In this case, a compromised MAG will not be able to revoke any 
> > bindings without, at least, having an IPsec already 
> established with 
> > the LMA.
> > IMO, I do not think including the identity or not including it is 
> > going to have any impact on the compromised MAG case.
> > 
> > Regards,
> > Ahmad
> > 
> > > 
> > > domagoj
> > > 
> > >