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

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hi Sandesh,
It is always appreciated to receive comments from people who actually
design and implement the protocol!
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.
> ~~~~~~~~~~~~~
[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.

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



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

[Ahmad]
This functionality is out-of-scope.
> 
> 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.
> 
[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.
> Is such a case allowed for binding revocation.

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

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

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


~~~~~~~~~~~~~
> 
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext