[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Binding Revocation almost ready for IESG
Hi Vijay,
Regards,
Ahmad
> -----Original Message-----
> Hi Ahmad,
>
> On 5/19/09 11:01 PM, "Ahmad Muhanna" wrote:
>
> >> I have a couple of comments on version 10
> >>
> >> You explained to me that 3GPP2 wants to differentiate
> between the two
> >> following triggers.
> >>
> >> 3 Inter-MAG Handover - same Access Type
> >> 4 Inter-MAG Handover - different Access Type
> >>
> >> That's fine.
> > [Ahmad]
> > Thanks for agreeing on adding these two back! :)
> >
> >> But what should the MAG behavior be when it receives the following
> >> trigger?
> >>
> >> 5 Inter-MAG Handover - Unknown
> >>
> > [Ahmad]
> > The MAG will reject the BRI with code "MN still attached"
> :) I mean,
> > the MAG is supposed to check whether the mobile node is attached or
> > not and based on its finding, it should reply back either
> success or
> > failure, e.g., "MN still attached".
>
> Ok.
>
> So what does the LMA do now? The new MAG is saying the MN
> attached to it and the handoff state is "unknown". The old
> MAG is saying the MN is still attached? Shouldn't this result
> in a new mobility session being setup for the attachment
> through the new MAG? It won't be treated as a handover
> anymore. This probably needs to be explained.
>
[Ahmad]
The LMA does nothing other than what is documented in RFC5213.
This is exactly the same case as if the LMA did not receive a
de-registration from the previous MAG and the timer expired. I do not
think it is necessary to add anything, but we could add a pointer to
RFC5213 for this specific case when handling the AD comments.
> >> On authorization for bulk revocation, we need some text
> that explains
> >> how the LMA is supposed to check if a particular MAG is
> authorized to
> >> perform bulk revocation. Is this list of
> >> "MAGS-authorized-for-bulk-revocation"
> >> manually created on the LMA? If not, how is this populated?
> >>
> >> (FWIW, I still think this authorization check should be
> removed from
> >> the draft).
> >
> > [Ahmad]
> > I think we keep coming back to this point:) It is based on the home
> > domain policy.
> >
> > 1. Some home domain probably wont allow this across
> different domain
> > period. Example: only between MAG(s) and LMA(s) that belong to the
> > same operator.
> >
> > 2. It could be as simple as all MAGs which IDs matches a
> simple string
> > of "wildcard at xyz.com"
> >
> > 3. It could be as simple as "every MAG which is able to
> establish an
> > IPsec SA for protecting PMIP signaling is authorized for Global
> > revocation; I guess this matches your views to some extent.
> >
> > 4. etc.
> >
> > Leaving the details out of scope gives the flexibility for the home
> > domain to enforce its own policy freely.
> >
> > I hope this address your concern.
>
> No, it doesn't. In general, you can't require some behavior
> on the LMA and then not specify how the LMA is supposed to
> implement it.
[Ahmad]
Vijay,
This behavior is NO different than what is currently required in
RFC5213. I believe we discussed this offline before and now we are going
back again. :)
What I meant by out of scope is: out-of-scope of this document because
RFC5213 contains very similar requirement already. Why it is NOT an
issue in RFC5213 when the LMA needs to ensure that the MAG is authorized
to send a PBU on behalf of the mobile node and a specific prefix? This
is exactly similar.
If you like, I could cut and paste the text from RFC5213 and include it
this draft or add a pointer to section 4.0 of RFC5213.
Here the related text:
"
...................................... Therefore, the local mobility
anchor MUST restrict the creation and manipulation of proxy bindings
to specifically authorized mobile access gateways and prefixes. The
local mobility anchor MUST be locally configurable to authorize such
specific combinations. Additional mechanisms, such as a policy store
or Authentication, Authorization, and Accounting (AAA) may be
employed, but these are outside the scope of this specification.
"
> Here is another suggestion. Remove all text
> related to the authorization check when the MAG sends a bulk
> revocation message in the draft.
[Ahmad]
No.
Again, this is no different than what is mentioned above. No. 1.
No. 2. This functionality has been in the draft since day one and all of
a sudden it becomes a problem without a clear reason.
> Instead, add the following
> text to the Security Considerations sections
>
> An LMA implementation should be careful in processing bulk
> revocation
> messages from the MAGs. Bulk revocation, when used
> inappropriately, can
> deny mobility service to a large number of mobile nodes.
[Ahmad]
This is an interesting statement to add in the security section! If you
admit there is a problem why removing the solution to start with? If you
have a problem handling this, then you probably have a problem with
RFC5213.
> Therefore the
> LMA should check if the MAG is authorized to send a bulk revocation
> message before processing the message. To implement this
> check, the LMA
> should be configured with the information about which MAGs
> are allowed to
> perform bulk revocation. For example, all the MAGs in a particular
> PMIPv6 domain can be authorized for bulk revocation, while
> othes are not.
> If the LMA decides to reject the bulk revocation message
> from the MAG,
> it should send a BRA message with status set to '130'
> (Global Revocation
> NOT Authorized).
>
> Feel free to modify the above text.
>
> In section 3.1, delete
>
> When the local mobility anchor
> receives such Binding Revocation Indication message, it
> ensures that
> the mobile access gateway is authorized to send such bulk
> termination
> message and then processes the Binding Revocation
> Indication message
> accordingly.
>
> In section 3.4.2, replace
>
> When the local mobility anchor
> receives a Binding Revocation Indication message with the
> (G) bit is
> set from a specified mobile access gateway, the local
> mobility anchor
> first checks if the mobile access gateway is authorized to
> use global
> revocations and then responds with the appropriate status code by
> sending a Binding Revocation Acknowledgement message as in
> Section 9.2.2.
>
> With
>
> When the local mobility anchor
> receives a Binding Revocation Indication message with the (G) bit
> set from a specified mobile access gateway, the local
> mobility anchor
> first processes the message and then responds with the appropriate
> status code by sending a Binding Revocation Acknowledgement message
> as in Section 9.2.2.
>
> In section 4, delete
>
> Additionally, in the case when the local mobility anchor receives a
> Binding Revocation Indication which indicates a bulk termination
> where the (G) bit is set and the Revocation Trigger field is set to
> "Per-Peer Policy", the local mobility anchor MUST verify that the
> mobile access gateway sending the binding revocation indication
> message is authorized to invoke global revocation.
>
> In section 9.2.1, delete
>
> The local mobility anchor MUST verify that
> the identified mobile access gateway as per the value
> in the MN-ID
> option is authorized to use the Global revocation. The
> mechanism
> the local mobility anchor uses to verify the mobile
> access gateway
> authorization is out of scope of this document.
>
> Hope this works for you..
>
> Vijay
>
>