Subject: [MEXT] Comments on draft-ietf-mext-binding-revocation-02

From: "Stupar, Patrick" <[email-masked]>
Date: Thu, 11 Dec 2008 01:19:19 -0000

Hi Ahmad,

I have reviewed binding revocation draft and have the following
comments/questions. 

- In MIPv6, Binding Update and Binding Ack have two different MH type
values. Why isn't the same approach taken for BRI and BRA and only one
value is used? 

- BRI has a revocation trigger field which is used for two main usages.
One is the provisioning of the reason why the revocation was sent (e.g.
inter-MAG handoff) and the other is related to specific binding
revocation procedures (e.g. IPV4 HoA Binding only, Per-Peer Policy). I
think it would be cleaner if the two concepts remain separated in the
messages, for instance defining additional flags for Per-peer policy or
IPv4 HoA Binding only.

- In the draft you refer to MAG identity, where is this term defined? I
wasn't able to find it in RFC 5213. 

Some other comments related to specific sections:

- page 21: in the first section after the bullet list, there is the
following sentence:
"As described in Section 7.3, the LMA SHOULD retransmit this BRI to
   the MAG before deleting the mobile node IP tunnel to the mobile
   access gateway until it receives a matching Binding Revocation
   Acknowledgement or the BRIMaxRetransmitNumber is reached. "
But this doesn't always apply, e.g. in case of inter-mag handoffs. What
am I missing?

- why is the A bit setting mandatory in case of IPv4 HoA binding only
revocation?

- section 10.1.1: 
"BRI MUST be formatted as in Section 6.1 and if the (P) bit is set,
      the mobile access gateway must validate that the impacted binding
      have the proxy binding flag set."
MAG is not supposed to have any proxy binding flag or is it? How can it
validate this flag?

-section 11.1
" If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication and the MN has the BCE in registered state, the mobile
      node MUST send a Binding Revocation Acknowledgement."

MN has no BCE, it has a binding update list.

-section 11.1
"If the Revocation Trigger field value is "Administrative Reason",
      the mobile node MUST NOT try to re-register with the home agent
      before contacting its home operator."

I don't think that BRI specs have to mandate the MN to contact the home
operator, the text at the end of section 11.1 is enough IMO.

I have some typos and editorial corrections as well, I will send them
off-list.

Regards,

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Dec 2008 19:34:05 -0600

Hi Patrick,
Thanks for your review. Please see responses inline.

Regards,
Ahmad

> -----Original Message-----
> From: Stupar, Patrick [mailto:[email-masked]] 
> Sent: Wednesday, December 10, 2008 7:19 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: Comments on draft-ietf-mext-binding-revocation-02
> 
> Hi Ahmad,
> 
> I have reviewed binding revocation draft and have the 
> following comments/questions. 
> 
> - In MIPv6, Binding Update and Binding Ack have two different 
> MH type values. Why isn't the same approach taken for BRI and 
> BRA and only one value is used? 

[Ahmad]
This was discussed on the mailing list for a long time and agreed that
using one MH type will help in preserving the MH type space. I believe
the "Heartbeat Mechanism for PMIPv6" is a wg doc in Netlmm and use one
MH type for the Request and Response. On the other hand, do see an issue
or problem in having a single MH type for both messages?

> inter-MAG handoff) and the other is related to specific 
> binding revocation procedures (e.g. IPV4 HoA Binding only, 
> Per-Peer Policy). I think it would be cleaner if the two 
> concepts remain separated in the messages, for instance 
> defining additional flags for Per-peer policy or
> IPv4 HoA Binding only.

[Ahmad]
I see what you are saying. However, as you said, the Revocation Trigger
field is defined to give the reason which caused the revoking node to
send the BRI message. Thus far, I believe all of the defined values are
inline with that definition or reasoning. For example: When the LMA sets
the R. Trigger value to "IPv4 HoA Binding Only" it means that the reason
behind sending this BRI message is to revoke the IPv4 HoA address in the
case that the MN is assigned two proxy HoA(v4 & v6) for the same pCoA. I
do not see this as a policy decision, because it is no difference from
the MAG sending a BRI with R. Trigger value is set to for example,
"Access Network Session Termination"

As for the R. Trigger value of "Per-Peer Policy", This is only
restricted to Global Revocation when the (G) bit is set. I still believe
that "Per-Peer policy" also indicate the reason that allowed the LMA to
send this Global BRI. Do you have a different name for this R. Trigger
value that would fit better? 

> 
> - In the draft you refer to MAG identity, where is this term 
> defined? I wasn't able to find it in RFC 5213.

[Ahmad]
Actually, under section 4.1. "Peer Authorization Database (PAD) Example
Entries", you can find the MAG-ID is defined there as mag_identity_1. It
is the same concept here. However, I agree that we do not have a
mobility option which is specific for carrying MAG-ID but the draft is
using the MN-ID in a very specific scenario. How the LMA would check if
this MAG is authorized for Global revocation is out of scope.

> - page 21: in the first section after the bullet list, there 
> is the following sentence:
> But this doesn't always apply, e.g. in case of inter-mag 
> handoffs. What am I missing?

[Ahmad]
Yes, I see what you are saying here. It seems that the text needs some
tweaking. 
Do you have any suggestion?

> 
> - why is the A bit setting mandatory in case of IPv4 HoA 
> binding only revocation?

[Ahmad]
May be if you tell me why not, we could change it?

> MAG is not supposed to have any proxy binding flag or is it? 
> How can it validate this flag?

[Ahmad]
Good catch. There is another incident below it too.
What about the following text for both bullets:
"
   o  BRI MUST be formatted as in Section 6.1 and the (P) bit is set.

   o  If the Global (G) bit is set and the Revocation Trigger field is
      set to "Per-Peer policy", the mobile access gateway identify all
      bindings that are registered at the LMA and hosted at the MAG.
      This Binding Revocation Indication does not include any other
      mobility options. In this case, the MAG MUST send a BRA with the
      appropriate status code to the LMA.
"

> MN has no BCE, it has a binding update list.
[Ahmad]
Right. Thx. What about the following:

   o  If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication and the MN has a Binding Update List entry for the
source
      of the BRI message, the mobile node MUST send a Binding Revocation

      Acknowledgement. However, in all other cases when the (A) bit is
set 
      in the BRI, the mobile node SHOULD send a Binding Revocation
Acknowledgement.  
      In all cases, the mobile node MUST follow Section 11.2 when send 
      a BRA using the appropriate status code.

> I don't think that BRI specs have to mandate the MN to 
> contact the home operator, the text at the end of section 
> 11.1 is enough IMO.
> 
[Ahmad]
I see your point, It seems a very strong requirement and for a well
behaved MN implementation, it may not be a problem to remove the whole
bullet. However, for a non-well behaved MN, it may be necessary to keep
something. What about if we demote MUST NOT to SHOULD NOT. Would that
work?

NEW TEXT:
   o  If the Revocation Trigger field value is "Administrative Reason",
      the mobile node SHOULD NOT try to re-register with the home agent
      before contacting its home operator.

TEXT at end of 11.1 that Patrick is referring to:

   The Revocation Trigger field value in the received Binding Revocation
   Indication could be used by the mobile node to define what action the
   mobile node could do to be able to register again and receive its IP
   mobility service, e.g. contacting its home operator.

> I have some typos and editorial corrections as well, I will 
> send them off-list.

[Ahmad]
Please send them. Thanks for your review and good comments!

---

From: "Stupar, Patrick" <[email-masked]>
Date: Mon, 15 Dec 2008 15:16:32 -0000

Hi Ahmad,

Please see answers inline

Best Regards,

Patrick

> From: Ahmad Muhanna [mailto:[email-masked]]
> Sent: Friday, December 12, 2008 2:34 AM
> To: Stupar, Patrick
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-mext-binding-revocation-02
> 
> Hi Patrick,

[Patrick] If the WG is worried about MH type space then I am fine with
the proposed message format.

> value that would fit better?

[Patrick]IMHO "IPv4 HoA Binding Only" is not the reason that triggered
the BRI, it's the action that the MN is requested to perform. Anyhow, my
concerns were not related to the list of reasons in the revocation
trigger, but to the fact that some values of the field imply some
actions and other values don't. My suggestion is that the actions are
taken by MN and HA based on flags (e.g. Global Revocation) and not on
the revocation trigger. Only the case of "IPv4 HoA Binding Only" lacks
of a proper flag.  

> this MAG is authorized for Global revocation is out of scope.

[Patrick] what I meant here is that in section 2 of RFC5213 there is the
definition of MN identity and that I would expect something similar for
the MAG in BRI draft. For MN identity, RFC5213 claims that MAC address
or NAI can be used. Are there similar guidelines for MAG identity?  

> Do you have any suggestion?
[Patrick] How about referring to the BCE?
Proposed text:
"As described in Section 7.3, the LMA SHOULD retransmit this BRI to
the MAG before deleting BCE until it receives a matching Binding
Revocation
Acknowledgement or the BRIMaxRetransmitNumber is reached. " 
Though I am not sure this text is helpful as it is already captured
later in the draft.

> May be if you tell me why not, we could change it?

[Patrick] I have nothing against it. But that "MUST" implies that a BRI
with the "IPv4 HoA Binding Only" value in the revocation trigger field
and A bit not set is not properly formatted. What does the MAG do in
this case?

>       appropriate status code to the LMA.

[Patrick] fine with me, thanks

>       a BRA using the appropriate status code.
[Patrick] I would perform the check based on the HoA and CoA contained
in the BRI. 
Proposed text:

   o  If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication and the MN has a Binding Update List entry for the Care
of address and the Home Address
      Contained in the BRI message, the mobile node MUST send a Binding
Revocation

> something. What about if we demote MUST NOT to SHOULD NOT. Would that
[Patrick] I was not worried about the "MUST" or "SHOULD", but by the
fact that IMO the action to be taken after receiving a BRI with that
value in the trigger field is implementation dependant as already
described later in the draft