Subject: Re: [netlmm] [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 17:49:19 -0500

Hello Vijay,

There have been consensus on the ml for the following issues that you
disagree with and I strongly believe that is NOT a good practice to keep
opening issues that have been addressed, consensus on them have been
reached, and closed. For the simple reason, those who accepted these
issues as resolved, probably have implemented them already. Any change
which is NOT related to a clear technical issue, should not be granted,
IMHO.

Therefore, I am yielding to the Chairs to make a decision on the
following issues. I also copied Netlmm wg.

ISSUE No. 1:
============
In the case of MAG's initiated Global revocation, is authorization of
the MAG by the LMA is Needed or NOT.

This has been in the draft since inception and discussed many times and
agreed upon, however, it seems that Vijay disagree and finds that a huge
implementation overhead.

ISSUE N. 2:
=============
The draft currently is written with the following in mind:

When the receiving node receives a BRI message, It is NOT necessarily
that the receiving node holds the BRI until it does the following:

i. Allocate all the BCE(s).
ii. Delete all the BCE(s).
iii. Send the BRA.

However, In every applicable scenario which requires the receiving node
to follow the above sequence, it is CLEARLY documented. The whole idea
is: specifying and mandating the above sequence GLOBALLY means that we
are specifying how this needs to be impregnated rather than define the
functionality where the end result is the same; I already used the
following examples but it seems they are not convincing to Vijay:

I. When the MN receives a BRI with R.T. is set to "Administrative
Reason", the MN could respond back with BRA status success and then
delete its binding from the BUL. As long as the MN does not use that HoA
binding, WHY in the WORLD this is a PROBLEM?

II. Global Revocation: Since this is allowed currently, if the MAG sends
a Global revocation which impacts 20k sessions, for examples, WHY the
LMA needs to hold sending BRA until it deletes all resources associated
with these 20k sessions. An implementation could do that. Nothing WRONG
with that BUT what is WRONG if another implementation sends that BRA and
then executes all the deletion. 

Regards,
Ahmad

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, March 12, 2009 5:58 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]; Julien 
> Laganier; mext; Sri Gundavelli
> Subject: Re: [MEXT] Review of 
> draft-ietf-mext-binding-revocation-03.txt
> 
> Ahmad Muhanna wrote:
> > Hi Vijay,
> > 
> >> Ahmad, if there is a security threat by a MAG deleting the 
> binding it 
> >> created, let me know. Otherwise the authorization check is 
> >> unnecessary.
> >> Please remove it.
> > 
> > [Ahmad]
> > The simple answer is yes. IMO, compromised MAG is 
> applicable here as 
> > it was applicable in PMIPv6.
> > The problem with Global revocation is: the consequences is 
> much more 
> > sever. One single message impact all bindings between the 
> MAG and the 
> > LMA. Adding this authorization check, is NOT a huge overhead. It 
> > ensures that this MAG is authorized to participate in such 
> activity, 
> > which MAY NOT happen that frequently anyway. Also, it gives LMA the 
> > freedom  to NOT allow some MAG(s) to do such activity.
> > 
> > As an example: let us assume that MAG1 will send a Global 
> Revocation 
> > at time (t1) and MNx will attach at time (t1+ 30 seconds). 
> Why it is 
> > acceptable for the LMA to make sure that the MAG1 is authorized to 
> > send a PBU on behalf on MNx while it is not needed to 
> validate that it 
> > is authorized to delete 10k sessions (for example) in a 
> single message.
> 
> This is a wrong analogy. Currently RFC 5213 does not require 
> the LMA to perform an extra authorization check when deleting 
> a binding when it receives a de-registration PBU from the 
> LMA. So why require the authorization check for bulk 
> revocation? It is the MAG that created the bindings.
> 
> In addition, the authorization check that is described in 
> draft-ietf-mext-binding-revocation-03.txt seems to be saying 
> that the LMA must check if the MAG is authorized to do bulk 
> revocation. Not about
>   the MAG being authorized to modify the binding related to 
> mobile node session. Why do you want the LMA to maintain a 
> list of MAGs that are authorized for bulk revocation? How is 
> this list configured on the LMA?
> 
> >>> [BTW: This has been in the draft since inception and has been 
> >>> discussed many times and was approved during the wg LC]
> >> Has it been discussed specifically?
> > 
> > [Ahmad]
> > Yes. We did. In several occasions. 
> > Please check exchanges with Domagoj, Patrick, and others.
> 
> I couldn't find anything on this. Can you please give me a pointer?
> 
> >>> 3. If there is a Peer Authorization Database already as 
> per PMIPv6, 
> >>> why it is TOO difficult to add the authorization for the
> >> Global Revocation.
> >>
> >> Are you talking about IPsec PAD?
> > 
> > [Ahmad]
> > That could be used too. I do not see any problem with that.
> 
> See section 4.4.3 of RFC 4301 for the PAD definition. How can 
> this be used by the LMA to check if the MAG is authorized for 
> bulk revocation?
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Mar 2009 16:47:24 -0800

Hi Ahmad,

Ahmad Muhanna wrote:
> issues as resolved, probably have implemented them already. 

This is something we can't avoid. If you implement a draft before it 
completes a WG last call, then you need to be prepared to make changes 
to your implementation.

> Any change

We don't have such a thing in the IETF. If you are saying we shouldn't 
make a change to a Proposed Standard RFC without there being an issue, 
then I agree. But not to an Internet Draft.

> following issues. I also copied Netlmm wg.

Let me clarify a bit. I am not sure if folks have read through all the 
emails. More than it being an implementation overhead, it is difficult 
to implement this authorization check based on the current document. 
Does the LMA keep a list of MAGs that are authorized for sending bulk 
revocations? How is this list configured? In addition, I think this 
authorization step is unnecessary and should be removed.

> ISSUE N. 2:

I find this very weird. When you receive a message, you try to process 
it and carry about what the message told you to. Then you send a 
response. In this specific example, when you receive a revocation 
message, you first try to delete the binding and then send a BRA message.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Mar 2009 23:49:10 -0500

Hi Vijay,

> > disagree with and I strongly believe that is NOT a good practice to 
> > keep opening issues that have been addressed, consensus on 
> them have 
> > been reached, and closed. For the simple reason, those who accepted 
> > these issues as resolved, probably have implemented them already.
> 
> This is something we can't avoid. If you implement a draft 
> before it completes a WG last call, then you need to be 
> prepared to make changes to your implementation.
> 
[Ahmad]
That is NOT TRUE. 
The WGLC has already been completed. This partial LC is restricted to
the Alternate-CoA use, which apparently you do NOT have a problem with.
Please check the chairs messages.

> > Any change
> > which is NOT related to a clear technical issue, should not be 
> > granted, IMHO.
> 
> We don't have such a thing in the IETF. If you are saying we 
> shouldn't make a change to a Proposed Standard RFC without 
> there being an issue, then I agree. But not to an Internet Draft.

[Ahmad]
Also, NOT on an internet draft after completing wglc. I believe
attempting to reopen issues that have been concluded and achieved
consensus is a waste of time and should not be the common practice,
especially if there is NO technical issue and it is nothing but one
person's preference and opinion. Again, IMHO, that is a waste of time.

> > This has been in the draft since inception and discussed many times 
> > and agreed upon, however, it seems that Vijay disagree and 
> finds that 
> > a huge implementation overhead.
> 
> Let me clarify a bit. I am not sure if folks have read 
> through all the emails. More than it being an implementation 
> overhead, it is difficult to implement this authorization 
> check based on the current document. 

[Ahmad]
This has been discussed before and agreed upon.
Authorization is NOT a new thing. It is already captured and documented
in RFC5213 under section 5.3. and it is needed for each PBU. Nothing
special in here.

> Does the LMA keep a list of MAGs that are authorized for 
> sending bulk revocations? How is this list configured? In 
> addition, I think this authorization step is unnecessary and 
> should be removed.

[Ahmad]
Again, What about authorization as per section 5.3. in PMIPv6
specification? Why is that possible for PBU?
There are many ways to do this and that is why it is left for the
creativity of Architect to find the best that fits their product
architecture.

> > However, In every applicable scenario which requires the receiving 
> > node to follow the above sequence, it is CLEARLY 
> documented. The whole 
> > idea
> > delete its binding from the BUL. As long as the MN does not 
> use that 
> > HoA binding, WHY in the WORLD this is a PROBLEM?
> > 
> > II. Global Revocation: Since this is allowed currently, if the MAG 
> > sends a Global revocation which impacts 20k sessions, for examples, 
> > WHY the LMA needs to hold sending BRA until it deletes all 
> resources 
> > associated with these 20k sessions. An implementation could 
> do that. 
> > Nothing WRONG with that BUT what is WRONG if another implementation 
> > sends that BRA and then executes all the deletion.
> 
> I find this very weird. When you receive a message, you try 
> to process it and carry about what the message told you to.
[Ahmad]
Probably you need to get out of the mode of BU/BA. It is a little
different. Smart implementations MAY schedule the processing of messages
based on their priorities. There is nothing wrong by sending the BRA and
starting the deletion process at the same time. As I said many times
already there is scenarios that the receiving node MAY choose to send
the BRA and complete the deletion later on, especially Bulk Revocation.
Capturing a restriction that makes ALL implementation do the same thing
is NOT a smart nor a creative way.

BOTTOM LINE:
DO you have any SINGLE scenario that needs to follow your sequence of
event and it is NOT documented in the draft?

> Then you send a response. In this specific example, when you 
> receive a revocation message, you first try to delete the 
> binding and then send a BRA message.

[Ahmad]
That could be one way of implementing it. That is absolutely fine, BUT
it should NOT be mandated on every other implementation.

---

From: Joel Hortelius <[email-masked]>
Date: Fri, 13 Mar 2009 09:27:44 +0000

Resending my questions in brief form;

1; Since some triggers do require specific actions, and the draft uses
the word "currently defined" for trigger definitions indicating new
triggers may be added - how is an implementation supposed to deal with
future triggers that may or may not require specific action?

2; What combinations are possible? What triggers may be used with the
'G' bit? Some triggers have been indicated that they should be used with
'G', but others do not. Some combinations do not make sense. Does 'G'
ONLY work with those explicitly specified? If so, what should one do
with the other combinations if they appear?

3; Since you define your own namespace regarding revocation trigger
message types (BRI, BRA), it would have made sense to me to split the
messages even further and have a Global BRI and Global BRA instead of
the 'G' bit, AND separate the trigger reason values into a global and
per binding trigger namespaces. Mixing global trigger reasons with
per-binding session reason, where the global "namespace" requires
specific actions based on trigger reason quickly gets complex. Having
them separated would remove the most obscure combinations, which are
either meaningless or invalid. 

4; Just remembered that the per-session revocation do require specific
action on some triggers (unknown handoff). Perhaps splitting the trigger
values:
< 128  -"soft" triggers; revoke and log - may use reason for for
undefined action to restore connectivity. This would be
"administrative", "user initiated", etc.
>= 128 -"hard" trigger. If unknown, reply with "unsupported trigger",
otherwise do the actions defined by the trigger. This would be
"per-peer", "node-local", "unknown handoff" etc.

5; What is one supposed to do if both 'G' and 'V' bit are set in a BRI?

6; The partial success on MAG is hazy; When is it supposed to be used?

7; The out of sync BCE state trigger, when is it supposed to be used? I
can't find any reference to it in the doc.

Regards,
Joel Hortelius

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 13 Mar 2009 12:05:10 -0400

Hello, 

> 3; Since you define your own namespace regarding revocation 
> trigger message types (BRI, BRA), it would have made sense to 
> me to split the messages even further and have a Global BRI 
> and Global BRA instead of the 'G' bit, AND separate the 
> trigger reason values into a global and per binding trigger 
> namespaces. Mixing global trigger reasons with per-binding 
> session reason, where the global "namespace" requires 
> specific actions based on trigger reason quickly gets 
> complex. Having them separated would remove the most obscure 
> combinations, which are either meaningless or invalid. 

This is a good idea. I would also like to see this change done.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 13 Mar 2009 13:00:54 -0500

Hi Joel,
Please see responses inline.

Regards,
Ahmad

> From: Joel Hortelius [mailto:[email-masked]] 
> Sent: Friday, March 13, 2009 4:28 AM
> Cc: mext; [email-masked]
> 1; Since some triggers do require specific actions, and the 
> draft uses the word "currently defined" for trigger 
> definitions indicating new triggers may be added - how is an 
> implementation supposed to deal with future triggers that may 
> or may not require specific action?
>
 
[Ahmad]
I believe the safest approach is to allow the receiving node to reject
such message with a proper status code, "Revocation Trigger NOT
Supported" or we can make it more generic "Specific Revocation
Functionality NOT Supported"

> 2; What combinations are possible? What triggers may be used 
> with the 'G' bit? Some triggers have been indicated that they 
> should be used with 'G', but others do not. Some combinations 
> do not make sense. Does 'G'
> ONLY work with those explicitly specified? If so, what should 
> one do with the other combinations if they appear?

[Ahmad]
Yes, Global Revocation is meant to communicate a Mass revocation which
impact all mobility sessions between the pair MAG-LMA. Another use case
was discussed to allow the LMA, for example, to revoke multiple sessions
that belong to all MN(s) which share a specific criteria, e.g., MN-ID
belong to a certain realm. The receiving node need to be able to
differentiate between the two cases. Thus, there was two different
Revocation Triggers.

Any other combinations of (G) bit and other R. T. is NOT supported. IMO,
the receiving node should reject that BRI.
We can add text for this one. 

> combinations, which are either meaningless or invalid. 

[Ahmad]
Good point. I see what you are saying about the separation of the
triggers. However I do not see any value in creating different message
type for Global revocation. It is the same message and duplication
should be eliminated as much as possible.

> 
> 4; Just remembered that the per-session revocation do require 
> specific action on some triggers (unknown handoff). Perhaps 
> splitting the trigger
> values:
> < 128  -"soft" triggers; revoke and log - may use reason for 
> for undefined action to restore connectivity. This would be 
> otherwise do the actions defined by the trigger. This would 
> be "per-peer", "node-local", "unknown handoff" etc.

[Ahmad]
Okay, this means that we will have the following combination:

Per-MN Soft,
Per-MN Hard,

Global, Soft, and
Global, hard

That is probably too much. I believe separating the triggers to per-MN
and Global will suffice. Introducing Status code of "Unsupported
Trigger" is a good idea too.

> 5; What is one supposed to do if both 'G' and 'V' bit are set 

[Ahmad]
I actually thought about this one but I was not able to come up with a
usecase that justifies it. In other words, why the LMA, for example,
would send a Global BRI to revoke all IPv4 binding only?
If there is a valid usecase, we could add it.

> 6; The partial success on MAG is hazy; When is it supposed to be used?
[Ahmad]
The original intention was: If the MAG, for example, received a BRI
which impacts multiple sessions and one of these sessions for a reason
or another was already removed because of race condition, for example,
the MAG would set the status Code to either "success" or "partial
success". However, it seems that this "partial success" opens the door
for a lot of interpretations. If the group thinks that is problematic,
we can actually remove it completely.

> 
> 7; The out of sync BCE state trigger, when is it supposed to 
> be used? I can't find any reference to it in the doc.

[Ahmad]
Hmmm... I guess we missed the text for this one. Will add it.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 13 Mar 2009 11:14:00 -0700 (PDT)

Hi Vijay,

Some comments on this.

>> addition, I think this authorization step is unnecessary and

Bulk revoc is a high security risk operation, requiring such
authorization check will allow the system to build some
configurability into the system.

Even for a single binding, if you recall and as Ahmad pointed
out, we do require this in 5213. We added this per IESG note.
Before the MAG can create a binding, the LMA is required to check
if the given MAG is authorized to perform such an operation. The
same goes for dereg, its enforced indirectly, there is a check
for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the
dereg is allowed.

Now, this check for bulk dereg spanning many MN's is for the
specific operation, if its allowed or not. This is a requirement
for a good system design, from OM perspective. Has no bearing
on protocol interop. I dont think this can be an issue, one
can always add a * rule to permit every MAG to perform such
operation.

If your concern is maintaing that list, we can always state in
a secure network, the MAG can just have one flat rule to allow
such operation from all the configured peers that it knows.
Will that work ?

Sri

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Mar 2009 11:56:02 +0800

Hello,
>We can add text for this one. 

Sound good to me, But I wonder whether multiple sessions reovocation for Proxy MIPv6 use case  is covered in the draft?
Because in the section 3.4.2, only global revocation is covered.

Regards!
-Qin

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Mar 2009 01:46:36 -0500

Hi, Qin,

> >> 'G' bit? Some triggers have been indicated that they 
> should be used 
> >> with 'G', but others do not. Some combinations do not make sense. 
> >> Does 'G'
> >was discussed to allow the LMA, for example, to revoke multiple 
> >sessions  that belong to all MN(s) which share a specific criteria, 
> >e.g., MN-ID  belong to a certain realm. The receiving node 
> need to be 
> >able to  differentiate between the two cases. Thus, there was two 
> >different  Revocation Triggers.
> >Any other combinations of (G) bit and other R. T. is NOT supported. 
> >IMO, the receiving node should reject that BRI.
> Sound good to me, But I wonder whether multiple sessions 
> reovocation for Proxy MIPv6 use case  is covered in the draft?

[Ahmad]
It is covered. 
If the (G) bit is set and the R. T. is set to "Revoking Node Local
Policy", then you need to include more information that are common to
all BCE, for example: you could send the MN-ID to "[email-masked]". This
means that the sending node is requesting that all BCE with the MN-ID
that match the MN-ID above should be revoked.

Here is the related text:

1. under section 6.1:

   Global (G)

      The Global (G) bit is set by the sending mobility node, LMA or
      MAG, to request the termination of all Per-Peer mobility Bindings
      or Multiple Bindings which share a common identifier that are
      served by the sending and receiving mobility entities as in
      Section 9.1.1 and Section 10.2.1. 

2. Under section 9.1.1:

   When the LMA needs to revoke all mobile nodes proxy BCE that belong
   to a specific realm, e.g. @companyabc.com, and are registered with
   the LMA and hosted at the MAG, the local mobility anchor MUST set the
   Global (G) bit and the value of the Revocation Trigger field to
   "Revoking Node 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.

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Mar 2009 17:23:23 +0800

Hi, Ahmad:
Please see the followup comments.
-Qin
----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Joel Hortelius" <[email-masked]>
Cc: <[email-masked]>; "mext" <[email-masked]>
Sent: Monday, March 16, 2009 2:46 PM
Subject: RE: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt

Hi, Qin,

[Ahmad]
It is covered. 

1. under section 6.1:

   Global (G)

[Qin]: Just As you said, the multiple bindings revocation has already been included in the definition of Global(G).
However the multiple bindings revocation is quite different from multiple per-peer bindings revocation what I understand. Let me give you one exmaple on multiple per-peer bindings revocation.

 One mobile device owning three interfaces which share the same NAI registers to the same LMA, if the LMA want to revoke two per-Peer bindings associated with two interfaces of the mobile devices.What should the LMA do using bulk PMIP6 binding revocation? 

 I wonder whether this example can be viewed as multiple bindings revocation and whether this use case should be considered in this binding revocation draft.

2. Under section 9.1.1:

[Qin] If all mobile nodes BCEs belong to the same specific realm and are hosted at the different  MAGs which register to the same LMA,
what should this LMA do using multiple bindings revocation mechanism? It seems multiple BRA messages to the different MAG are required.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Mar 2009 07:34:44 -0500

Hi, Qin,
Please see inline.

> 
> [Qin] If all mobile nodes BCEs belong to the same specific 
> realm and are hosted at the different  MAGs which register to 
> the same LMA,
> what should this LMA do using multiple bindings revocation 
> mechanism? It seems multiple BRA messages to the different 
> MAG are required.
> 

[Ahmad]
This is NOT allowed and NOT supported. When MAG1 sends a BRI to revoke
multiple binding for a specific realm, it ONLY revokes those bindings
which are registered using a pCoA that belong to MAG1. In other words,
MAG1 is not supposed to remove binding(s) that registered through MAG2,
for example.

That is why LMA always sends a single BRA to MAG1.

Regards,
Ahmad

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Mar 2009 17:49:42 -0700

> out, we do require this in 5213. We added this per IESG note.

This authorization check was added in a very early version of the PMIPv6 
draft in response to a review from Lakshminath. Not due to the IESG. One 
of the options suggested was to have the LMA check if the MN is really 
attached to the MAG before allowing the MAG to create a binding for the 
mobile node. But this has nothing to do with the authorization check for 
bulk revocation.

> for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the

When the MAG de-registers a mobile node's session, there is no 
authorization check. The LMA only makes sure that it the same MAG that 
is responsible for the binding.

> can always add a * rule to permit every MAG to perform such

This does not make sense. If we are going to create a rule allowing all 
MAGs to perform bulk revocation, then why do we need the authorization 
check?

> such operation from all the configured peers that it knows.

You mean the LMA, right? The LMA is the one that does this check.

Your email does not address my question on how this list is created at 
the LMA. Why is one MAG special and allowed to do bulk revocation while 
another MAG is not allowed? The MAGs are all part of the same PMIPv6 domain.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Mar 2009 18:25:11 -0700 (PDT)

On Mon, 16 Mar 2009, Vijay Devarapalli wrote:

> draft in response to a review from Lakshminath. Not due to the IESG. One of 
> the options suggested was to have the LMA check if the MN is really attached 
> to the MAG before allowing the MAG to create a binding for the mobile node. 
> But this has nothing to do with the authorization check for bulk revocation.
>

No. That's not true. I've added this during the AD review. We may
have discussed this earlier, but this specific authorzation check
was added per the AD review. We may have discussed this very
early and I remember that discussion as well.

http://www.ietf.org/mail-archive/web/netlmm/current/msg04144.html

See this below snipper from Jari.

"Here's a potential rewrite:

Therefore, the local mobility anchor MUST restrict the creation
and manipulation of proxy bindings to specifically authorized
mobile access gateways, mobile nodes, and prefixes."

> When the MAG de-registers a mobile node's session, there is no authorization 
> check. The LMA only makes sure that it the same MAG that is responsible for 
> the binding.
>

No, there is a indirect check. The MAG before deregistering,
will match the Proxy-CoA in the request to that present in
the binding. Prior to that BCE creation, the LMA allowed only
a authorized MAG to create that binding. So, this check at dereg
will indirectly enforce the same.

> This does not make sense. If we are going to create a rule allowing all MAGs 
> to perform bulk revocation, then why do we need the authorization check?
>

Building the rule into the system is for defining an authorization model,
relaxing that rule in a given system deployment is a SDO/deployment
choice. That's the operator's choice based on the security considerations
in their operating environment.

> You mean the LMA, right? The LMA is the one that does this check.

Yes, typo

> Your email does not address my question on how this list is created at the 
> LMA. Why is one MAG special and allowed to do bulk revocation while another 
> MAG is not allowed? The MAGs are all part of the same PMIPv6 domain.
>

There is not much to address. We require the LMA to maintain a list
of MAG's authorized to perform certain functions. We need a very similar
list, or add an attribute to the above maintained list, with finer
access control as who can perform bulk dereg operations.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Mar 2009 18:32:11 -0700

Hi Sri,

Sri Gundavelli wrote:
>> This authorization check was added in a very early version of the 
>> PMIPv6 draft in response to a review from Lakshminath. Not due to the 
>> IESG. One of the options suggested was to have the LMA check if the MN 
>> is really attached to the MAG before allowing the MAG to create a 
>> binding for the mobile node. But this has nothing to do with the 
>> authorization check for bulk revocation.
>>
> 

This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in 
April 2007 had the following

    However, the local mobility anchor MUST allow only authorized mobile
    access gateways to create binding cache entries on behalf of the
    mobile nodes.  The actual mechanism by which the local mobility
    anchor verifies if a specific mobile access gateway is authorized to
    send Proxy Binding Updates on behalf of a mobile node is outside the
    scope of this document.  One possible way this could be achieved is
    sending a query to the policy store such as by using AAA
    infrastrucure.

See http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-00

AD review happened in Jan 2008.

> will indirectly enforce the same.

This is NOT an indirect authorization check. As I have said in this 
thread many times, the MAG that created the binding is allowed to delete 
the binding. Simple. There is no authorization check when deleting the 
binding.

Sorry, I am not convinced that this authorization check is needed for 
bulk revocation from the MAG.

Vijay

>> This does not make sense. If we are going to create a rule allowing 
>> all MAGs to perform bulk revocation, then why do we need the 
>> authorization check?
>>
>> the LMA. Why is one MAG special and allowed to do bulk revocation 
>> while another MAG is not allowed? The MAGs are all part of the same 
>> PMIPv6 domain.
>>
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Mar 2009 18:48:36 -0700 (PDT)

Hi Vijay,

On Mon, 16 Mar 2009, Vijay Devarapalli wrote:

> This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in April 
> 2007 had the following
>

We are not discussing about the check related to a MN attachment at
a given MAG. We are discussing about the LMA requiring to maintain
MAG authorization list, that's exactly Ahmad is talking about for
allowing/dis allowing Bulk Authorization list. How is this below check
relevant to this discussion ? The text I quoted with respect to MAG
authorization list was provided by our AD and thats what we have in
5213.

> AD review happened in Jan 2008.

Right. The quoted text in Security considerations that was there
from very begining is not about MAG authorization list, thats for
the proof of MN attachment at a given MAG.

> This is NOT an indirect authorization check. As I have said in this thread 
> many times, the MAG that created the binding is allowed to delete the 
> binding. Simple. There is no authorization check when deleting the binding.
>

MAG created a single binding and can very well delete a single binding
by sending a single request. That did not provide an explicit right
to delete all 30,000 bindings in a single message. That request needs
to pass additional authorization, as that can impact many sessions.

> Sorry, I am not convinced that this authorization check is needed for bulk 
> revocation from the MAG.
>

Sorry, I'm not convinced with this argument either. I dont see a single
interop/implementation issue requring LMA maintain that list, 5213 already
maintains that list. If this is unnecessary in a given trusted secure 
network, one can very well relax that. But, from a protocol design
perspective, this needs to be specified. I agree with Ahmad.

Sri