Subject: [MEXT] AD review of draft-ietf-monami6-multiplecoa

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Sep 2008 14:48:51 +0300

I have reviewed this draft. Overall it was well written, easy to read 
and in relatively good shape; no major showstoppers. But as usual there 
are a number of issues that need to be looked at before we can progress 
this further. Some of the biggest ones are:

- you need to specify default behaviour policy that makes sense
- the use of BIDs in care-of address tests requires further thought (or 
additional justification)
- whether outer source address verification is necessary for Ipsec tunnels
- weak recommendations for bulk address verification
- various small mistakes and inconsistencies
- a number of questions

Here are the details. Technical:

> The BID MUST be unique for a binding to a specific care-of address for 
> a given home address and care-of address pair.

I cannot parse this. Or maybe I just do not understand what you are 
saying here. Are you saying that the BID must be unique, period (what I 
would have expected)? Or are you saying that the tuple <bid, hoa, coa> 
must be unique?

> It uses the first matched binding or a binding in a round robin 
> fashion.  This is implementation dependent and configurable on a node.

Round-robin would create unacceptable transport layer issues. (Such as 
potentially massive reordering.)

It is fine to leave the policy aspects to another spec. But it is not 
fine to leave the default behaviour unspecified, specified in a partial 
way, or specified in a way that causes problems elsewhere. It is also 
inappropriate to leave this as a configuration problem. Even when we 
eventually have the policy control, for interoperability the other side 
needs to know what the behaviour is when no policy has been set.

I would suggest one of the following default approaches:

1. Home agent sends all traffic to the coa associated with the lowest 
BID number (or the primary address used in the BU). Mobile node can send 
its traffic from any interface, but should avoid unnecessary switching 
between interfaces, as that might affect transports.

2. As above, but home agent sends its traffic to the coa that it last 
received traffic from the mobile node.

3. As above, but both sides send traffic to the address that was last 
verified to work (HA sees a BU or payload packet from an address, MN 
sees a BA or payload packet to an address).

These techniques also help a little bit with failure detection, which is 
an essential part of any multi-interface solution.

> In case the binding cache lookup for data packets, using the 
> combination of home address and BID, does not return a valid binding 
> cache entry, the home agent MAY perform another lookup based on only 
> the home address.
And I would prefer this to be set to a SHOULD, i.e., revert to a default 
policy when there is no policy or the policy is in error. It is useful 
to avoid blackholing traffic, when it costs nothing to do so. I do 
expect that some day some mobile nodes and home agents will be out of 
sync with their BIDs, so lets make the system fail safely even in that case.

> The sequence number value SHOULD be shared among all the binding 
> update list entries related to binding updates sent to a particular 
> home agent or correspondent node.  Whenever a mobile node sends either 
> individual or bulk binding update, the sequence number is 
> incremented.  On the other hand, if a mobile node manages an 
> individual sequence value per binding update list, a mobile node 
> SHOULD carefully select the sequence number value for the bulk binding 
> update. (complex algorithm omitted.)

Is there some reason why we need to allow this flexibility? If you had 
said the sequence number is always shared, you would not need an 
algorithm to determine when a bulk update can be sent.

> Status
>
> The Status field is an 8-bit unsigned integer.  When the Binding 
> Identifier mobility option is included in a Binding Acknowledgement, 
> this field overwrites the status field in the Binding Acknowledgement.
Overwrites the status for all, even in a bulk registration? Or just for 
this BID?

> Overwrite (O) flag
>
> When this flag is set, all the binding cache entries for a mobile node 
> are replaced by new entries registering with this binding update message.

Some of the fields of the BID option feel like they are not associated 
with a particular BID. For instance, why isn't the O flag in the BU? Is 
the O flag used in a BA, COT, or COTI?

> MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)
>
> Bulk binding registration is not supported.  Note that the bulk 
> registration is optional procedure and might not be available on a 
> home agent.

Lets make this a bit more general by including also the case where it is 
not allowed for some reason. (E.g., with correspondent ndoes. I could 
also think of a situation where the home agent requires that all 
registrations come from a source address claimed to be the care-of 
address. MCOA can be supported in this situation as well, but bulk 
registrations would have to be disabled.)

Also, can you include text to say that the mobile node should retry by 
sending the individual registrations separately? Unless you already say 
it somewhere else...

> 5.1. Management of Care-of Address(es) and Binding Identifier(s)

This section should be clearer about when the multiple bindings are 
actually used by default. Always when there are more than one interface? 
When there is more than one address? When policy dictates? Personally, I 
think this should only be used when explicitly configured to do so.

> 5.2. Return Routability: Sending CoTI and Receiving CoT

I'm not sure I understand the rational to include the BID option in the 
CoT and CoTi. As you mention, an identical process is used by the CN to 
calculate the cryptographic functions. Is this merely for the capability 
discovery? If so, perhaps you could use a flag or another mobility 
option that does not carry all the complex formats and semantics of the 
BID option...

> If the mobile node wants to replace existing registered bindings on 
> the home agent with the bindings in the sent Binding Update, it sets 
> the 'O' flag.  Section 6.3 describes this registration procedure in 
> detail.

I'm curious why this statement occurs only in Section 5.4 (bulk mcoa) 
but not in 5.3 (regular mcoa). Is there an implication that the 
semantics of the O flag are different in these two cases?

> 5.6.2. Using only Interface attached to the Visited Link
>
> The mobile node returns home in physically and shuts down the 
> interface attached to the home link.  As a result, a mobile node does 
> not return home even though it attaches to the home link by one of 
> interfaces.

I think we need a better definition returning home. My definition is 
that the mobile node attaches an interface to the home link. If the 
interface is shut down, it is no longer at home.

Given this, I'm not sure the discussion in 5.6.2 is relevant at all. Or 
if it is, perhaps you should have another section that talks about 
leaving home.

> 1.  Mobile node defends the home address by the regular Neighbor 
> Discovery Protocol (illustrated as topology-a in Figure 3).  The home 
> agent is the only router on the home link.  Therefore the home agent 
> is capable of intercepting packets without relying on the proxy 
> Neighbor Discovery protocol and the mobile node can manage the 
> Neighbor Cache entry of the home address on the home link as a regular 
> IPv6 node.

Even if the home agent is the only router on the link, it does not 
guarantee that it can receive all traffic destined to the home address. 
What about traffic between mobile nodes or other hosts in the link?

I think it is fine for you include scenario 1, but I would constrain it 
further, by stating that in this case the mobile node and the home agent 
must be the only two nodes on the link. I believe this is what some 
cellular arrangements look like, so it seems to fit.

> From Section 5.6.3 (about mixed home/foreign model):
>
> The mobile node MUST include the BID mobility option specifying the 
> BID the mobile node had previously associated with the interface 
> attached to the home link.  The 'H' flag MUST be set in the BID 
> mobility option.  None of the care-of address MUST be sent in the 
> Care-of Address field of the BID mobility option. ... Note that H flag 
> MUST be set for all the binding updates sent from the mobile node 
> (ex.  Binding Update for the interface(s) attached to the foreign 
> link(s)).
>
>

The requirement on no care-of addresses seems to preclude making a bulk 
registration. Why wouldn't it be allowed to return home *and* change one 
of the other care-of addresses at the same time? Please generalize the 
text to fit this situation as well.

> On the other hand, if the mobile node does not have any active care-of 
> address to send a Binding Update and leaves the home link (i.e. the 
> mobile node is completely disconnected), the home agent continues 
> forwarding packets to the mobile node until the expiration of all the 
> binding cache entries for the home address. Once all the bindings are 
> expired, the mobile node is assumed to be disconnected completely from 
> networks.
This seems wrong and contradictory to RFC 3775. If a binding expires, 
the home agent reverts back to doing nothing (not intercepting packets), 
but the packet should still be flowing to the home network, in case the 
mobile node is there!

> If no such mobility option is included in the Binding Acknowledgement 
> in response to a Binding Update for multiple care-of address 
> registration, this indicates that the originating node of the Binding 
> Acknowledgement does not support processing the Binding Identifier 
> mobility option. The mobile node MUST then stop multiple care-of 
> address registration with that node.
Please specify what state this leaves the attempted registration to. 
Presumably, the BU source address is registered as the only care-of 
address. The mobile node must then do something if this is not acceptable.

> If a mobile node receives a Binding Refresh Request with a Binding 
> Identifier mobility option, it indicates that the node sending the 
> Binding Refresh Request message is requesting the mobile node to send 
> a new Binding Update for the BID.  The mobile node SHOULD then send a 
> Binding Update only for the respective binding.  The mobile node MUST 
> include a Binding Identifier mobility option in the Binding Update.
.. to send a new Binding Update that updates at least the binding in 
question.

(I do not see a reason to prohibit the mobile node from sending a BU 
without BIDs at all, if, say, if wanted to go back to having one care-of 
address for some reason.)

> If either the 'C' or the 'O' flag is set in the Binding Identifier 
> mobility option, ...
There is no 'C' flag. Do you mean 'H' flag? Also, why wouldn't the O 
flag be OK even with a correspondent node? Or maybe all this is due to 
the use of the BID option as a capability negotiation when you should 
have used a simpler, separate option.

> If only the 'O' flag is set in the Binding Identifier mobility option, 
> the home agent removes all the existing bindings and registers the 
> received bindings.
Hmm. What if the O flag is set on some but not all in a bulk registration?

> For Mobile Prefix Discovery messages, [RFC-3775] requires the home 
> agent to verify that the mobile node is using the care-of address that 
> is in the binding cache entry that corresponds to the mobile node's 
> home address.  If a different address is used as the source address, 
> the message is silently dropped by the home agent.  This document 
> requires the home agent implementation to process the message as long 
> as the source address is one of the care-of addresses in the binding 
> cache entry for the mobile node.
Why does this have to be repeated under Section 9.2 when Section 6.5 
states the same requirement?

> Section 9

This section talks about, among other things, ensuring that the IPsec 
stack verifies outer tunnel source addresses. I would ask whether this 
requirement was sensible in RFC 3775 to begin with for IPsec protected 
traffic. If it is not, we could simply relax it here. The check is still 
very important for unprotected tunnels, though.

> Thus, in view of such risks, it is advisable for a home agent to 
> employ some form of care-of address verification mechanism before 
> using the care-of addresses as a valid routing path to a mobile node. 
> Solutions related to this are described in [ID-COAVERIFY].
Its is unacceptable to advise the use of something and then point to a 
draft that is nowhere near being completed.

Here's what I would recommend: 1) require that bulk mode only be used 
when sufficient trust exists, 2) use the error code that suggested that 
lets the home agent decline bulk mode, 3) move on. Note that the error 
code approach lets people use draft-lim solution 3.1.

Missing things:

- Was there a specification on how to deal with simultaneous 
home/care-of location in the context of IPv4?

- Error code to disallow simultaneous home/care-of location registration 
might be useful.

- Wouldn't it be nice if multiple care-of addresses fit nicely with the 
pmip/cmip co-existence discussion we've been having in Netlmm? That is, 
it would be possible to use multiplecoa to manage a set of binding 
entries from both the client and a mag, even if the host is connected to 
both a visited network a pmip domain at the same time. Or when things 
happen in unexpected order. However, I'm uncertain if the current 
multiplecoa spec makes this possible. A pmip unaware mobile node would 
see a move from a visited to home network, for instance, and after 
getting to the home network it would send a de-reg. This would overwrite 
the pmip registration. However, some other way to override previous 
bindings in multiplecoa might have solved that. Someone should think 
about this a little bit before multiplecoa becomes an RFC.

Editorial:

> Care-of Address
>
> If a Binding Identifier mobility option is included in a Binding 
> Update, either IPv4 or IPv6 care-of address for the corresponding BID 
> can be stored in this field.  If no address is specified in this 
> field, the length of this field MUST be zero (i.e. not appeared in the 
> option).

Can you clarify if it is allowed to leave this field to zero length when 
the option appears in a BU? What would the care-of address be in that 
case, the source address?

> The mobile node returns home in physically and shuts down ...

"in physically"?

>    [Problems of Simultaneous Home and Foreign Attachments]

What's this? Use a new subsection header instead.

> None of the care-of address MUST be sent
addresses

> If the mobile node receives the Binding Acknowledgement with the 
> status code set to 135 [Sequence number out of window], it MUST retry 
> sending a Binding Update with the last accepted sequence number 
> indicated in the Binding Acknowledgement.
Perhaps a reference to RFC 3775 would be more appropriate here than 
repeating its requirements.

> The Binding Update and binding acknowledgement messages with multiple 
> care-of addresses MUST be protected using IPsec as show in Section 9.
shown

More importantly, are you changing the security requirements or 
attempting to become the normative place where the security of Mobile 
IPv6 specified? Please refer to RFC 3775 and use only explanatory text, 
not normative language.

Jari

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 24 Sep 2008 18:49:33 +0900

Hi Jari,

Thanks for reviewing it.
Please find my comments inline.

> would have expected)? Or are you saying that the tuple <bid, hoa, coa>

BID must be unique in period. I will fix this.
> needs to know what the behaviour is when no policy has been set.

OK

> an essential part of any multi-interface solution.

Any of them are reasonable approaches.
Since HA cannot verify reachability of all the CoA in the bulk  
registration,
No.3 might be most appropriate as a default.

> sync with their BIDs, so lets make the system fail safely even in  

ok, fine with SHOULD.

> algorithm to determine when a bulk update can be sent.

no technical reasons for this option.
The use of the shared sequence number is basically added for the bulk  
registration.
If there is an implementation not supporting bulk registration, it  
might be easier to use the individual sequence number.

> Overwrites the status for all, even in a bulk registration? Or just  

This was unclear.
just for this BID.

> the O flag used in a BA, COT, or COTI?

This saves the reserved field in BU for the future extension.
I don't follow how many bits we still have in the BU reserved field.

> sending the individual registrations separately? Unless you already  

OK, I'll fix this.

> think this should only be used when explicitly configured to do so.

This is configuration base. MCoA can work with either single address  
or single interface.

> option that does not carry all the complex formats and semantics of  

OK. The easiest way is to use the reserved field of CoTI message.
We can remove all the complex formats and semantics.

> semantics of the O flag are different in these two cases?

O flag is not useful in the regular MCoA.
Do you assume MN replaces "multiple binding caches" by the single  
binding sent with regular MCoA BU?

> if it is, perhaps you should have another section that talks about

OK.

> What about traffic between mobile nodes or other hosts in the link?

If HA sends RA without the on-link flag, MN will send all the traffic  
to the default router (i.e. HA).

This was actually discussed in the separate doc.
http://tools.ietf.org/html/draft-wakikawa-mip6-no-ndp-02
Not sure we should mention this in MCoA.

> cellular arrangements look like, so it seems to fit.

right. The cellular is the right scenario.

> text to fit this situation as well.

Well, we can not use the bulk registration for returning home.
The lifetime field of the BU is shared among all the care-of addresses
in the bulk registration mode.

If MN returns home with multiple interfaces, it can use the bulk-BU  
for removing the CoAs.
However, this scenario is corner-case.

> but the packet should still be flowing to the home network, in case  

You may misunderstand here.  The texts might not be clear.
A home agent keep intercepting packets for the mobile node while at  
least one binding cache for the home address is available.
It stops intercepting and forwarding only when _ALL_ binding caches  
are expired.

> address. The mobile node must then do something if this is not  

Right. The Binding Identifier option is just ignored as RFC3775.  
Single CoA is registered to the receiver of BU.
If this is not acceptable, it should de-register that binding cache  
and will try registration with another home agent (possibly supporting  
MCoA).

> address for some reason.)

I'll fix this.

> have used a simpler, separate option.

C flag was older flag... Yes, I meant H flag.

O flag is added to replace existing bindings with new "set of bindings".
For this purpose, MN desirably uses bulk registration.
The bulk registration is not supported for the binding registration to  
CNs.

If MN can sends BU separately, O flag is useless.
A individual BU (for single CoA) replaces the older CoA anyway.

> Hmm. What if the O flag is set on some but not all in a bulk  

hmm, HA should rejects BU and return  MCOA MALFORMED error code.

> states the same requirement?

We will merge the texts.

> very important for unprotected tunnels, though.

Since the traffic is still protected by SA for HoA, this is not big  
issue.
The tunnel is managed by BU/BA (secured signaling).

The check is important for the no-IPseced tunnels.

> draft that is nowhere near being completed.

OK.

> code approach lets people use draft-lim solution 3.1.

I think 2) use the error code might be the best approach here.
The error code is useful for several cases.

> home/care-of location in the context of IPv4?

Do you mean returning home in DSMIP support?

> - Error code to disallow simultaneous home/care-of location  

agree.

> about this a little bit before multiplecoa becomes an RFC.

OK, I will look at this problem.

I will update the document according to the comments and fix the  
editorial errors ASAP.

regards,
ryuji