[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
Hello,
I reviewed this document. It needs some work before it can be sent to
the IESG. Comments follow.
Abstract
This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources.
How about saying
This document defines a binding revocation mechanism to terminate a
mobile node's mobility session and release the associated resources.
In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration
has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. In some networks where
Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4
registration revocation mechanism has been specified [RFC3543].
The MIPv4 registration mechanism was specified in the IETF, not in the
networks where Mobile IPv4 has been deployed. :) I think the last
sentence needs to be re-worded.
This document defines the semantics of the revocation mechanism of a
mobile node registration binding, which could have been established
using a Client Mobile IPv6 or any of its extensions, e.g. Proxy
Mobile IPv6 signaling.
Re-write as
This document specifies the binding revocation mechanism to remove
a mobile node's mobility sessions. The same mechanism can be used to
revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy
Mobile IPv6 [RFC 5213].
We don't use "Client Mobile IPv6" in the IETF. :) And we need references
to RFC 3775 and 5213, since they are mentioned here for the first time
in this document.
2.2. Terminology
All the general mobility related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 specification [RFC3775] and
Proxy Mobile IPv6 specification [RFC5213].
Maybe you should define the term "mobility agent" here. Basically, it
would be the Home Agent, LMA and the MAG. You have used "mobility node"
throughout the document. A "mobility node" is kind if vague. Suggest
replacing all occurrences with "mobility agent".
In the case of Client Mobile IPv6, the revocation procedure can be
initiated by the home agent.
"can be"? It is always the home agent right? Suggest re-wording to
In the case of Mobile IPv6, the revocation procedure is initiated by
the home agent.
If the home network decides to
terminate the service of the mobile node, the home agent sends a
Binding Revocation Indication (BRI) message to the mobile node. The
home agent includes the HoA in the type 2 routing header as specified
in [RFC3775] to indicate the impacted mobile node binding. When the
mobile node receives a BRI message with its HoA included and the
Acknowledge (A) bit is set, the mobile node responds by sending a
Binding Revocation Acknowledgement (BRA) message.
hmm... Won't the mobile node delete the binding first before sending the
BRA message?
In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also
be initiated by the home agent.
Again, it is always the home agent that initiates the revocation
mechanism. Who else can do it in DS-MIPv6?
If the home network decides to
terminate the service of the mobile node, the home agent sends a BRI
message to the mobile node to indicate the termination of the mobile
node IP Mobility service. The home agent may include the HoA option
s/HoA option/IPv4 Home Address Option/
I don't know of any other option that carry the IPv4 home address.
with the mobile node assigned home IPv4 address. After receiving the
BRI message with the Acknowledge (A) bit is set, the mobile node
responds by sending a BRA message.
Again, the mobile node would delete the binding first, I guess.
3.2. Client MIPv6 and DSMIP6 Use Case
s/Client MIPv6/Mobile IPv6/
Binding revocation mechanism is applicable to Client Mobile IPv6 and
DSMIPv6 session(s) when the home agent needs to inform the mobile
node that its binding registration has been revoked, e.g. for an
administrative reason. This mechanism enables the home domain to
dynamically allow the user to act upon the revocation message in
order to recover its interrupted mobile IPv6 services.
What does the last sentence mean? Isn't the mobile node required to do
something when it gets a revocation message? The mobile node has to find
another home agent, right? How can its services not be interrupted?
In this case, the home agent sends a BRI message to indicate to the
mobile node that its current mobile IPv6 binding has been revoked and
it no longer can receive IP mobility service. The home agent
includes the mobile node home address in Type 2 routing header as
used in [RFC3775] and sets the Revocation Trigger field to a proper
value, e.g. Administrative Reason. In the case of DSMIPv6 session,
the home agent may additionally include the mobile node assigned IPv4
Home Address in the IPv4 Home Address Option. When the mobile node
receives the BRI message, it sends a BRA message as described in
Section 11.2 to the home agent. Figure 1 illustrates the message
sequencing when home agent revokes a mobile node binding
registration.
MN HA
| |
| HoA in Type 2 Hdr + BRI [seq.#, A bit] |
|<------------------------------------------|
| |
| |
| |
| HoA in Destination Option BRA[seq.#] |
|------------------------------------------>|
| |
| |
Why is the HoA required in a destination option? The BRA message can
just be sent from the CoA with no home address option in it. The Home
Agent just needs to match the BRA to the BRI message using the sequence
number field.
BTW, in figure 2, there is no HoA destination option in the BRA message.
3.3.1. Termination of Multiple Care-of Addresses Bindings
In the case of multiple care-of addresses, the home agent maintains
different binding for each pair of care-of address and home address.
These bindings are also indexed and identified during the mobile node
registration using a Binding ID mobility option [ID-MCoA]. In this
case, the HA may revoke any binding, more than one binding, or all of
the bindings for the same mobile node home address.
Re-phrase the last sentence as
In this case, the HA may revoke one or more bindings for the same
mobile node home address.
In the case when home agent revokes a single binding for a mobile
s/In the case when/In case/
node with multiple care-of addresses registration, the home agent
sends a BRI message to the mobile node with the corresponding BID
option included and the HoA is in the Type 2 routing header.
Rephrase as
node with multiple care-of addresses registration, the home agent
sends a BRI message to the mobile node with the corresponding BID
option included.
If the
home agent needs to revoke more than one of the mobile node
registered care-of addresses, the home agent includes all the
corresponding Binding ID options which reference these care-of
addresses in the same BRI message.
Rephrase as
If the
home agent needs to revoke more than one of the mobile node
registered care-of addresses, the home agent includes all the
corresponding Binding ID options in the same BRI message.
3.4. Proxy MIPv6 Use Case
Since the Mobile node does not participate in the mobility mechanism
in the case of PMIPv6, there are many scenarios where Binding
Revocation mechanism is needed to clean resources and make sure that
the mobility entities, e.g. MAG and LMA, are always synchronized
with respect to the status of the existing proxy mobile IPv6
bindings. The binding revocation mechanism is generic enough that
can be used in all applicable PMIPv6 scenarios and deployment
options. For example, this revocation mechanism is still applicable
and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports
and when the mobile node uses IPv4 or IPv6 address as specified in
[ID-PMIP6-IPv4].
Thats a tall claim. We don't really where all PMIPv6 might be used.
Suggest replacing the last two sentences with the following.
The binding revocation mechanism is generic enough that can be
used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4].
3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding
The local mobility anchor may send a BRI message to the mobile access
gateway, hosting a specific proxy mobile IPv6 binding, with the
appropriate value in the revocation trigger field to indicate that
the mobile node binding has been terminated and the MAG can clean up
the applicable resources. When the MAG receives a BRI message, the
MAG identify the respected binding and if the (A) bit was set in the
s/identify/identifies/
The process identified above can also be used by the LMA in scenarios
other than the inter-MAG handoff with the proper revocation trigger
value to indicate to the peer MAG that a specific proxy mobile IPv6
binding or bindings have been revoked.
sMAG tMAG LMA
Can we call this oldMAG and newMAG? We have traditionally used these
terms in the IETF.
4. Security Model
The binding revocation protocol described here uses the same security
association between the MN and the HA or the MAG and the LMA that has
been used to exchange the corresponding Client MIPv6 or Proxy MIPv6
BU and BA when the mobile node binding was created. If IPsec is
used, the traffic selectors associated with the SP protecting BU and
s/SP/SPD entry/
There are few places where this needs to be replaced.
BA MUST be extended to include Binding Revocation Signaling MH type
<IANA-TBD>. Extending the traffic selectors of the SP in order to
reuse the SA protecting BU and BA (instead of creating new ones)
ensures that those SA will be up and running when the revoking entity
needs to send a Binding Revocation Signaling message.
Additionally, in the case when the LMA receives a BRI which indicates
a bulk termination, i.e., the (G) bit is set, the LMA MUST verify
that the MAG sending the binding revocation indication message is
authorized to invoke Global revocation.
Why require this? It is after all the MAG that created all these
bindings. And now the MAG wants to delete the bindings it created at the
LMA. So why does this alone require an additional authorization step?
5. Exchanging Binding Revocation Messages over an IPv4 Transport
Network
In some deployments, the network between the MAG and the LMA may only
support IPv4 transport. In this case, the Binding Revocation
messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding
Update and Proxy Binding Acknowledgment messages are sent using UDP
encapsulation to traverse NATs, then the Binding Revocation messages
are sent using the same UDP encapsulation. The same UDP port that
was used for the Proxy Binding Update and Proxy Binding
Acknowledgement messages will also be used when transporting Binding
Is the destination port in the BRI set to the DS-MIPv6 port or the
source UDP port seen on the PBU from the MAG to the LMA? The NAT on the
path might have changed the source UDP port on the PBU. So do you want
the BRI to be sent to that port?
The following options are valid in a Binding Revocation Indication:
o Home Network Prefix option [RFC5213]. This option MAY be used
when the (P) bit is set. This option MUST be present when the BRI
is used to revoke a single PMIP binding cache entry.
o Mobile Node Identifier Option [RFC4283]. This option is mandatory
when the (P) bit is set. Additionally, If the (G) bit is set by
the mobile access gateway, this option carries the MAG identity.
o Binding ID mobility option [ID-MCoA]. This option is mandatory if
the sending mobility entity request to terminate one binding of a
multi care-of addresses bindings for the same mobile node. The
sending mobility entity may include more than one of the Binding
ID mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4
address [ID-DSMIP6]. This option is included only when the IPv4
HoA Binding only (V) bit is set.
o Alternate Care-of Address mobility option [RFC3775]. This option
MAY be included to indicate the Care-of Address of the mobile
node's binding that is being revoked. In the case when the Global
(G) bit set, this option identifies all the mobility bindings that
share the same care-of address. Additionally, if the Global (G)
bit set, more than one Alternate Care-of Address mobility options
MAY be present in the BRI message.
I don't understand the last one. Why is this needed? If Mobile IPv6 is
used, the home address would identify the right binding that needs to be
deleted. If MCoA is used, then the BID would identify the right binding.
If PMIPv6 is used, the home network prefix option, MN ID option and the
IPv4 home address options are sufficient to identify the right binding.
So what is the last one used for?
7.1. Sending Binding Revocation Messages
When sending a Binding Revocation message, the sending mobility node,
initiator, follows the rules of constructing a Mobility Header as in
Section 9.2 of [RFC3775] with the exception of setting the MH Type
field to <IANA-TBD and the appropriate value of the Binding
Revocation Type field.
Section 9.2 of RFC 3775 talks about processing Mobility Headers. Perhaps
you meant some other section from RFC 3775.
The mobility entity which initiates the revocation process,
initiator, MUST use the underlying IPsec security association that
You have already introduced the term "initiator" to refer to the
"sending mobility node" in the first paragraph. It is repeated here.
When a mobility entity initiate the binding revocation process by
sending a Binding Revocation Indication message, the initiator MUST
construct the BRI message as described in Section 6.1. In the BRI
message, the initiator MUST set the Sequence Number field to the next
sequence number available for Binding Revocation.
Why? It can be any random number, right? It is only used for matching
BRA messages to BRI messages. You don't normally sending a sequence of
BRI messages to a mobile node right? Not like sending binding updates
with increasing sequence numbers.
On the other hand, when the responder acknowledge the BRI message by
"On the other hand" of what? Just say "When the responder..."
7.2. Receiving Binding Revocation Messages
When receiving a Binding Revocation message, the receiving mobility
node MUST verify the Mobility Header as in [RFC3775].
I think here you should mention section 9.2 of RFC 3775.
If the packet
is dropped due to failing any of the Mobility Headers test check, the
receiving node MUST follow the processing rules as in Section 9.2 of
[RFC3775]. For example, it MUST send a Binding Error message with
the Status field set to 2 (unrecognized MH Type value) if it does not
support the received binding revocation message type.
The "MUST" here does not make sense. Re-word the last sentence to,
If the receiving node does not support the Binding Revocation
Indication message and does not recognize the new MH type, it sends
a Binding Error message with the Status field set to 2, as described
in [RFC3775].
Since some mobility entities, e.g. LMA and MAG, are allowed to
receive and possibly send a BRI or a BRA for different cases, IPsec
mechanism will prevent any possible man in the middle reflection
attack.
Not sure what this means. What is IPsec is not used? You have indicated
in a number of places in the document that there could be other mechanisms.
Upon receiving a packet carrying a Binding Revocation Indication, the
receiving mobility entity, responder, validates that the packet was
received protected with the underlying IPsec protection with the
responding mobility entity.
Here we are mandating IPsec protection for the BRI message. Is this the
intention? If yes, a few other places need to be fixed.
Upon receiving a packet carrying a Binding Revocation
Acknowledgement, the receiving mobility entity, initiator, MUST
validate that Sequence Number field matches the Sequence Number of an
outstanding Binding Revocation Indication that was sent by the
initiator. If the Sequence Number does not match any sequence number
of any of the outstanding BRI, the receiving node MUST ignore the
message but MAY log the event.
s/ignore/silently drop/
7.3. Retransmission of Binding Revocation Indication
If the sending mobility entity does not receive a Binding Revocation
Acknowledgement in response to the outstanding Binding Revocation
Indication before the MINDelayBRIs timer expires, the mobility
entity, e.g. LMA, may retransmit the same BRI message up to the
BRIMaxRetriesNumber as defined in Section 12. If the revoking
mobility entity does not receive a BRA message after the maximum
number of retransmits have been sent, the revoking mobility entity
can clean the mobile node binding cache and all resources associated
with this binding. The revoking mobility entity may log the event.
Is it a simple re-transmit scheme or do we have to exponentially backoff
for subsequent BRI messages?
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.
In a race condition case, the local mobility anchor may receive a PBU
from the mobile access gateway while the mobile node's proxy BCE has
the revocation in progress flag set, the LMA should handle this case
based on the reason for sending the Binding Revocation Indication
message and its local policy. In this case, if the LMA accepts the
PBU, it needs to update the mobile node proxy BCE accordingly, e.g.
removing the revocation in progress flag.
Same as before. I think the LMA should just reject the PBU.
I didn't review much of the text in sections 9.1, 9.2, 10.1, 10.2, 11.1
and 11.2. These sections have too much repetitive text
13. IANA Considerations
This document defines two new messages BRI and BRA, as described in
Section 6.1 and Section 6.2 by using Binding Revocation types of 1
and 2 of the Binding Revocation Message which is defined in in
Section 6 and uses a MH type <IANA-TBD>. The new Mobility Header
type value needs to be assigned from the same numbering space as
allocated for the other Mobility Header types.
This section is not complete. Needs a re-write.
We define one new mobility header message - the binding revocation message.
Then we need to create a new namespace for the "Binding Revocation Type"
field with the current assignments.
0 Reserved
1 Binding Revocation Indication Message
2 Binding Revocation Acknowledgement Message
All other values are reserved
Then we need to create another namespace for the "Revocation Trigger" in
the Binding Revocation Message. I think IANA should manage this field too.
Then we need yet another namespace for the "Status" field in the BRA
message. I think this should also be managed by IANA.
So you need to request all of these from the IANA.
Hope this helps.
Vijay