Issues of Address List, NAT Traversal and RR Check

Hi,

Last week I sent an email to discuss my thoughts on address list, NAT 
traversal and RR check. Probably because I used subject of
"Re: Some Thoughts about "Path Failover"" that confused people, I only 
got one response from Jing Xiang.  I am interested in getting
more comments on the issues. So I re-send the message below.

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. All the payloads 
can be sent in one message.

Another potential notify payload I am thinking of is traffic selector. 
In a mobile network (like a network in a car or train) 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 as described in smobike draft in 
section 3, bulletin 4, may be resolved in the following way.
NAT traversal issue arises because the peer outside NAT that has 
recently changed address couldn't send messages through NAT (
restricted cone, port restricted cone or symmetric NAT) using the new 
address. The suggested solution is for  the IPsec peer that is
not behind NAT to simply send an address update Notify payloads sourced 
with the old address, which will go through NAT. Then
the peer behind NAT will send an acknowledgment to the new address. 
After that, packets sent from the peer outside NAT will be
able to get through NAT.
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.

Third, I think return routability check is useful but we should try to 
minimize the associated handoff latency, which brought 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.

Any comments are welcome.

Regards
Judy