[Ahmad]
Actually, the intention was for the case when the (G) bit
set and the R.
T. is set to "Per-Peer policy", which means all binding
between the
MAG and the LMA to be deleted.
The above paragraph says nothing about "per-peer policy".
It says for
any bulk termination, the LMA must perform this additional
authorization check.
[Ahmad]
Sure, what about the following:
Additionally, in the case when the LMA receives a BRI
which indicates
a bulk termination where the (G) bit is set and the Revocation
Trigger field is set to "Per-Peer Policy", the LMA MUST
verify that
the MAG sending the binding revocation indication message is
authorized to invoke Global revocation.
Now comes the additional question. What is special about
"Per-Peer Policy"? The MAG should still be allowed to revoke
the bindings it created. Why require an additional authorization step?
[Ahmad]
Please see the responses below.
Additionally, I see your point, but something could have
happened to
the MAG between the time it created all of these session
and time of
terminating them.
Like what?
[Ahmad]
The same reason which was behind allowing the LMA to
validate that the
MAG is allowed to send the PBU and the MN is present at the access
side associated with the MAG.
In your reply you said something about "something could have
happened to the MAG". What is that? What you wrote above is
not a response to that.
As I said in the earlier email, the analogy is not correct.
[Ahmad]
Please see the responses below.
I do not see any problem to demote "MUST" to "SHOULD", would that
address your concern?
Well, I would still like to get rid of this additional
authorization step.
[Ahmad]
Sure, that is your view, but please see the response below.
Even in the case of creating a
single binding, RFC5213 left the door open for the LMA to
make sure
that the MAG is authorized for sending the PBU on behalf of
the mobile node.
I don't agree with this analogy. When the MAG creates a
proxy binding
cache entry for the mobile node, it is altering the
routing for the
mobile node.
[Ahmad]
And when it send a bulk revocation it does not alter the
routing of a
BUNCH of MNs?
hmm... the MAG created the bindings, so it can delete them.
The MAG can always send a de-registration PBU for each of
those bindings without an extra authorization step. So not
clear why it is required for binding revocation.
[Ahmad]
Okay. I remember very well that a similar topic while PMIPv6 is
developed generated a lot of heated discussion. In any case, let me say
the following:
1. In PMIPv6 [RFC3215], it says the following under section 4:
The Mobile IPv6 specification [RFC3775] requires the home agent to
prevent a mobile node from creating security associations or creating
binding cache entries for another mobile node's home address. In the
protocol described in this document, the mobile node is not involved
in creating security associations for protecting the signaling
messages or sending binding updates. 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.
2. If per PMIPv6 specification, the LMA needs to make sure that the MAG
is always authorized to send a PBU message on behalf of any mobile node
at any time, why it is NOT acceptable, if the MAG sends a BRI which
requires deleting all Bindings between the LMA-MAG Pair, to require the
LMA to check if the MAG is authorized to do such action.
In a race condition case, the home agent may receive a
BU from the
mobile node while the mobile node's BCE has the revocation in
progress flag set, the home agent should handle this
case based on
the reason for sending the Binding Revocation Indication
message and
its local policy. In this case, if the home agent
accepts the BU, it
needs to update the mobile node BCE accordingly, e.g.
removing the
revocation in progress flag.
Why is this needed? Shouldn't the home agent just reject
the BU based
on the fact that it in the process of revoking the binding? Why
should this
be subject to "a local policy"? If you do want to
multiple options
here, you have to recommend a default one.
[Ahmad]
I guess this text was added to address the case when the
HA sends a
BRI message to the MN when the mobile node just made a
handoff and
sent a BU with a new care-of address. IMO, the HA handling
should be
based on the reason for sending the BRI. However, if we
allow the HA
to reject the BU, which Status Code should we use?
If you are using Mobile IPv6 and the home agent has
already decided
to revoke a mobile node's binding, why should it accept a
BU from the
new CoA?
It should just reject the BU. For the status code, you can perhaps
use "Administrative Reason".
[Ahmad]
I thought about that BUT I do not think that is a good option.
Because, if the MN receives a BA with Administrative reason, the MN
MAY get confused and stop trying to connect. IMO, leaving
the existing
text probably safer, However, there is another option, MAY
be the LMA
would ignore the BU until it receives BRA or timeout. That would
guarantee that the MN will continue to try to connect. The problem
here, is in the case of handoff, it may cause some
unnecessary delay.
-OR-
If possible, we can define a new BA Status Code?
How about using "Insufficient Resources", instead? This tells
the mobile node that the current home agent is not usable and
it should find another one.
[Ahmad]
Okay, since the wg agreed to the current behaviors and the proposed one
is quite very different from the one captured in the draft, I will send
a separate email and ask if the group agrees to the change. If there is
a consensus for the change, then we can adopt it.