Re: Some thoughts about "path failover"

Jing,

Thanks for your quick response. My comments in-line.

Jing Xiang wrote:

> 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.

Sounds fine.

>  
> 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.

UDP wraper helps when a mobile node behind NAT sends packets to others 
that are not behind NAT, while UDP wraper does not solve the problem 
that a mobile device outside NAT sends packets with new address to a 
device that is behind NAT. In the latter case, as described in smobike draft
in section 3, bulletin 4, the NAT of either restricted cone, port 
restricted cone or symmetric NAT blocks the address update or packets 
sent from the new address
by the party outside the NAT.  In my previous email, for this case, the 
proposed solution is for the IPsec peer outside NAT sends an address 
update containing the
new address using old address as source address. All other packets can 
resume right after an acknowledgment is received from node behind NAT to 
the new address.

>  
> 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.

I think message pairs should still be allowed. Or we simply do regular 
RR and send other packets in parallel.

Regards
Judy

>  
> 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
>
>
>
>
>
>
>
>>  
>>