Re: Some thoughts about "path failover"

Hello,

This is Judy Fu from Motorola Labs. I have been reading 
information/documents on the Mobike web sites and I am greatly interested.
I have some thoughts and ideas for a discussion.

Jari Arkko writes:

>Overall conclusion: I think your list looks very good
>and complete. Based on my 2 GW example, I am starting
>to think we need the address lists and not just a single
>address. 
>  
>

First, I agree with Jari and Tero that we need address lists. I also 
think it is a useful feature to allow users to change some of the IPsec
SAs. I have an idea on mobike message formats that are actually 
combining Pasi, Tero and Francis's drafts. The basic idea is as follows.

In default case, a mobile device just send USE_DYNAMIC_ADDRESS_UPDATES 
Notify payload as specified in Pasi's SMOBIKE
draft. This case uses minimal signaling. At default, all SPIs are changed.

When a user needs to change only some of the SAs or wants to send an 
address list for multihoming case,  a special message format
similar to Tero's draft is used. In addition to address notify payload 
specified in Tero's draft,  we can have SPI notify payload such as the
one specified in Francis's address management draft. To make the address 
change flexible, we can have add, delete, change from <addr>
to <addr> options. While we want to reuse existing payload format,  
there should be no problem to design a new format if necessary.

Another potential notify payload I am thinking of is traffic selector. 
In a mobile network scenario with a IPSec tunnel between two mobile
routers, could the mobile routers' mobility cause traffic selector 
change and is there a need to notify the traffic selector change upon mobile
routers' move?

Second,  I think NAT traversal issue may be resolved by the following 
way. NAT traversal issue arises because the peer that is not behind NAT
couldn't send messages through NAT using the new address. The idea is 
for  the IPsec peer that is not behind NAT
to simply use old address to send the address change Notify payloads as 
specified above to change address. For NAT traversal, IPsec can dynamically
keep and update new addresses and use new address to send IKEv2 and ESP 
packets. Then IPsec should also be able to store old address
and use old address to send notify payloads for NAT traversal. After the 
peer behind NAT receives the address update and starts to send
packets to the new address, other packets from the peer that is not 
behind NAT  will go through.

Third, I have an idea of piggybacked return routability check. I think 
return routability check is useful to prevent a DoS attack in which
an attacker subscribes to heavey stream media service and claims to 
change address to an address that he does not own. Then stream
media will be sent to the victim device to bring it down. Although an 
attacker on the transmission path can launch redirect attack anyway,
the attack using address change is more effortless in that the attacker 
device does not need to keep redirecting traffic. To prevent this
attack, a piggybacked return routability check is good enough. With this 
scheme, the peer will start to send traffic once receiving address
update without waiting, and piggyback or send return routability message 
at the same time,  The peer can set a timer and stop traffic
upon timeout if return routability check has failed. The advantage of 
this scheme is to prevent DoS attack described above without latency
or handoff delay caused by return routability check.

Your comments are appreciated.

Best Regards
Judy







>  
>