Subject: Initial Contact Message processing

From: vamsi <[email-masked]>
Date: Tue, 13 Jan 2004 15:13:59 -0800

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:

    Security Client 1
                            ----------NAT 
Gateway-------Internet--------SG-----LAN
    Security Client 2

    At one time, both clients have tunnels established with SG (acting as 
remote
    access server and only Clients initiate phase1 exchange)
    and  SG will see both the tunnels from NAT Gateway IP address.

    If Client 1 gets restarted, it sends IC message to the SG.
    SG, upon receipt, deletes tunnels established by Client 1 and also
    it deletes the tunnels, that are created by Client 2.

    DOI (RFC2407) states that, upon receipt of IC message, the implementations
    might delete tunnels associated with the sending system.

     It is observed that, identification of 'sending system' is being done 
based on source IP
     address of the IC message in some implementations. I feel that, it 
should be based
     on 'Phase1 ID' (FQDN, USER FQDN, USER DN etc..) and/or with source IP 
address.

     Some clarification on IC message processing in DOI  document, might be 
helpful.

Thanks
Vamsi

---

From: Thor Lancelot Simon <[email-masked]>
Date: Tue, 13 Jan 2004 22:49:07 -0500

>    For instance, take this example:

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.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Jan 2004 13:10:15 +0200

> >    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.
----------------------------------------------------------------------

> 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). 
-- 
[email-masked]

---

From: vamsi <[email-masked]>
Date: Wed, 14 Jan 2004 11:06:26 -0800

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