Subject: [Ipsec] Tunnel persistance with a MobileNode

From: krishna G <[email-masked]>
Date: Wed, 1 Dec 2004 10:12:45 -0800 (PST)

Outbound packet processing:
I have a few questions on this
First, How is it implemented in the practical world
RFC 2401 says
-------------------------------------------------------------------------------------
5.1 Outbound IP Traffic Processing
5.1.1 Selecting and Using an SA or SA Bundle
Since a packet's selectors might
   match multiple policies or multiple extant SAs and since the SPD is
   ordered, but the SAD is not, IPsec MUST:
           1. Match the packet's selector fields against the outbound
              policies in the SPD to locate the first appropriate
              policy, which will point to zero or more SA bundles in the
              SAD.
           2. Match the packet's selector fields against those in the SA
              bundles found in (1) to locate the first SA bundle that
              matches.  If no SAs were found or none match, create an
              appropriate SA bundle and link the SPD entry to the SAD
              entry.  If no key management entity is found, drop the
              packet.
           3. Use the SA bundle found/created in (2) to do the required
              IPsec processing, e.g., authenticate and encrypt.
_________________________________________________________
Selector fields:
4.4.2  Selectors
The following selector parameters
   MUST be supported for SA management to facilitate control of SA
   granularity.  Note that in the case of receipt of a packet with an
   ESP header, e.g., at an encapsulating security gateway or BITW
   implementation, the transport layer protocol, source/destination
   ports, and Name (if present) may be "OPAQUE", i.e., inaccessible
   because of encryption or fragmentation.  Note also that both Source
   and Destination addresses should either be IPv4 or IPv6.
      - Destination IP Address (IPv4 or IPv6): 
 Source IP Address(es) (IPv4 or IPv6): 
 Name:
 Data sensitivity level: (IPSO/CIPSO labels)
 Transport Layer Protocol:
 Source and Destination (e.g., TCP/UDP) Ports
-------------------------------------------------------------------------------------
Now in the practical world what are the typical selectors used for establishing the SA's in a VPN Gateway scenario (VPN GW sitting in between the communicating nodes, typical corporate intranet access scenario).
Is the use of one security association per pair of nodes, i.e Source, Destination IP addresses typical?
I was just thinking if it is possible to maintain a SA with a node (Mobile Node) that changes it's IP address frequently (we won't like to establish a new SA during every change in IP address) and moreover i would like to have a unique SA with each MN
If i ought to maintain SA then the selectors should be so chosen that they are unique to each MN at the same time not depending on its IP address.
If i choose source address, source, destinatin ports, it would work as long as all the MN's have a unique port number for themselves at any point of time, but considering the fact that MN's might most often be behind NAT, this doesn't seem practical.
Is there any easy solution for this? 
Suppose we succeeded to send the packet to the MN, the inbound processing at the MN looks for SA based on the triple, Destination IP address, protocol, SPI. The packet will not be processed. Is updating the SAD whenever a new binding request is send to the Home Agent (not when binding update is sent by HA, since this itself would be in IPsec tunnel) a solution. Since this updation is needed only at the client side, it should be easy to implement if the updation is done by the MobileIP client software (ofcourse, it should be possible for this to access and update the SAD which might be implemented by a different vendor's solution). I believe such updation is not against the IETF standard.
Also i would be happy to know the usage of 'Name' field in the selectors?
How does the a tunnel end point recognise the 'name' of a sender by looking at the packet Does that use other identities such as layer2 identity to determine this. But this works at layer3, so no information would be conveyed by layer2. (Even layer2 identity usage won't work for using X.509 in the name field, then how can this field be used?)

Ofcourse, upcoming standards like IKE2 would provide a solution to the problem of mobile VPN connection. 

       Regards,
       Krishna

---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Helps protect you from nasty viruses.

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