[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
Hi Vijay,
Thanks for your detailed review and comments.
Will go through them and respond back, hopefully over the weekend.
Cheers!
Regards,
Ahmad
> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On
> Behalf Of Vijay Devarapalli
> Sent: Friday, March 06, 2009 7:21 PM
> To: draft-ietf-mext-binding-revocation at tools.ietf.org
> Cc: Julien Laganier; mext
> Subject: [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
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>