Subject: [Monami6] Review of draft-ietf-monami6-multiplecoa-02

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 14 Mar 2007 22:11:11 -0700

All,
I apologize for the terribly delayed review of this document, after I
had promised a review a while ago :) The document is generally well
written, although I still have a few unanswered questions. Also, the
draft is really long, given that the functionality provided is quite
simple and straightforward - I don't have specific suggestions now, but,
I think the text can be scrubbed for redundancy and cut down a bit. 

Comments and questions: 

1. A BID is stated to be assigned to an interface or CoA. Isn't it more
appropriately tied to a CoA or an MNP (in the NEMO case)? In other
words, an MN may have multiple addresses on its interface, leading to
multiple BIDs per interface. 

2. The use of the priority field is a bit unclear to me. The value of
255 is used to indicate a default binding. What happens when there there
are other bindings with different priority values less or greater than
255? What does "default" mean here? 

3. Are multiple BIDs with priority of 255 allowed? In other words, can
there be more than one default binding? That seems problematic, so,
perhaps that should be explicitly disallowed? 

4. If a binding exists with priority of 255 and an MN sends another BU
with a new BID and priority of 255, does the new binding replace the old
one as default? It seems like that would be appropriate, but, it is not
clear. 

5. Is it possible for the BA to be successful, even if some of the BID
options indicate failure? For e.g., if an MCOA BID CONFLICT is returned
for one particular BID, can the other CoA bindings be successful? 

6. The message format for the BID sub-option seems a bit odd to me. The
current format requires that the C and O flags be present (and
synchronized) for every CoA. Would it not be better to define this
option such that the Bulk registration and Overwrite flags are generally
applicable, while there may be multiple BID, Priority/Status and CoA
fields present - the number of those fields present may be indicated by
the length field or by an explicit field, say, "CoA count", in which
case, the length field may be removed? 

7. In section 5.1, two cases are listed where the MN may have multiple
CoAs. There is also the case where the MN may be using RFC3041-style
addresses from the same prefix - it may have multiple CoAs belonging to
the same prefix on the same or different physical interfaces (if
multiple interfaces are attached to the same prefix, for e.g.). So, the
relevance of physical interfaces seems not so significant - perhaps it
could be reworded to reflect this. 

8. The description about sequence numbers in section 5.4 for bulk
registration is confusing. Assuming that this is referring to the
sequence number in the BU and not the ESP sequence number, why would
there ever be a separate sequence number per CoA registered? For a given
HoA, there should be only one sequence number space, right? In that
case, there doesn't seem to be any ambiguity in setting the sequence
number correctly for bulk registration. 

9. Section 5.6 states - "Note that when the mobile node does not want to
return home even if one of the interfaces is attached to the home link,
the mobile node MUST disable the interface". Disabling the interface
seems unnecessary to me. The MN MUST NOT do NDP on that interface seems
more appropriate - that is what ultimately prevents the duplicate
address issue between the MN and the HA defending the same address,
right? 

10. I don't understand section 5.10 - is it referring to the case where
the HA is also a CN? 

11. Section 8.1 gets into describing how the 'K' bit is used. I think
this requires more clarity. Presently, the MN may simply follow a policy
of always setting the 'K' bit in the BU. With MCoA registration, the MN
only needs to set it if it needs to changes its address for the IKEv2
session. Also, it is not entirely clear that when the 'K' bit is set,
the CoA to use for IKEv2 must be set to the source address of the BU,
irrespective of any number of CoAs that may be present in it.  

12. Section 8.3.2. brings up a good point about IPsec not always knowing
which CoA to use and hence, the MIP6 stack having to communicate the CoA
to it. This seems to change the IPsec behavior that normally would use
the IKEv2 endpoint as the tunnel outer address. This is internal box
behavior and hence, it is probably not a big deal. I'm also wondering if
this has the same level of security assurances as for instance, MOBIKE,
would have - it probably does, given that the BU was protected with
IPsec.. But, I have to think more about this. Or, I'll wait for the
security considerations section to be written :) 

Thanks,
Vidya

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 16 Mar 2007 00:11:32 +0900

Hi Vidya,

FIrst of all, thanks a lot for reviewing the draft!

please fine my comments inline.

> I think the text can be scrubbed for redundancy and cut down a bit.

I have been maintaining this draft for years (the first version of  
MCoA individual submission was 2003),
I agree that there are several redundant texts and maybe unnecessary  
texts:-<

I will try to reduce the texts somehow in the next revision.

> multiple BIDs per interface.

see my reply to comment 7.

> 255? What does "default" mean here?

The draft is not clear on this point. The answer is in the draft- 
soliman-monami6-flow-binding-04.txt.
The draft-soliman states that
"6.1.  Default Bindings
    A default binding is always maintained between a MN and its peers
    (home agent, correspondent node if RO is used and mobility anchor
    point if applicable).  The default entry indicates which care-of
    address to use for a data flow that does not match any of the flow
    bindings.  The preferred care-of address is determined through the
    BID option described in [4]."

This draft needs a default binding and they want to carry "defautl"  
information by BID sub-option.

> perhaps that should be explicitly disallowed?

The default binding must be one.

> one as default? It seems like that would be appropriate, but, it is  

right.
The context of  "default" is nothing to do with multiplecoa spec.
I didn't pay much attention to this.

> for one particular BID, can the other CoA bindings be successful?

Good point.
If one of BID registration fails, the error status is kept in the  
Status field of each BID sub-option.
The question is what kind of status value should be used for the  
Status field of BA.

> case, the length field may be removed?

OK, beside the length field is required for all suboptions of MH  
(i.e. TVL format).

THe problem is that the CoA field is only valid for bulk registration.
When a MN sends a separate BU for each CoA, it can save 128 bit in  
BID sub-option.
If COA is always stored in the CoA field in BID sub-option regardless  
of bulk or not,
the format gets much simpler. However, 128-bit in mobile is somewhat  
important.

> could be reworded to reflect this.

Right. This comment is similar to your comment.1.
I agree that # of interface is not important here. I will update this  
text.

In fact, draft-ietf-monami6-mipv6-analysis only deals with # of HoA  
and # of CoA.

> number correctly for bulk registration.

This section discusses the BU Sequence number.
If a sequence number is defined in each BID sub-option, there is not  
such problem, right.
On the other hand, this sequence number field is useful only for bulk  
registration.
I want to save  bits as much as possible. If this isn't much concern,  
I can update this accordingly.

Alternatievley, a new sub-option for bulk registration can be  
defined, though too much sub-options are not desired.

> address issue between the MN and the HA defending the same address,

right. will fix this.

> 10. I don't understand section 5.10 - is it referring to the case  

Yes.
When a  MN communicates with its HA as a destination, there is two  
methods.
One is using tunnel and another is using HoA option (RO). Either  
works fine.

> irrespective of any number of CoAs that may be present in it.

The second bullet tried to explain this.
The MN only set K-bit when it wants to change its address for IKEv2.
We will update the text.

> security considerations section to be written :)

We will definitely add the section of security considertation in the  
next revision,
but your comments and feedbacks are very welcome! :-)

Thanks a lot for detailed review, again.

ryuji

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 16 Mar 2007 23:51:47 +0900

Hi Ryuji,

> On the other hand, this sequence number field is useful only for bulk 

BTW, is the sequence number defined per HoA, or per CoA? Is this 
clarified in the MCoA draft? Is there any specific motivation to have a 
different seq. number per CoA? OTOH, if the sequence number is defined 
per HoA, then the BU seq. number issue in bulk reg. does not appear.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sat, 17 Mar 2007 11:24:08 +0900

Hi Romain,

On 2007/03/16, at 23:51, Romain KUNTZ wrote:

>> If a sequence number is defined in each BID sub-option, there is  
>> not such problem, right.
>> On the other hand, this sequence number field is useful only for  
>> bulk registration.
>
> clarified in the MCoA draft? Is there any specific motivation to  
> have a different seq. number per CoA? OTOH, if the sequence number  
> is defined per HoA, then the BU seq. number issue in bulk reg. does  
> not appear.

The seq number is basically used to guarantee the order of BU at the  
receiver side.
The Seq Number should be assigned per binding, binding update list.

regards,
ryuji

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 19 Mar 2007 06:44:08 -0700

Hi Ryuji, 

> -----Original Message-----
> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 7:24 PM
> To: Monami6 WG
> Subject: Re: [Monami6] Review of draft-ietf-monami6-multiplecoa-02
> 
> Hi Romain,
> 
> >>> there ever be a separate sequence number per CoA 
> registered? For a 
> >>> given HoA, there should be only one sequence number 
> space, right? In 
> >>> that case, there doesn't seem to be any ambiguity in setting the 
> >>> sequence number correctly for bulk registration.
> > clarified in the MCoA draft? Is there any specific 
> motivation to have 
> > a different seq. number per CoA? OTOH, if the sequence number is 
> > defined per HoA, then the BU seq. number issue in bulk reg. 
> does not 
> > appear.
> 
> The seq number is basically used to guarantee the order of BU 
> at the receiver side.

I believe we only need a sequence number per HoA. The sequence number is
to sequence all the BUs and sometimes used for replay protection - the
HoA is a common element in all the BUs - so, I don't see why we need it
per CoA. "Per binding" is a bit misleading, since it is largely an
implementation issue whether multiple CoAs are stored as part of the
same binding pertaining to a HoA or treated as separate bindings. But,
in either case, having a sequence number space per HoA seems sufficient
to me. 

Regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 19 Mar 2007 06:59:35 -0700

Hi Ryuji,
Some notes inline.  

> Sent: Thursday, March 15, 2007 8:12 AM
> To: Monami6 WG
> > simple and straightforward - I don't have specific suggestions now, 
> > but, I think the text can be scrubbed for redundancy and cut down a 
> > bit.
> 
> I have been maintaining this draft for years (the first 
> version of MCoA individual submission was 2003), I agree that 
> there are several redundant texts and maybe unnecessary texts:-<
> 
> > 1. A BID is stated to be assigned to an interface or CoA. Isn't it 
> > more appropriately tied to a CoA or an MNP (in the NEMO case)? In 
> > other words, an MN may have multiple addresses on its interface, 
> > leading to multiple BIDs per interface.
> 
> > 255 is used to indicate a default binding. What happens when there 
> > there are other bindings with different priority values less or 
> > greater than 255? What does "default" mean here?
> 
> The draft is not clear on this point. The answer is in the 
> draft- soliman-monami6-flow-binding-04.txt.

Hmmm.. Okay. Thanks for this clarification. I think this document needs
to then specify the behavior of the default binding more clearly. It is
worth thinking about whether we want to state that the default value
should not be used unless it truly is a default (primary) one, in which
case, the priorities of other CoAs may be ignored. Otherwise, this
document seems to leave an ambiguity about this that doesn't get
resolved until one implements flow-based bindings. 

That said, I do think having a default binding for the base MCoA
document is well worth it. One use case is this - the default binding is
the one the HA sends data to; but, the HA accepts packets from any of
the other CoAs. This is useful for some wireless networks where the MN
may use any uplink based on what is better; but, it prefers a rather
stable endpoint for receiving the packets. 

> The default binding must be one.

So, I think the draft needs to state that upon receiving a BID with
priority of 255, any other existing BID with priority of 255 must be
reset to some other value (zero?). 

> > with a new BID and priority of 255, does the new binding 
> replace the 
> > old one as default? It seems like that would be 
> appropriate, but, it 
> > is not clear.
> 
> right.
> > options indicate failure? For e.g., if an MCOA BID CONFLICT is 
> > returned for one particular BID, can the other CoA bindings be 
> > successful?
> 
> Good point.
> If one of BID registration fails, the error status is kept in 
> the Status field of each BID sub-option.
> The question is what kind of status value should be used for 
> the Status field of BA.
> 

Yes, I think this draft should describe that. 

> >
> > 6. The message format for the BID sub-option seems a bit 
> odd to me.  
> > The
> > option such that the Bulk registration and Overwrite flags are 
> > generally applicable, while there may be multiple BID, 
> Priority/Status 
> > and CoA fields present - the number of those fields present may be 
> > indicated by the length field or by an explicit field, say, "CoA 
> > count", in which case, the length field may be removed?
> 
> OK, beside the length field is required for all suboptions of 
> MH (i.e. TVL format).
> 

Okay. 

> When a MN sends a separate BU for each CoA, it can save 128 
> bit in BID sub-option.
> If COA is always stored in the CoA field in BID sub-option 
> regardless of bulk or not, the format gets much simpler. 
> However, 128-bit in mobile is somewhat important.
> 

Sure. But, depending on the length field and the bulk flag, it should be
clear what is in the rest of the message, right? So, the CoA wouldn't be
included when the bulk flag is set. 

> > addresses from the same prefix - it may have multiple CoAs 
> belonging 
> > to the same prefix on the same or different physical interfaces (if 
> > multiple interfaces are attached to the same prefix, for e.g.). So, 
> > the relevance of physical interfaces seems not so significant - 
> > perhaps it could be reworded to reflect this.
> 
> I agree that # of interface is not important here. I will 
> update this text.
> 
> In fact, draft-ietf-monami6-mipv6-analysis only deals with # 
> of HoA and # of CoA.
> 
> > there ever be a separate sequence number per CoA registered? For a 
> > given HoA, there should be only one sequence number space, 
> right? In 
> If a sequence number is defined in each BID sub-option, there 
> is not such problem, right.
> On the other hand, this sequence number field is useful only 
> for bulk registration.
> I want to save  bits as much as possible. If this isn't much 
> concern, I can update this accordingly.
> 
> > 9. Section 5.6 states - "Note that when the mobile node 
> does not want 
> > to return home even if one of the interfaces is attached to 
> the home 
> > link, the mobile node MUST disable the interface". Disabling the 
> > interface seems unnecessary to me. The MN MUST NOT do NDP on that 
> > interface seems more appropriate - that is what ultimately prevents 
> > the duplicate address issue between the MN and the HA defending the 
> > same address, right?
> 
> right. will fix this.
> 
> > 10. I don't understand section 5.10 - is it referring to the case 
> > where the HA is also a CN?
> 
> Yes.
> When a  MN communicates with its HA as a destination, there 
> is two methods.
> One is using tunnel and another is using HoA option (RO). 
> Either works fine.
> 
> >
> > this requires more clarity. Presently, the MN may simply follow a 
> > policy of always setting the 'K' bit in the BU. With MCoA 
> > registration, the MN only needs to set it if it needs to 
> changes its 
> > address for the IKEv2 session. Also, it is not entirely clear that 
> > when the 'K' bit is set, the CoA to use for IKEv2 must be 
> set to the 
> > source address of the BU, irrespective of any number of 
> CoAs that may 
> > be present in it.
> 
> > 12. Section 8.3.2. brings up a good point about IPsec not always 
> > knowing which CoA to use and hence, the MIP6 stack having to 
> > communicate the CoA to it. This seems to change the IPsec behavior 
> > that normally would use the IKEv2 endpoint as the tunnel outer 
> > address. This is internal box behavior and hence, it is 
> probably not a 
> > big deal. I'm also wondering if this has the same level of security 
> > assurances as for instance, MOBIKE, would have - it probably does, 
> > given that the BU was protected with IPsec.. But, I have to 
> think more 
> > about this. Or, I'll wait for the security considerations 
> section to 
> > be written :)
> 
> We will definitely add the section of security considertation 
> in the next revision, but your comments and feedbacks are 
> very welcome! :-)
>

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 19 Mar 2007 15:15:47 +0100

Hi Vidya,

On 2007/03/19, at 14:44, Narayanan, Vidya wrote:

<SNIP>

> in either case, having a sequence number space per HoA seems  

Thanks for clarification. This is slightly implementation issue, but  
I agree with you.
I will update this in the next version.

thanks
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 19 Mar 2007 15:25:03 +0100

Hi Vijdya

> resolved until one implements flow-based bindings.

ok. We don't have much specific usage of this default binding.
We may ask Hesham to specify this primary binding in their spec.

> stable endpoint for receiving the packets.

interesting.
This may avoid running any flow exchange to utilize MCoA.

right.

> Yes, I think this draft should describe that.

ok, thanks.

> included when the bulk flag is set.

Do you mean C flag (Care-of address?). We don't have bulk flag.
But I understand your context here. I will look at the option format  
again.

thanks,
ryuji

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 19 Mar 2007 15:46:28 +0100

Hi,

On Mar 19, 2007, at 3:25 PM, RYUJI WAKIKAWA wrote:

[...]

> We may ask Hesham to specify this primary binding in their spec.

I think both drafts (mcoa and flow binding) need a "default binding",  
just for the reason you mentioned below : when there are several CoAs  
registered at the HA, the MN should be able to control which one will  
be used as destination address in the packets from the HA.

In the flow-binding draft, a default binding is needed in the case  
that none of the flow binding rules match the incoming packet at the HA.

Now, we can define that the registered CoA that has the higher  
priority value is defined as the default CoA, can't we?

> This may avoid running any flow exchange to utilize MCoA.

Correct. But the limitation of that is that the MN cannot provide  
information to the HA to help its decision about which CoA to use.

Nicolas

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 19 Mar 2007 16:01:58 +0100

Hi Nicolas,

On 2007/03/19, at 15:46, Nicolas Montavont wrote:

> I think both drafts (mcoa and flow binding) need a "default  
> binding", just for the reason you mentioned below : when there are  
> several CoAs registered at the HA, the MN should be able to control  
> which one will be used as destination address in the packets from  
> the HA.

right, but even without default binding, HA can always use a first  
matched binding for tunnel if no policy is found.
It is uncontrollable for MN to register a desired primary binding on  
top of binding cache,  default may be valuable .

> priority value is defined as the default CoA, can't we?

255 indicates default.
Much easier to pick a default binding.
Otherwise, a HA must compare the priority value for all the bindings...

> information to the HA to help its decision about which CoA to use.

This is out of scope of MCoA, right?

ryuji

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 19 Mar 2007 16:10:07 +0100

Hi Ryuji,

On Mar 19, 2007, at 4:01 PM, RYUJI WAKIKAWA wrote:

>> several CoAs registered at the HA, the MN should be able to  
>> control which one will be used as destination address in the  
>> packets from the HA.
>
> It is uncontrollable for MN to register a desired primary binding  
> on top of binding cache,  default may be valuable .
>

I see, but in this case, what happens if you loose the CoA (get un- 
synchronized with your HA, or the CoA with the 255 value expires)  
which indicates 255 ?

I would be more in favor of the higher value defines the default  
rather than the value 255. You can still optimize your code by  
stopping the search when you find the higher value possible.

> This is out of scope of MCoA, right?

Sure

Nicolas

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 19 Mar 2007 16:25:12 +0100

Hi Nicolas,

On 2007/03/19, at 16:10, Nicolas Montavont wrote:

>>> binding", just for the reason you mentioned below : when there  
>>> are several CoAs registered at the HA, the MN should be able to  
>>> In the flow-binding draft, a default binding is needed in the  
>>> case that none of the flow binding rules match the incoming  
>>> packet at the HA.

correct.

My question is
- do you always need default?
- I don't specify much about treatment of this priority field in  
MCoA, because flow binding has some intention to use this.
   If you have any proposal, please propose your text:-)

> stopping the search when you find the higher value possible.

higher value? can you elaborate more?

ryuji

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 19 Mar 2007 16:29:58 +0100

Ryuji,

On Mar 19, 2007, at 4:25 PM, RYUJI WAKIKAWA wrote:

>>> right, but even without default binding, HA can always use a  
>>> first matched binding for tunnel if no policy is found.

I think yes.

>   If you have any proposal, please propose your text:-)

Ok, I'll try to propose some text.

> higher value? can you elaborate more?

I didn't check the format of your field yet (so I don't know the max  
possible value), but I suggest here that a CoA with a value 200 will  
be preferred compared to a CoA with a value 150.

Nicolas

---

From: Conny Larsson <[email-masked]>
Date: Mon, 19 Mar 2007 16:43:42 +0100

Nicolas, Ryuji

See comment inline regarding the priority flag.

Regards
Conny

Nicolas Montavont wrote:
> [snip]
>>>
>>> I see, but in this case, what happens if you loose the CoA (get 
>>> un-synchronized with your HA, or the CoA with the 255 value expires) 
>>> which indicates 255 ?
>>
>> correct.
>>
>> My question is
I find this a bit strange. If you introduce a flag (in this case the 
priority flag) in a protocol shouldn't that flag be used for the 
protocol? I.e. I think the specific use of the flag should be clearly 
specified in the protocol. If this can't be done, just leave it outside 
the protocol and let another protocol introduce it.

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 19 Mar 2007 16:54:27 +0100

Conny,

On Mar 19, 2007, at 4:43 PM, Conny Larsson wrote:

>>>> un-synchronized with your HA, or the CoA with the 255 value  
>>>> expires) which indicates 255 ?
>>>
>>> correct.
>>>
>>> My question is
> I find this a bit strange. If you introduce a flag (in this case  
> the priority flag) in a protocol shouldn't that flag be used for  
> the protocol? I.e. I think the specific use of the flag should be  
> clearly specified in the protocol. If this can't be done, just  
> leave it outside the protocol and let another protocol introduce it.

Good point, and this is why we need some text in MCoA draft

Nicolas