Re: Initial Contact Message processing

[vamsi <vamsi@intotoinc.com>]

Hi,
     Thank you for pointing out the text and draft number. This
      text clearly indicates the solution, that is inter-operable and
      I am  comfortable with this text.

Thanks again
Vamsi
CTO office
Intoto Inc.
www.intoto.com

At 01:10 PM 1/14/2004 +0200, Tero Kivinen wrote:
>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