Subject: RE: (NAT) RSIP and IKE rekey

From: "Mike Borella" <[email-masked]>
Date: Thu, 2 Dec 1999 17:41:35 -0600

I think these issues are slightly different.

Bernard has brought up the case of an external host rekeying
by choosing a new isakmp SA, which the RSIP gateway doesn't
know what to do with.  This may be alleviated if IKE is not fixed
at source port 500, and therefore we don't have to muck with cookies.

On the other hand, Ylian is referring to the case in which an external
host talking to multiple RSIP clients doesn't know which isakmp SA
to use because it is basing the identity of its peer on the shared
IP address.  Here, IMO, the external implementation is not making the
right assumption.

Hope I'm not putting words in anyone's mouth.

The important thing is to document exactly how and why these issues
come up and what can be done about them.  We need reach consensus
on that soon.

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 12/02/99 04:50:13 PM

Please respond to "Saint-Hilaire, Ylian" <[email-masked]>

Sent by:  "Saint-Hilaire, Ylian" <[email-masked]>

To:   "'Bernard Aboba'" <[email-masked]>, [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: (NAT) RSIP and IKE rekey

We figured the same problems and are working gathering information on this.
Within the current scope of RSIP, I don't believe we should hold the
documents back because of this. It is clear that multiplexing multiple IPsec
traffic to a single destination will cause problems.

Ylian Saint-Hilaire
INTEL - Communication Architecture Labs

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, December 02, 1999 9:26 AM
To: [email-masked]
Subject: (NAT) RSIP and IKE rekey

There are some issues that arise in the case of a responder
rekey of an existing SA.

In this case, the responder will send an IKE packet that
may have a new initiator cookie. The RSIP gateway will
be unable to determine who this should be forwarded to,
since it does not have any state relating to that
cookie.

Some ideas on how to deal with this:

1. Try to set the RSIP lease time so that the client
will initiate rekey rather than the responder. Not
clear this can work because rekeys can be undertaken
for reasons other than just expiration of the SA,
and therefore the time at which this can occur is
unpredictable.

2. Use the IPSEC non-port specific method. This would
send *all* IKE traffic from a given destination to the
registering client. This is somewhat ugly since it
prohibits multiplexing of IKE to the same destination.
Hope we don't have to go here.

Any ideas?
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 2 Dec 1999 17:49:14 -0800 (PST)

> at source port 500, and therefore we don't have to muck with cookies.

that would do it. the re-keying draft draft-jenkins-ipsec-rekeying-02.txt
talks about a "continuous model" which would help when re-keying phase
2 sa's. but you're right, re-keying a phase 1 sa is problematic.
it is the same problem as accepting incoming phase 1 sa's, which
we already know we have a problem with (except when we
can use a port other than 500 to accept those incoming connections).
 
> IP address.  Here, IMO, the external implementation is not making the

agreed, i thought this was already put to rest by this message (which
did not make it to [email-masked], so i'm sending it here):

>----- Begin Included Message -----<

Date: Mon, 15 Nov 1999 18:24:44 -0800
From: "Scott G. Kelly" <[email-masked]>
Subject: (NAT) Re: IKE negotiation/rekeying problem with RSIP
To: "Saint-Hilaire, Ylian" <[email-masked]>
Cc: "'Mike Borella'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>, [email-masked], "David Grabelsky" <[email-masked]>

"Saint-Hilaire, Ylian" wrote:
> 
> Even if we get out of using pre-shared keys and start using certs, there is
> no requirement in the IKE standard to choose one phase 1 over another. For
> example, IKE standards don't require that a re-key of a phase 2 MUST be done
> over the same phase 1 as the original SA. Even if we use certs, I would
> guess that no IKE implementations will currently look at the cert of a phase
> 1 before selecting it for a phase 2.
> 
> Ylian Saint-Hilaire

Actually, I think this may be incorrect. Ostensibly, the 2 users behind
the rsip server would use separate authenticators (not the same
preshared key or cert). If this is true, then the phase 2 SAs are bound
to the respective phase 1 SAs by the authentication materials used in
each case. If the kernel (or whatever you want to call the ipsec portion
of the stack) requests a phase 2 negotiation from IKE, it must provide
IKE with identifying information (and authentication requirements) with
which IKE can determine whether an existing phase 1 SA is appropriate.
If the IKE implementation does not verify that the phase 1 SA meets the
authentication requirements before using it, I think the IKE
implementation is badly broken.

Scott
-

>----- End Included Message -----<

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 2 Dec 1999 23:14:37 -0800

> This may be alleviated if IKE is not fixed

Yup. Who wants to raise this issue on the IPSEC list? (I suggest
donning an asbestos suit).
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Paul Francis <[email-masked]>
Date: Fri, 03 Dec 1999 17:28:35 +0900

> donning an asbestos suit).

I don't think you'll need an asbestos suit, just a good firewall  :-)

PF
-

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 03 Dec 1999 03:47:50 -0800

Hi Bernard,

> donning an asbestos suit).

I'm sort of peripherally following this conversation, so forgive me if I
say something which proves I don't fully understand the issues. I
*think* what I'm hearing is that if the remote ipsec peer tries to rekey
an existing IKE SA, the nat gw won't know who to send the traffic to
since the cookie is unrecognized. 

IKE is already permitted on ports other than 500 - support for 500 is
required of compliant implementations, but there is no reason why a
different port can't be used. The (interoperability) trick would be in
the remote implementation's configurability in this regard.
Alternatively, remote peers could "remember" what port the rsip-enabled
peer initiated from, and rekey on that port, but I'm not sure how many
implementations work this way now. Our next release will...

I don't think these ideas are controversial, though the mention of
"continuous model" in this vein is likely to get people's attention. As
you know, there's not much agreement on that at this point. However,
since this model simply entails always keeping a phase 1 SA up (as
opposed to deferring rekeying under some circumstances), I don't think
it's particularly relevant. The real problem here is with who initiates
the rekey, and this problem remains whether the rekey is deferred or not
- the problem seems to be with who initiates the rekey.

As an interim workaround, the rsip-enabled end could be configured with
a shorter phase 1 lifetime than the remote peer, which should insure
that the rekey is initiated from the rsip end. Just a thought.

Scott
-

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 3 Dec 1999 05:39:38 -0800

>at source port 500, and therefore we don't have to muck with cookies.

Are you suggesting that we move toward a conventional port allocation
approach for IKE? For those implementations that can float the source
port, this would be desirable. However, for those that cannot, this
would result in only a single client being able to use IPSEC at a 
time. In contrast, if you also support cookies, at worst your
restriction will be that only a single client will be able to open
an IKE SA to a given destination at a time.  

Therefore I think that we will need to continue to support cookie-based
demultiplexing even if we also provide a source port alternative. 
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 7 Dec 1999 05:48:47 -0800

>IP address.  Here, IMO, the external implementation is not making the

I think that the solution to this one is for the IKE initiator to
negotiate *very* specific filters for the IPSEC SA so that the 
destination will not be confused. For example, if the RSIP 
client were to dynamically plumb a filter corresponding
to the RSIP port/address that it was allocated, this would guarantee 
uniqueness. 

Example filter:
From: <RSIP allocated IP address> To: destination address 
Source Port: <RSIP allocated port> Dest Port: destination port

-