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

Re: Initial Contact Message processing



Thor Lancelot Simon writes:
> On Tue, Jan 13, 2004 at 03:13:59PM -0800, vamsi wrote:
> > 
> > Hi,
> >    We found one problem during inter operability testing and I thought
> >    I will inform to the list for feedback.
> > 
> >    It seems that some implementations, while processing IC message,
> >    delete all IPSEC and IKE SAs that correspond to source IP address of
> >    the IC message.
> > 
> >    This works well, in most of the scenarios, but fails to work when there
> >    are more than one Security Gateway or Clients behind a NAT gateway.
> >    For instance, take this example:

If you are using IPsec through NAT you should be using NAT Traversal
as defined in the draft-ietf-ipsec-nat-t-ike-07.txt document. It
states that:
----------------------------------------------------------------------
6.  Initial contact notifications

The source IP and port address of the INITIAL-CONTACT notification for
the host behind NAT are not meaningful, so the IP and port numbers
MUST NOT be used for the determine which IKE/IPsec SAs to remove. The
ID payload sent from the other SHOULD be used instead. I.e when
INITIAL-CONTACT notification is received from the other end, the
receiving end SHOULD remove all the SAs associated with the same ID
payload.
----------------------------------------------------------------------

> 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). 
-- 
kivinen@safenet-inc.com