Subject: [Mip6] Comments on draft-muhanna-mip6-binding-revocation-01.txt

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 05 Jun 2007 13:17:58 +0200

Dear writers,

Here are my comments/questions to your draft (ed. 01).
Sorry, this is a long review but i think its needed if we want to do a 
good job!

Bruno.

Abstract section
************

[opinion] I don't see the need to say that revocation is missing in 
other drafts. Should just say that the draft "defines" a revocation 
mechanism that applies to mobile IPv6 and its extensions (PMIP6).

[opinion] Draft says:

   The proposed revocation mechanism
   uses generic message properties which is applicable to Mobile IPv6
   and Proxy Mobile IPv6 and can be used by any two mobility entities.

I don't think it is the main focus of the draft. It introduces some 
confusion for the reader. The revocation mechanism has a semantic and 
the abstract raises first implementation aspects. Revocation is 
independent of a generic messaging between "any two mobility entities". 
Moreover, reading further the draft, the revocation appears to be mainly 
initiated by HA or LMA (CN?) and thus might not require a generic messaging.

You might have a look at the abstract of draft-ietf-reg-revok-07.txt. I 
think it is a perfect abstract of a revocation mechanism.

[question] Is the example of PMIP6 usage pertinent in the abstract 
section? Would a regular MIP6 example not be simpler?

Protocol overview section (3.)
***********************

[opinion] Usage of the term "Binding Revocation  Indication Message" is 
not consistent with the term "Binding Revocation Message" used in IPv4 
revocation draft. Not critical.

[question] HA/LMA can issue BRI, but can a CN (Correspondant Node) issue 
a BRI?

BRI message
**********

[question] possible senders and receivers of BRI?
My understanding is:
-HA can send BRI to MN (MIP6)
-LMA can send BRI to MAG (PMIP6)
Is that correct?
I don't get it that way when reading the section intro.
It seems MAG can send BRI to LMA also, right?
It seems MN can cend BRI to HA also, right?
If so, i would rather suggest MAG sends regular deregistration PBU to 
release the binding rather than revocation.
I would also suggest (as recommended by RFC 3775) that MN sends 
deregistration BU to release the binding rather than revocation.

[opinion] "sessions" in Global Per-Peer Bindings (G bit) should be 
"bindings". The term "session" is confusing.
Same in Mobility Options and several places in the draft.

[opinion+question] lack of BRI semantics in the section.
If  P bit (Proxy) is set, binding identification shall be present in 
Mobility Options. How is a PBU identified? Is it possible to include 
multiple PBU identifications in a BRI. If P bit not set, same problem to 
identify a binding.
If G bit (global) is set, does the revocation concerns all BU and PBU?
Identification of the BU/PBU in Mobility options is critical. I doubt 
solely the HoA is enough, thoughts?

BRA message
***********

[question] how do you handle the case where G bit has been set in the 
BRI and revocation is partially successful (some BU/PBU revoked, others 
don't)?
[opinion] lack of semantics for the Mobility Options field in BRA 
("usually match...").
[opinion] lack of semantics for the Status code (BU/PBU discrimination). 
BCE term is confusing.

Use cases
********

[opinion+question] You say that revocation no longer authorizes to 
receive mobility services. What does it mean exactly "authorizes to 
receive mobility service"?
To revocation terminates prematurely an established BU/PBU with the 
following consequences:
-no more data will be tunneled by the revoker (HA/LMA) toward the peer 
mobility agent
-no more data will be accepted  from the revokee for tunneling to the 
network by the revoker
-BU/PBU need to be reestablished
Thus revocation implies deregistration at both revoker and revokee level.
I think this could be said in the draft before to go into use case details.

===> Use Case 1 (HA to MN)

[question] Why is the P bit (Proxy bit) set while PMIP6 is not involved?
[question] Is the HoA sufficient to identify the binding?
I doubt it. If the MN has multiple CoA (primary and non-primary), 
multiple BU can exist at HA level. In such case the (CoA, HoA) couple is 
needed to identify the BU to revoke.

===> Use Case 2 (LMA to MAG)

[question] Looks like the A bit is required for PBU revocation. Is it 
stated previously in revocation message semantics?
[opinion] the sending of the RA to terminate the prefix of the MN should 
be optional (as in IPv4 with the I bit). Ideally, the support of sending 
such RA when a BRI is received shall be an option of the PBU message 
(the MAG indicates its capability). In addition, the BRI shall indicate 
if RA sending is requested on a BRI basis and according to MAG 
capability. This of course, will require additional working on the draft 
if a BRI targets multiple BU/PBU with the G bit.

===> Use Case 3 (MAG to LMA)

[opinion] BRI/BRA is not required in that case. The MAG can send a 
regular deregistration BU/PBU to the LMA with suited CoA and HoA. To me 
the case does not really correspond to a revocation but more to regular 
behavior of MIP6/PMIP6.
Thoughts on this?

[question] What is the need for Handoff timer?
I have in mind that you can let BU from sMAG expire in LMA and accept 
new BU from tMAG in LMA. When new BU is in LMA, data gets to MN through 
tMAG. In the meantime (handoff) data will try to get to MN through sMAG 
(no guarantee since MN might not be anymore on the sMAG link).

Bulk termination
************

[opinion] please use the term "bindings" instead of "sessions".
[question] How is the HA address is provided in the BRI? As a specific 
Mobility Option? Is this what you mean by Home Address Option? If so, is 
it the same option than the one used to sepcify the HoA in the BRI? I 
guess a specific Mobility Option is required to distinguish HoA from HA 
address.
[opinion] also note that this section introduces an additional semantic 
for the G bit (all bindings of a HA/LMA) that was not specified in the 
field semantic before.

MAG Operational summary
*********************

[question] if MAG sends a BRI to LMA for maintenance purpose and uses 
the MAG IP address as the CoA address option (Mobility Option i 
presume), how does the LMA find the related bindings? I don't see a 
necessary relationship between MAG IP address and the CoA managed by the 
MAG. The MAG IP address is not necessarily stored on LMA side, is it?

[opinion] i think that using the HNP in the PMIP6 binding management is 
not a good idea. Any binding can be identified by the couple (CoA, HoA). 
The identification of binding should be consistent in the draft. The 
usage of HNP is equivalent because the per-MN prefix model is used in 
PMIPv6 for now. Should this change in the future, this would cause 
problems with your draft.

Binding revocation signaling in global mobility
**********************************

[question] Do you mean that revocation can be used to avoid unexpected 
mobility service interruption? So, when a BRI is received because the 
user runs out of money, the user puts additional money and sends a BRA 
with status "refunded" and the revocation process is relinquished?

[opinion] i disagree with the usage of BRI/BRA when returning home while 
this can be done using RFC 3775 as recommended.

Other points
*********

-support of the revocation mechanism should be optional as this has been 
done in IPv4. That is the BU or PBU should be extended with a capability 
bit. HA/LMA should not send BRA for BU or PBU if MN/MAG does not support it.
-not clear if the draft allows a CN (Correspondant Node) to issue a BRI 
when RO is in effect (MIP6 case)
-missing MN Operational summary section to describe MIP6 MN behavior 
supported by the draft.

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 11 Jun 2007 12:40:46 -0500

Hi Bruno,

Thanks for your detailed review and comments. My apologies for the late
response, please see comments inline.

Regards,
Ahmad

> Abstract section

[Ahmad]
Ok.

> independent of a generic messaging between "any two mobility 

[Ahmad]
I guess the idea here is that these messages can be used by the HA, MAG,
LMA, and probably the MN. That is probably what we want to communicate
and I am not sure if we succeeded. However, we will look into it to
improve the abstract.
 
> Moreover, reading further the draft, the revocation appears to be 
> mainly initiated by HA or LMA (CN?) and thus might not require a 
> generic messaging.

[Ahmad]
That is not necessarily true. Use case 3 shows a scenario where the
revocation is initiated by the MAG. I mean we tried to present some of
the relevant use cases in our initial revision. Hopefully, when this
draft becomes a wg item, then we will cover all related scenarios and
use cases.

> 
> You might have a look at the abstract of draft-ietf-reg-revok-07.txt. 
> I think it is a perfect abstract of a revocation mechanism.

[Ahmad]
Ok, you mean RFC3543. will look into that too.
> section? Would a regular MIP6 example not be simpler?

[Ahmad]
I see your point. I guess we can capture the MIP6 example there too or
make it either or to capture both examples.

> [opinion] Usage of the term "Binding Revocation  Indication Message" 
> is not consistent with the term "Binding Revocation Message" used in 
> IPv4 revocation draft. Not critical.

[Ahmad]
Thanks for raising this. Actually we were thinking of Binding Revocation
Request (BRR) but that conflicts with the Binding Refresh Request
message and also, it is not a request. Our thoughts was that since this
is an optional functionality and acknowledgement is kind of optional
too, we thought an indication make more sense, especially, for example,
if this is used during MN handoff for example, LMA may send an
indication to the source MAG to cleanup resources. In reality the MN BCE
has not been revoked at the LMA but we use the message to help MAG clean
unused resources.

> 
> [question] HA/LMA can issue BRI, but can a CN (Correspondant
> Node) issue a BRI?

[Ahmad]
We did not think of this scenario and it would depends on the group
consensus if it make sense to extend revocation to CN, for example.
> BRI message

[Ahmad]
Yes.

> It seems MAG can send BRI to LMA also, right?

[Ahmad]
Yes.
> It seems MN can cend BRI to HA also, right?
[Ahmad]
That is not the intention. If you can point me to the exact text, we
would try to eliminate the confusion. Anyway, we will look into the text
more closely one more time, to make sure that is not the case.

> deregistration BU to release the binding rather than revocation.

[Ahmad]
As far as the MN, yes MN should use deregistration BU with lifetime of
zero. In the case of the MAG, we probably can make it optional to use
either or. Since the MAG needs to support receiving a BRI, it also can
send it. But we can look into that and modify it as per group consensus.

> Same in Mobility Options and several places in the draft.

[Ahmad]
Thanks. Appreciate it. Will take care of them.
> Mobility Options. How is a PBU identified?
[Ahmad]
I am not sure about the question here, do you mean how we distinguish
PBU from BU?, or How we identify a MN BCE?

> Is it
> possible to include multiple PBU identifications in a BRI. If P bit 
> not set, same problem to identify a binding.
[Ahmad]
That is a good topic for discussion. Our thoughts, initially, is the
ability to revoke multiple BCEs as long as they share a common criteria,
however, I think we can look into that during the discussion of the
protocol details.

> If G bit (global) is set, does the revocation concerns all BU and PBU?

[Ahmad]
The G bit is introduced to communicate the need to delete all sessions
at one of the mobility agents. For example LMA or MAG.
However, this should be applicable to Proxy BCE only, IMO.

> Identification of the BU/PBU in Mobility options is critical. 
> I doubt solely the HoA is enough, thoughts?
[Ahmad]
I agree. We can discuss this in more details later when we get deeper in
the protocol. However, we probably need more than HoA in some cases.

> BRI and revocation is partially successful (some BU/PBU revoked, 
> others don't)?
[Ahmad]
I am not sure what you mean by partially successful? The MAG should be
able to release all sessions. You may meant that probably the number of
sessions that the MAG release is not the same as those at the LMA/HA for
example. But in that case, it does not matter. IMO.

> [opinion] lack of semantics for the Mobility Options field in BRA 

[Ahmad]
Not necessarily. Because all what we need is for the sending mobility
entity is able to match the returned BRA to the outstanding BRI.

> [opinion] lack of semantics for the Status code (BU/PBU 

[Ahmad]
Why do we need to discriminate between the two types?
> receive mobility service"?

[Ahmad]
There are many reasons that the Home domain would like to revoke a user
service. There is currently I think a Disconnect message identified that
AAA can send to the HA. Basically the user is no longer able to receive
MIPv6 services and be able to access the internet as a mobile.

> mobility agent -no more data will be accepted  from the revokee for 
> tunneling to the network by the revoker -BU/PBU need to be 
> reestablished Thus revocation implies deregistration at both revoker 
> and revokee level.

[Ahmad]
That is a good idea and we can capture some of these details.
> [question] Why is the P bit (Proxy bit) set while PMIP6 is not 

[Ahmad]
It should not. If it is in the text, we will correct it. Can you point
me to the exact text. Thanks.

> multiple BU can exist at HA level. In such case the (CoA, HoA) couple 
> is needed to identify the BU to revoke.

[Ahmad]
This is a very Good point. Thanks again. Will address the details when
we dive into the protocol details.  However, this is a good scenario.
> stated previously in revocation message semantics?

[Ahmad]
I guess we left it up to the HA local policy but we do not want to
mandate it. Unless there is a very strong reason and the group agrees on
that.

> [opinion] the sending of the RA to terminate the prefix of the MN 
> should be optional (as in IPv4 with the I bit).
[Ahmad]
Actually you are bringing very good points. I really thanks you for your
detailed review.
There is only one difference from MIPv4 revocation. In our case it is
possibly a PMIP session and the MN is not involved in the mobility
aspect. Since MN depends on RA to identify if it moves, still have a
valid IP address etc., I am thinking at least, for certain scenarios, we
need to mandate that the MAG need to send a RA with HNP lifetime is set
to zero.

> Ideally, the support of sending such RA when a BRI is received shall 
> be an option of the PBU message (the MAG indicates its capability). In

> addition, the BRI shall indicate if RA sending is requested on a BRI 
> basis and according to MAG capability. This of course, will require 
> additional working on the draft if a BRI targets multiple BU/PBU with 
> the G bit.

[Ahmad]
We assume in order for the MAG to be able to support PMIPv6, it should
be able to send RA. However, I agree with you, we may need to have an
indication to the MAG in certain cases that MAG must send a RA as I said
above. Probably another bit or identify that scenario specifically. We
will work out the details.
> regular deregistration BU/PBU to the LMA with suited CoA and HoA. To 
> me the case does not really correspond to a revocation but more to 
> regular behavior of MIP6/PMIP6.
> Thoughts on this?

[Ahmad]
I guess I addressed this above in one of your questions. In general, I
would like the MAG to send BRI since if the MAG support revocation,
there is not much extra in doing that. However, I am sure this point
needs the group consensus and we will address it at the proper time.
 
> new BU from tMAG in LMA. When new BU is in LMA, data gets to MN 
> through tMAG. In the meantime (handoff) data will try to get to MN 
> through sMAG (no guarantee since MN might not be anymore on the sMAG 
> link).

[Ahmad]
This is a tricky points. It is possible that the MAG would not be able
sometimes to identify if the MN moved to another MAG or exited the
network. In the case of MN exited the network, it is useful for the MAG
to send revocation. However, in the case of inter-AGW handoff, the sMAG
may skip sending BRI. However, as I said before, if the MAG sometimes is
not certain what happened, then MAG MAY send a BRI anyway. In that case,
we need the LMA to take an extra precaution before deleting the BCE.
Assuming that BRI arrived at the LMA before the PBU form the tMAG. Also,
we will have enough time to address the fine details of this scenario.

> Bulk termination

[Ahmad]
No problem.

> Mobility Option? Is this what you mean by Home Address Option? If so, 
> is it the same option than the one used to sepcify the HoA in the BRI?

> I guess a specific Mobility Option is required to distinguish HoA from

> HA address.

[Ahmad]
I guess we can still use the HoA address. Since the HA address is
already known to the MAG. But a new option is possible depending on
group agreement.

> [opinion] also note that this section introduces an additional 
> semantic for the G bit (all bindings of a HA/LMA) that was not 
> specified in the field semantic before.
> 
> MAG Operational summary
> *********************
> 
> necessary relationship between MAG IP address and the CoA managed by 
> the MAG. The MAG IP address is not necessarily stored on LMA side, is 
> it?

[Ahmad]
Actually what I meant is the CoA. Now if the MAG happens to use several
CoA, then we either specify multiple of them or use something else. TBD.
> 
> [opinion] i think that using the HNP in the PMIP6 binding management 
> is not a good idea. Any binding can be identified by the couple (CoA, 
> HoA).

[Ahmad]
According to PMIPv6 semantics, there is a possibility that the HA does
not know the exact HoA for the MN. Using the HoA and CoA is very good.
However, if the HoA is not available we need to use HNP but most
probably in combination with CoA.

> problems with your draft.

[Ahmad]
Well, I understand that but, please see the above comment.

> with status "refunded" and the revocation process is relinquished?

[Ahmad]
In the case of prepaid, Notification should have been sent earlier to
the user to refill its account. However, I foresee this scenario for the
MN to ack and it may does whatever it needs and then try to register
later. I do not see revocation being used in the semantics you
mentioned.
> 
> [opinion] i disagree with the usage of BRI/BRA when returning home 
> while this can be done using RFC 3775 as recommended.

[Ahmad]
Just in case some MNs do not send de-registration when returning home.
If MN sends de-registration, then HA wont send revocation anyway.

> 
> Other points
> *********
> 
> -support of the revocation mechanism should be optional as this has 
> been done in IPv4. That is the BU or PBU should be extended with a 
> capability bit. HA/LMA should not send BRA for BU or PBU if MN/MAG 
> does not support it.
> -not clear if the draft allows a CN (Correspondant Node) to issue a 
> BRI when RO is in effect (MIP6 case)
 
{Ahmad]
This needs the group consensus and we can discuss during the protocol
details.

> -missing MN
> Operational summary section to describe MIP6 MN behavior supported by 
> the draft.

[Ahmad]
We will add that section. Thx.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 11 Jun 2007 12:50:13 -0500

Hi Bruno,

not clear if the draft allows a CN (Correspondant Node) to issue a 
> BRI when RO is in effect (MIP6 case)
 
Mohamed>> can you elaborate more on why we need this feature.