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

From: Sandesh <[email-masked]>
Date: Mon, 4 Aug 2008 14:55:10 +0530

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.

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)

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)

2.-------------------------
IMHO this draft should include the changes for
'IPv4 Support for Proxy Mobile IPv6' also.
i.e.
In the sections related to MAG and LMA there should be mention
of IPv4 home address also.

3.-------------------------
Section 8.2.2. 4th bullet
s/The local mobility MAY set/The local mobility anchor MAY set

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

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

6.-------------------------
As per section 9.2.1 MAG will always set A bit in BRI message which
it sends to LMA
Following lines gives an impression that that there may be some case
in which MAG sends BRI without setting A bit.
IMHO following line of section 3.1 should be modified to reflect the
spirit of section 9.2.1.
"If the local mobility anchor processes the BRI message
 successfully and the (A) bit is set in the BRI, the local mobility
 anchor responds to the mobile access gateway by sending a BRA
 message.

Thanks and Regards,
Sandesh Kumar Sodhi
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 4 Aug 2008 14:10:56 -0500

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
> 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).

[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.

> 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.

> When binding is administratively down MAG keeps on 
> transmitting PBU and LMA replies PBA with status = 
> Administratively prohibited.

[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.
> In the sections related to MAG and LMA there should be 
> mention of IPv4 home address also.

[Ahmad]
Okay. I will make sure that we mention the IPv4 address. Although, that
is independent of the BRI process. If a BCE is revoked all resources are
removed including the IPv4 Home address.

[Ahmad]
Ok, thx.

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

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

[Ahmad]
Like what?

> As per section 9.2.1 MAG will always set A bit in BRI message 
> which it sends to LMA Following lines gives an impression 
> that that there may be some case in which MAG sends BRI 
> without setting A bit.
> IMHO following line of section 3.1 should be modified to 
> reflect the spirit of section 9.2.1.
> successfully and the (A) bit is set in the BRI, the local 
> mobility  anchor responds to the mobile access gateway by 
> sending a BRA  message.

[Ahmad]
The intent is to mandate the MAG to set the (A) bit whenever the (G) bit
is set. We will try to clarify the text.

---

From: Sandesh <[email-masked]>
Date: Wed, 6 Aug 2008 17:09:07 +0530

Hi Ahmad,

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

Thanks and Regards,
Sandesh Kumar Sodhi

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 12:41 AM
To: Sandesh; [email-masked]
Subject: RE: [MEXT] Queries/comments on 'Binding Revocation for IPv6
Mobility' draft

Hi Sandesh,

Regards,
Ahmad

> 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).

[Ahmad]

~~~~~~~~~~~~~
[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.
~~~~~~~~~~~~~

> 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.

[Ahmad]

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.
~~~~~~~~~~~~~~

[Ahmad]

~~~~~~~~~~~~~
[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.
~~~~~~~~~~~~~

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 Aug 2008 09:00:30 -0500

Hi Sandesh,
It is always appreciated to receive comments from people who actually
design and implement the protocol!
Please see inline.

Regards,
Ahmad
 
> from using 
> 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).
> 
> 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.
> ~~~~~~~~~~~~~
[Ahmad]
Hmmmm .. I have not looked at SS7 for a long time.
However, I am not sure if the comparison here is valid. A link
associated with an established session in plain vanilla SS7 is a
dedicated link that is always used for carrying the traffic of that
session. In IP, the data could use different routes all the time and I
am not sure if what you are trying to do here is applicable.

> received in 
> binding (i.e.
> 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:
> 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]
> 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'

[Ahmad]
I am sorry, I am missing something here. What is the relevance that the
AAA and the LMA are run by two different companies here. If that AAA
needs to maintain AAA functionality for a specific users where they may
be offered service at a specific LMA, then there has to be a specific
mechanism to keep these two entities in sync. Otherwise, there is
something broken.

May be if you give an exact example, then we can see what is broken in
there and try to fix it. At any rate, that is also out-of-scope Binding
Revocation.

> 
> 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.
>  MAG removes BUL entry. LMA and MAG removes data tunnel  for 
> the MN. This involves interaction with AAA server.
> 

[Ahmad]
This functionality is out-of-scope.
> 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.
> 
[Ahmad]
It seems that you have assumed that the MAG and the LMA are always in
sync with respect to the state of every single BCE. In my experience
there are many cases where the LMA and the MAG could be out of sync with
respect to the state of a single or some BCEs. 

> 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.

[Ahmad]
The case you mention here is not related to Binding Revocation. Again,
IMO, this is an implementation specific. I would be happy to continue
this discussion off list if you need my personal opinion. BTW: Is the
scenario you are concerned about allowed by base PMIPv6 protocol? I
believe that should be allowed there first then we can talk how Binding
Revocation or something else need to address it.

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

> The draft mentions that handling of BRA(status = partial 
> success) is defined by LMA's local policy (Section 9.1.1. 
> Third bullet).
 
[Ahmad]
Did you mean a different section. I can not find what you reference
here.

> 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 
> 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) 

[Ahmad] 
If the MAG decides to remove a MN Binding from the BUL for any valid
reason that justify sending a BRI, even for a MAG local policy, the MAG
sends a Binding Revocation to the LMA to gracefully clean resources and
avoid unnecessary traffic, for a specific Mobile node which is no longer
is hosted at the MAG, for example. The main concept is to allow this
functionality in a flexible manner that different deployment can specify
what fits its own. In other words, sometimes the BRI message requires a
BRA and that why the draft specify when the (A) bit is set and the
retransmission, etc. However, in certain conditions, the revoking node
may not set the (A) bit and consequently delete the MN Binding
immediately as soon as it sends the BRI.

Having that in mind, I agree with you that we probably need some
clarification added to this status code. Like a recommendation what to
do. IMO, if the MAG has a valid reason to revoke the MN Binding, then
the LMA response in BRA is nothing but acknowledgement that the LMA has
received the BRI and processed it. Let us assume that one of the
identified sessions in the BRI was already removed before the LMA
receive the BRI message, in this case, the LMA has the option to either
set the status to partial success or success. 

Another example, let us assume that when the MAG sent the BRI message
with the (G) bit is set one of the MN moved to another MAG and a handoff
PBU was received at the LAM before the BRI. What the LMA should do here?
If I were the designer for any implementation, I would allow the LMA to
revoke all other MNs BUT not this one. Then the LMA may send a BRA with
'Partial success" and should include the MN session identity in the BRA.
In such a case, the MAG should not do any further actions and should
delete that MN resources as well, if it has not done so already.

~~~~~~~~~~~~~

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 7 Aug 2008 07:25:26 -0700 (PDT)

Hi Sandesh,

Couple of comments ..

I'm not sure, if this concept of session freezing is needed in mobility.
Suspending a mobility session (BCE/BUL) will result in the application
breakdown. Lets say, the mobile have existing TELNET and other sessions,
freezing the traffic for some time will break those sessions. If this
is still desired, the operator can simply apply some traffic policies
to drop the traffic locally. But, if this needs to notified to the
peer (LMA or MAG), we are now looking at rate-limiting notifications and
that's not the scope of Binding Revocation.

> inhibited so that no traffic goes on that link.

Revocation is an atomic and a permanent action. There is no reversal and
no second thoughts. The MAG can always re-establish the session.

Sri

---

From: Sandesh <[email-masked]>
Date: Thu, 7 Aug 2008 21:13:31 +0530

Hi Ahmad,

Thanks very much to you and Sri for valuable inputs.

>Did you mean a different section. I can not find what you reference here.
>
>> For MAG the draft does not seem to be mentioning anything.

[SANDESH]
Sorry! I mentioned wrong section number.
I meant section '8.1.2 Third bullet'. This section does talk about
local policy for handling 'partial success' BRA at LMA.
IMO Section 9.2.2 should include similar lines for MAG.

Thanks and Regards,
Sandesh Kumar Sodhi