RE: Some thoughts about "path failover"

Judy,
I too like the idea of using spi to specify address changes only for certain
child SAs thus allowing different Child SAs to 
use different addresses. However I don't think a lot of addresses would be
involved for the multi-homing case so I would prefer the complete address
list sent rather than incremental changes with "DEL" & "ADD" options.
 
With NAT, the main problem is when roaming from non-NAT or ipsec-aware-NAT
to not-ipsec-aware NAT cases, in which UDP wrapper is required but not
negotiated during tunnel establishment.
I wonder if we can simplisticly solve this problem by requiring UDP wrapper
be used in all roaming cases.
Another way is to use the info-exch to signal whether to "add" or "take out"
UDP wrapper.
 
I like your idea of start using the new address without waiting for the RR
but  stop if RR is not successful within certain time limit. However I am
not sure if piggyback would result in odd number of messages when IKEv2
requires message in pairs.
 
Regards!
/Jing 

-----Original Message-----
From: Judy Fu [mailto:[email protected]]
Sent: Friday, April 16, 2004 2:00 PM
To: Tero Kivinen
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [Mobike] 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