Subject: Re: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt asMonami6 WG Document

From: Heejin Jang <[email-masked]>
Date: Wed, 02 Nov 2005 21:06:07 +0900

Hello, Ryuji, all,
 
 To use BID for multiple binding sounds reasonable. 

But, I don't think seperate BUs MUST be used, in all cases.
draft-wakikawa-mobileip-multiplecoa-o4.txt mentions that there 
are two cases when MN has several CoAs:
 
1) An MN uses several physical network interfaces
2) An MN gets multiple prefixes via one physical network interface.
 
 In case 1), it's good to use seperate BUs for the multiple CoA registrations
since each link over multiple interfaces would become inactive and active independently.
In case 2), if the interface goes active, then multiple CoAs can be available at the 
same time, then it's better to use single BU.
Is it necessary to send separate BUs/HoTs/HoTIs/CoTs/CoTIs for all CoAs?
 
My draft is about the use of single BU in such cases. 
 (http://home.postech.ac.kr/~arche/draft-jang-mip6-smreg-00)
 
 Regards, 
 Heejin.

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 14:30:19 +0100

In your previous mail you wrote:

   but it needs some work. here is one of the issues.
   
   when a mobile node reverse tunnels a packet to the
   HA, the HA performs a number of checks, which include
   checks on the outer source address (CoA). sometimes
   the tunnel decapsulation is done by IPsec code on
   the HA. the tunnel mode IPsec SA is typically keyed
   on the home address, but the CoA is stored in the
   SPD/SAD entries. we could store multiple CoAs in the
   binding cache, but it is not a standard IKEv2/IPsec
   practice to store multiple outer tunnel source
   addresses. we need to figure out a way to make this
   work.
   
=> IMHO there is not enough considerations in the draft about the
IPsec protection:
 - how HoTi/HoT are protected? what about payload packets? K flag?...

According to the discussion I can guess:
 - HoTi/HoT are sent on the tunnel using the principal CoA. It can
   work on the MN but on the HA there is today no specified way to
   recognize the principal CoA.
 - there is only one SPD entry (pair) to protect the HoTi/HoT.
 - for payload packets a mapping between BIDs and tunnels
 - the support of the K flag requires to be able to recognized
   BUs changing the principal CoA.

So IMHO there are no critical issues but enough missing points to make
the document impossible to implement/deploy in the real world.

Regards

[email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 04 Nov 2005 00:16:36 +0900

Hi Francis

Thanks for comments.

At Wed, 02 Nov 2005 14:30:19 +0100,
>  - how HoTi/HoT are protected? what about payload packets? K flag?...

right. This was pointed out by Vijay, too.

>    recognize the principal CoA.

right.

>  - there is only one SPD entry (pair) to protect the HoTi/HoT.

yes.

> the document impossible to implement/deploy in the real world.

I'll certainly update the document if the draft becomes WG document.
I appreciate your inputs to the draft.

thanks
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 04 Nov 2005 00:40:00 +0900

Vijay

At Mon, 31 Oct 2005 17:46:20 -0800,
vijay wrote:
> Ryuji Wakikawa wrote:
> > Good point. However, which scenario do you need ipsec tunnel?
> 
> reverse tunneling payload traffic with IPsec protection.

ok

> > For RR, HoTI can be sent through the primary CoA.
> > 
> > 
> >>other minor issues.
> >>
> >>1. the use of a flag in the binding update to
> >>indicate multiple CoA registrations. perhaps we could
> >>use a mobility option. flags are scarce.
> > 
> > 
> > This can be easily fixed.
> 
> ok.
> 
> >>2. do we need to really extend DHAAD? we can have
> >>some kind of a reject status in the BAck if the HA
> >>does not support this option. or have the HA echo
> >>something back if it supports multiple CoA
> >>registration and has processed the BU successfully.
> > 
> > We introduce this extension becase MN need to discover the right HA
> > when it gets BA with negative status.
> 
> it just tries the next HA. (?) are you planning to have
> something like DHAAD modifications in RFC 3963?

That was original motivation. 

> >>3. I dont understand the need for a BID. the draft
> >>says
> >>
> >>
> >>>         The BID is an identification number used to distinguish
> >>>         multiple bindings registered by the mobile node.  Assignment of
> >>>         distinct BID allows a mobile node to register multiple binding
> >>>         cache entries for a given home address. 
> >>
> >>doesnt the HoA/CoA pair uniquely identify a binding?
> >>do you want a unique identifier for a particular
> >>binding even when the CoA changes? in that case why
> >>not associate the interface with a particular binding?
> >>maybe I am missing something.
> > 
> > 
> > How do you express interface in MIP6 stack? Do you suggest the use of
> > name like "en0"?:-)  
> > BID can be an interface index which most of implementation uses for
> > interface management.  That's why we use 16bits length for
> > BID. (interface index is mostly 16bits)
> > 
> > In our system, we bind BID with network interface. We define
> > well-known BID which express intereface like wifi, ethernet, Ev-Do,
> > etc. (This is not in the draft though).
> 
> I guess this needs to be evaluated against just sending
> a BU with all the current valid CoAs. I wonder if we are
> making it more complex than is really necessary.

Always using a BU looks simple, but, after all this may lead overhead
in some scenario. depending on how many CoAs, how often CoAs are
changed, etc.

I have presentation slot in Monami WG. I will summarize all the issues
for the presentation.

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 04 Nov 2005 00:47:18 +0900

Hi Heejin

At Wed, 02 Nov 2005 21:06:07 +0900,
> same time, then it's better to use single BU.

I think the most of multihoming case is 1). 

BTW, I want to know if there're any motivation for wireless operators
to manage multiple prefixes to a link.

> Is it necessary to send separate BUs/HoTs/HoTIs/CoTs/CoTIs for all CoAs?

Not for HoT/HoTI. MN can use the same Home Nonce.

>  (http://home.postech.ac.kr/~arche/draft-jang-mip6-smreg-00)

Ah, I knew this draft. I will re-check this again.

ryuji

---

From: Heejin Jang <[email-masked]>
Date: Fri, 04 Nov 2005 10:45:01 +0900

Hello. Ryuji & folks.

Even in case 1), an MN can decide to send one BU
for CoA which is involved in active session during handover, 
and sends another  BU for the remaining CoAs after aggregation.

Regards, 
Heejin.