Subject: Re: Initial Contact Message processing

From: David Wierbowski <[email-masked]>
Date: Wed, 14 Jan 2004 12:02:21 -0500

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jan 2004 16:12:26 -0500

>to be true in order to process an INITIAL-CONTACT notification based on IDs

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Jan 2004 05:21:16 +0200

> Are you saying that an identity may use IPSec from one device only?

USer can use IPsec from multiple devices, but if you want to have
working solution going through NATs each identity should only be tied
to one device. This normally is the case, your private key is only
stored in exactly one machine, and it is tied to one certificate
having one identity. If you have another device you use to connect to
the same VPN you should have separate private key and identity for
that (for example FQDN).

In some cases you might want to use only one identity and you want to
clear out old identities, for example in cases where you use securID
card or similar and you have forgotten to log out from the office
workstation, and you then log in with same card from your home.

All of this depends on the configuration and policy defined in the VPN
gateway. 

> two different work stations at the same time.

There is nothing preventing you to configure your systems to allow
that. 

> Are you saying that I would need 2 phase 1 IDs to do that?

Yes, if you want to use NAT traversal or IKEv2 and you want to send
INITIAL_CONTACT notifications. 

> Is it a generally accepted limitation of IPSec that identities are
> tied to a particular device?

Normally identities are tied either to the device or to the user.
Everything again depends on the policy. 

> This would have to be true in order to process an INITIAL-CONTACT
> notification based on IDs only.

In NAT-T draft and also in the IKEv2 the INITIAL-CONTACT is only
processed based on the authenticated identities only:

from the draft-ietf-ipsec-ikev2-12.txt:
----------------------------------------------------------------------
        INITIAL_CONTACT                          16384

            This notification asserts that this IKE_SA is the only
            IKE_SA currently active between the authenticated
            identities. It MAY be sent when an IKE_SA is established
            after a crash, and the recipient MAY use this information to
            delete any other IKE_SAs it has to the same authenticated
            identity without waiting for a timeout.  This notification
            MUST NOT be sent by an entity that may be replicated (e.g.,
            a roaming user's credentials where the user is allowed to
            connect to the corporate firewall from two remote systems at
            the same time).
-- 
[email-masked]

---

From: Thor Lancelot Simon <[email-masked]>
Date: Thu, 15 Jan 2004 01:08:35 -0500

> the same VPN you should have separate private key and identity for

It seems to me that implementations could easily allow the use of
the identity,address,port tuple instead of just "identity" or
"address,port" (the latter being a bug).  This seems more flexible
and, to be honest, I don't see any downside to it at all.  Do you?

Requiring a different identity for each device used by a given user
is likely to cause severe problems with X.500 identies, considering 
how certificates are usually allocated to users.  I worked on one
implementation (IKEv1 without Initial Contact, FWIW) where this would
have been an utter disaster for some of our largest customers.

Thor

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Jan 2004 14:50:08 +0200

> and, to be honest, I don't see any downside to it at all.  Do you?

Yes. In that case it does not work if the other end is behind NAT (i.e
the host is rebooted, and it gets new address or port after reboot, so
the state is not cleared up). It also does not clean up state if the
user simply closes machine and then moves another place and restarts
it there (new IP). The state is left running in those cases.

Anyways this is again somewhat policy matter, and depends on the
configuration and setup. 

> how certificates are usually allocated to users.

I do not see any problems there. It is actually much harder to share
the same private key in multiple machines than to create separate
private key and certificate for each device (implementations allowing
pkcs10 based certficiate enrollment or similar, might not allow any
standard way to get private key out to another machine).

> I worked on one implementation (IKEv1 without Initial Contact, FWIW)
> where this would have been an utter disaster for some of our largest
> customers.

I do not see any problem for your implementation then to be configured
to use only IP/port or IP/port/ID if you do not have NATs or mobile
users there.

The use of INITIAL_CONTACT in the IKEv2 is much smaller anyways, as
the dead peer detection will detect the disappearing remote hosts, so
INITIAL_CONTACT only causes that happen little bit sooner. 
-- 
[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Thu, 15 Jan 2004 10:12:39 -0500

>>>>> "Thor" == Thor Lancelot Simon <[email-masked]> writes:

 Thor> On Thu, Jan 15, 2004 at 05:21:16AM +0200, Tero Kivinen wrote:
 >> David Wierbowski writes: > Are you saying that an identity may use
 >> IPSec from one device only?
 >> 
 >> working solution going through NATs each identity should only be
 >> tied to one device. This normally is the case, your private key is
 >> only stored in exactly one machine, and it is tied to one
 >> certificate having one identity. If you have another device you
 >> use to connect to the same VPN you should have separate private
 >> key and identity for that (for example FQDN).

 Thor> It seems to me that implementations could easily allow the use
 Thor> of the identity,address,port tuple instead of just "identity"
 Thor> or "address,port" (the latter being a bug).  This seems more
 Thor> flexible and, to be honest, I don't see any downside to it at
 Thor> all.  Do you?

 Thor> Requiring a different identity for each device used by a given
 Thor> user is likely to cause severe problems with X.500 identies,
 Thor> considering how certificates are usually allocated to users.  I
 Thor> worked on one implementation (IKEv1 without Initial Contact,
 Thor> FWIW) where this would have been an utter disaster for some of
 Thor> our largest customers.

Agreed.

Since a "device" can have multiple NICs, it can have multiple
addresses.  So if "address" is used as part of the tuple that
distinguishes devices, how are multi-NIC devices handled?

	      paul