Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft



Hi Ahmad,

My few thoughts inline (marked with [SANDESH]).

Thanks and Regards,
Sandesh Kumar Sodhi

-----Original Message-----
From: Ahmad Muhanna [mailto:amuhanna at nortel.com]
Sent: Tuesday, August 05, 2008 12:41 AM
To: Sandesh; mext at ietf.org
Subject: RE: [MEXT] Queries/comments on 'Binding Revocation for IPv6
Mobility' draft

Hi Sandesh,
Thanks again. Please see inline.

Regards,
Ahmad


> Subject: [MEXT] Queries/comments on 'Binding Revocation for
> IPv6 Mobility' draft
>
> Hi,
>
> I was going through the draft
> draft-ietf-mext-binding-revocation-00.txt
> (http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00)
>
> I have following queries/comments -
>
>
> 1.-------------------------
> There should a provision to bring a binding administratively DOWN/UP
> revoke/unrevoke mechanism without deleing entry from in BUL/BC.
> Administrator (at LMA or MAG) can use this to prohibit a MN from using
> a PMIv6 for some time (without deleting entry from in BUL/BC).
> This provision can be useful during testing/maintenance.

[Ahmad]
If the MN needs to be revoked for sometime, why do we need to keep its
BCE. It seems to me that one of the most important functionality that
Binding Revocation is trying to do is to help mobility nodes clear
resources and avoid stale sessions. May be you can elaborate more to
understand what you are trying to do.

~~~~~~~~~~~~~
[SANDESH]
I agree with the you that BRI provides a useful facility to remove BCE for
stale sessions. This is a desirable functionality.

IMO it is also desirable to have an administrative interface which
can disable/enable a particular binding for sometime without deleting
BUL/BCE. The session is not stale. It is just that we don't want to allow
any data traffic/Signalling for that MN for testing/maintenance activity
without the involvement if AAA server (Please see my next comment).

I would like to compare this feature of binding revocation to
link inhibit/uninhibit in SS7. When a link is inhibited data structures
for the particular link are not removed but particular link is marked
inhibited so that no traffic goes on that link.
~~~~~~~~~~~~~

>
> 1.-------------------------
> If administrator at LMA revokes a binding (does a revoke
> administrative
> action) (I would call is bringing binding administratively
> down) in this case a BRI message is sent to MAG (and BRA received in
> return).
>
> If after some time the same administrator unrevokes the binding (i.e.
> and makes this binding administratively up)

[Ahmad]
What is your definition of this administrative up and administrative
down events.
When the MN Binding is revoked for administrative reason, the MN is no
longer allowed to receive mobility service. If that the case, then
there is no need to keep the BCE around.


>
> Option 1:
> In this case should there be message which LMA can send to MAG to
> indicate that MAG can send PBU to register the MN binding with LMA.
>
> OR
> Option 2:
> When binding is administratively down MAG keeps on transmitting PBU
> and LMA replies PBA with status = Administratively prohibited.
> MAG keeps on sending PBU until LMA responds with PBA (status = 0)

[Ahmad]
I seem to have difficulties with the logic here.
If the MN session is revoked for administrative reason, all resources
associated with the MN session are deleted.
If the MN tries to access the network again, the MN should not be
allowed to receive PMIPv6 mobility services unless the Mobile node is
authorized to receive PMIPv6 which is communicated to the MAG during
access authentication.

As per PMIPv6 base protocol, the MAG receives the MN profile and also
if the MN is allowed for PMIPv6 service or not. Therefore, both
options above are not applicable.
~~~~~~~~~~~~~
[SANDESH]
Policy of an MN is present in the AAA sever and BCE is present in LMA.
Does revocation of binding at LMA means -
'marking MN unauthorized in AAA server' AND 'revoking MN binding at LMA'
If above is the definition of binding revocation then, if AAA server and LMA
are independent servers controlled by different companies, then
binding revocation
would involve interaction with both AAA server and LMA which might be
undesirable
in some case. (e.g when AAA server administarator and LMA administrator are not
the same person).

Also 'marking MN unauthorized in AAA server' needs to be done before
'revoking MN binding at LMA' for the following reason -
If 'revoking MN binding at LMA' done first and after that
'marking MN unauthorized in AAA server' is done then following race condition
might occur -
1. 'revoking MN binding at LMA' is done at LMA
2. BRI/BRA has been exchanged
3. MN attaches to MAG
4. PBU/PBA gets exchanged before -
5. 'marking MN unauthorized in AAA server'

Can we define two types of binding revocation -
i. DELETE REVOCATION (revocation defined in the draft) -
 Mark MN unauthorized for PMIPv6 service in AAA server.
 Initiate BRI+BRA exchange with MAG. LMA removes BCE.
 MAG removes BUL entry. LMA and MAG removes data tunnel
 for the MN. This involves interaction with AAA server.

ii. LOCAL REVOCATION - Initiate BRI+BRA exchange.
 BRI, BRA can carry flag indicating 'local revocation'.
 LMA marks BCE 'revoked'( i.e. administratively down).
 MAG marks BUL entry 'revoked' (i.e. administratively down).
 This does not involve interaction with AAA server. If BUL
 entry is marked 'revoked' MAG shall not query AAA server for
 authorization.
 The binding  can be unrevoked by another message exchange
 between LMA and MAG (say BINDING UNREVOKE + BINDING UNREVOKE ACK)

I hope I make some sense here.
~~~~~~~~~~~~~~

> 4.-------------------------
> Section 8.2.2. 4th bullet
> It would be good if few cases of 'partial success' can be mentioned.

[Ahmad]
I believe the text is generic and applicable.
Do you have a case that is not addressed by the current text?

~~~~~~~~~~~~~
[SANDESH]
Could you please let me know few cases in which LMA/MAG may be unable to
revoke a binding. IMO the LMA/MAG in all cases should be able to at least set
one flag to indicate for the binding is revoked and prohibit that binding from
being used until that binding is physically deleted.

Does partial success include the case when BCE at LMA or BUL entry at
MAG is deleted
but data tunnel for that link is not deleted for some reason or the
other way around.
Is such a case allowed for binding revocation.

It would be helpful for me if you can tell the thought process which
led to addition
of this 'partial success' status to draft.
~~~~~~~~~~~~~


>
> 5.-------------------------
> Section 9.2.2
> It would be good if few guidelines can added for the case when MAG
> receives BRA (status = partial success)

[Ahmad]
Like what?

~~~~~~~~~~~~~
[SANDESH]
The draft mentions that handling of BRA(status = partial success) is
defined by LMA's
local policy (Section 9.1.1. Third bullet). For MAG the draft does not
seem to be
mentioning anything.

Some guideline (which you feel makes more sense) for actions which can
be taken after
receiving BRA(status = partial success) can be provided in the draft
itself. This guideline
will make the draft rich in content.

One example guideline which I can think of is -
LMA/MAG may choose maintain a 'RevokeTryCounter' per binding initially
set to 0.
If BRA indicates MAG/LMA is unable to revoke the binding then the
counter can be
incremented. LMA/MAG retries for 'MaxRevocationTries' and then can
delete BCE/revoke binding. (This is similar to BRIMaxRetransmitNumber)
~~~~~~~~~~~~~
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.