[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initial Contact Message processing



At 12:02 -0500 1/14/04, David Wierbowski wrote:
>> This is a pretty dubious way to use IKE. That aside for the moment,
 it seems to me to be only one of a number of reasons why implementations
 should track the _port_ they receive the initial message of a
conversation
from, not just the source IP address.

This does not work. You MUST use identities for tracking the SAs from the same identity. If the host behind NAT is rebooted, there is possibility that the NAT will allocate new IP and port for the host when it connects again. Now the SGW will see connection coming with new IP and new port, and the INITIAL-CONTACT will not clear the old state away at all, meaning that it can still try to send the traffic to old SAs (== black hole).

Are you saying that an identity may use IPSec from one device only? It seems to me that I may want to establish a phase 1 SA with you from two different work stations at the same time. Are you saying that I would need 2 phase 1 IDs to do that? Is it a generally accepted limitation of IPSec that identities are tied to a particular device? This would have to be true in order to process an INITIAL-CONTACT notification based on IDs only.

In general one would not expect the same entity to be present at multiple addresses at the same time, although I agree that there are circumstances where this might legitimately happen. However, the observation about the inadequacy of relying on addresses and ports to identify a peer in all circumstances is still true. So, if one wants to allow the same identified entity to connect to the same destination from multiple sources simultaneously, there needs to be an instance-specific form of identification that IKE can use to distinguish among the multiple instances of the same entity, for housekeeping purposes.


Steve