Subject: [MEXT] Global Binding Revocation initiated by MAG

From: "Magesh Shanmugam" <[email-masked]>
Date: Wed, 10 Dec 2008 12:24:30 +0530

Ahmad
 
In PMIPv6 domain, when MAG initiates Global Binding Revocation (G bit set),
it will send the MAG identity in the MN-ID option (as per section 3.1 of
binding-revocation draft-02).
 
As per RFC 5213, while creating Binding Cache Entry @ LMA, we have MN-ID,
HNP(s), Proxy Care of Address, etc in the received PBU message which will be
updated in the
BC entry after validation.  MAG-ID will not be stored in the Binding Cache
Entry when individual binding session(s) are processed and validated by LMA.

When MAG triggers Global Binding Revocation, it will send the MAG-ID in the
MN-ID option.  Since LMA won't maintain the MAG-ID for each binding session
(i.e. in BC entry), 
it will be tough for the LMA to identify all the binding(s) from the
specific MAG.  
 
Instead of having MAG-ID in the MN-ID option for Global Revocation, if we
use Proxy Care of Address (through the source IP address of the BRI message
or 
Alternate Care of Address mobility option, if source address is different
from proxy care of address), it will be easy for LMA to retrieve all the
binding(s), 
since Proxy Care of Address is stored in the Binding Cache entry.
 
Thanks
S Magesh
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Dec 2008 16:07:41 -0600

Magesh,
 
Sorry for the late response. Had to travel for a short trip.
 
I see what you are saying here. May be what we need to do is to take one
step back and look into the reason for the Global revocation.
 
The intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to
inform the other to revoke all bindings that is served by these two
nodes or a partial number of these binding, for example proxy MIP6
bindings that have their MN-ID which belong to a specific realm, e.g.,
([email-masked]). 
 
When the 'G' bit is used for a partial Global revocation, "Revoking Node
Local Policy", the draft requires that another identifier MUST be
included in the BRI which is used to identify these proxy bindings. I
believe that we do not have any problem in that one. Right?
 
When the 'G' bit is used for a Global revocation and in line with the
above logic, we need to communicate the MAG-ID. I understand that
currently we do not have a mobility option specific to carry MAG-ID,
however, we defined a very specific scenario where the 'G' bit is set
and the R. Trigger is set to "per-peer policy". Only in this case, the
draft currently allow the MAG to include its ID in the MN-ID option.
Sending the BRI and BRA is assumed to follow the exact procedure for PBU
and PBA with respect to the source and dest. IP addresses.
 
On the other hand, I see your point of defining a default mechanism to
be used by the received Node to identify all these proxy Bindings. IMO,
we need probably to have a generic approach that applicable to all
cases. for example, a MAG may have more than one pCoA with a specific
LMA. As a suggestion, I would recommend, in this case ONLY that the pCoA
always be included in the Alternate CoA option in the BRI. Additionally,
when the MAG share more than one pCoA, the MAG MUST include each pCoA in
a separate Alternate-CoA option.
 
Does sound acceptable? 
 
As a side note, implementations may have their own mechanism where the
MAG-ID is somehow known to the LMA, for example, and that implementation
would identify all of the proxy Binding that are served at that MAG
using the MAG-ID, but that is out of scope.

Regards, 
Ahmad 

________________________________

	From: Magesh Shanmugam [mailto:[email-masked]] 
	Sent: Wednesday, December 10, 2008 12:55 AM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: [email-masked]
	Subject: Global Binding Revocation initiated by MAG

	Ahmad
	 
	In PMIPv6 domain, when MAG initiates Global Binding Revocation
(G bit set), it will send the MAG identity in the MN-ID option (as per
section 3.1 of binding-revocation draft-02).
	 
	As per RFC 5213, while creating Binding Cache Entry @ LMA, we
have MN-ID, HNP(s), Proxy Care of Address, etc in the received PBU
message which will be updated in the
	BC entry after validation.  MAG-ID will not be stored in the
Binding Cache Entry when individual binding session(s) are processed and
validated by LMA.  
	When MAG triggers Global Binding Revocation, it will send the
MAG-ID in the MN-ID option.  Since LMA won't maintain the MAG-ID for
each binding session (i.e. in BC entry), 
	it will be tough for the LMA to identify all the binding(s) from
the specific MAG.  
	 
	Instead of having MAG-ID in the MN-ID option for Global
Revocation, if we use Proxy Care of Address (through the source IP
address of the BRI message or 
	Alternate Care of Address mobility option, if source address is
different from proxy care of address), it will be easy for LMA to
retrieve all the binding(s), 
	since Proxy Care of Address is stored in the Binding Cache
entry.
	 
	Thanks
	S Magesh

---

From: "Magesh Shanmugam" <[email-masked]>
Date: Fri, 12 Dec 2008 11:20:02 +0530

Ahmad
 
Thanks for the response.  Please see my comments inline.
 
Regards
S Magesh

  _____  

From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Friday, December 12, 2008 3:38 AM
To: Magesh Shanmugam
Cc: [email-masked]
Subject: RE: Global Binding Revocation initiated by MAG

Magesh,

 
The intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to
inform the other to revoke all bindings that is served by these two nodes or
a partial number of these binding, for example proxy MIP6 bindings that have
their MN-ID which belong to a specific realm, e.g., ([email-masked]). 
 
When the 'G' bit is used for a partial Global revocation, "Revoking Node
Local Policy", the draft requires that another identifier MUST be included
in the BRI which is used to identify these proxy bindings. I believe that we
do not have any problem in that one. Right?
 
[Magesh] I agree with your above statement.
 
When the 'G' bit is used for a Global revocation and in line with the above
logic, we need to communicate the MAG-ID. I understand that currently we do
not have a mobility option specific to carry MAG-ID, however, we defined a
very specific scenario where the 'G' bit is set and the R. Trigger is set to
"per-peer policy". Only in this case, the draft currently allow the MAG to
include its ID in the MN-ID option. Sending the BRI and BRA is assumed to
follow the exact procedure for PBU and PBA with respect to the source and
dest. IP addresses.
 
[Magesh] I'm not in favour of having a new mobility option for carrying the
MAG-ID, my concern is if MAG-ID is carried in the BRI message, how does LMA
knows all the binding session(s) related to that particular MAG (your point
here is implementation dependent).  Since from RFC5213 , it is clear that
Binding Cache & Policy Profile does not maintain the MAG-ID, i feel it is
better to add a statement in Binding Revocation draft regarding the way
MAG-ID is handled by LMA for identifying all the binding session(s).
 
In the vice versa case (i.e. LMA sending Global Revocation to MAG with
Revocation Trigger set to "Per-Peer Policy" ), the BRI triggered by LMA will
not have any mobility option(s).  When MAG receives the
BRI, based on the LMAA (i.e. source address in the received BRI message), it
will retrieve all the binding session(s) and revoke them.  I just need the
same kind of procedure when MAG sends BRI with status set to "Per-Peer
Policy".
 
On the other hand, I see your point of defining a default mechanism to be
used by the received Node to identify all these proxy Bindings. IMO, we need
probably to have a generic approach that applicable to all cases. for
example, a MAG may have more than one pCoA with a specific LMA. As a
suggestion, I would recommend, in this case ONLY that the pCoA always be
included in the Alternate CoA option in the BRI. Additionally, when the MAG
share more than one pCoA, the MAG MUST include each pCoA in a separate
Alternate-CoA option.
 
Does sound acceptable? 
 
As a side note, implementations may have their own mechanism where the
MAG-ID is somehow known to the LMA, for example, and that implementation
would identify all of the proxy Binding that are served at that MAG using
the MAG-ID, but that is out of scope.

Regards, 
Ahmad 

  _____  

Ahmad

 
 
Thanks
S Magesh

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Dec 2008 08:57:14 -0600

Magesh,
please see inline.

Regards, 
Ahmad

	When the 'G' bit is used for a Global revocation and in line
with the above logic, we need to communicate the MAG-ID. I understand
that currently we do not have a mobility option specific to carry
MAG-ID, however, we defined a very specific scenario where the 'G' bit
is set and the R. Trigger is set to "per-peer policy". Only in this
case, the draft currently allow the MAG to include its ID in the MN-ID
option. Sending the BRI and BRA is assumed to follow the exact procedure
for PBU and PBA with respect to the source and dest. IP addresses.
	 
	[Magesh] I'm not in favour of having a new mobility option for
carrying the MAG-ID, my concern is if MAG-ID is carried in the BRI
message, how does LMA knows all the binding session(s) related to that
particular MAG (your point here is implementation dependent).  Since
from RFC5213 , it is clear that Binding Cache & Policy Profile does not
maintain the MAG-ID, i feel it is better to add a statement in Binding
Revocation draft regarding the way MAG-ID is handled by LMA for
identifying all the binding session(s).
	 
	In the vice versa case (i.e. LMA sending Global Revocation to
MAG with Revocation Trigger set to "Per-Peer Policy" ), the BRI
triggered by LMA will not have any mobility option(s).  When MAG
receives the
	BRI, based on the LMAA (i.e. source address in the received BRI
message), it will retrieve all the binding session(s) and revoke them.
I just need the same kind of procedure when MAG sends BRI with status
set to "Per-Peer Policy". 
	 
	[Ahmad]
	As I said earlier in my reply. If the case of the LMA is
sufficient to you, then the case of the MAG is sufficient too. Because,
in every BRI sent from the MAG to the LMA, the MAG follow the same
procedure as in sending a PBU. i.e. src address = pCoA. However, as I
said earlier, that could be NOT enough in case the MAG has multiple
pCoAs. In this case, my suggestion is: Whenever MAG sends a BRI with the
(G) bit is set and the R. Trigger is set to "per-Peer Policy", the MAG
must identify the pCoA(s) by including them in Alternate CoA options in
the BRI.
	 
	Is that logic acceptable to you or you have a problem with that?
	 
	Regards,
	Ahmad