[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
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:vijay at wichorus.com]
> Sent: Thursday, March 12, 2009 5:58 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: draft-ietf-mext-binding-revocation at tools.ietf.org; 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
>