Subject: (NAT) RSIP and IKE rekey

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 2 Dec 1999 09:25:49 -0800

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.

---

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Thu, 2 Dec 1999 14:50:13 -0800

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

Any ideas? 
-

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 6 Dec 1999 10:43:08 -0800 (PST)

--- Mike Borella <[email-masked]> wrote:
> 
> 
> I think these issues are slightly different.

I agree.

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

Yes. Rekeying phase-I SA can be tricky. The "Continuous phase-I model"
that is being discussed in IPsec in the context of remote access users
might help the RSIP case as well. I believe, the rekeying discussion 
in the context of RSIP parallels the same rekeying discussion going on 
in the IPsec mailing list (or IPSRA mailing list) vis-a-vis 
Secure-remote-access. More on this below. 

Independent of the outcome of "continuous  model", one way to get around 
this issue would be for the RSIP client to take ownership of rekeying. 
I think, using a port other than 500 is bound to run into interoperability
issues and as such may not be a good idea to go down that path.

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

This is a valid concern as well - Being able to securely contact an RSIP
client from external realm. But, this wont work with RSIP (i.e., RSA-IP 
or RSAP-IP), generally speaking. This can work with RSA-IP only if a 
static mapping exists between private adress(of RSA-IP client) and 
external  address on the RSA-IP server.

The reason inbound IKE does not work with RSIP is principally because of 
an inherent problem with IKE. Today, multiple users on a single multi-user
system (like a SUN UNIX system or a Remote Access Server) can establish IKE 
session with an external node. But, the external node cannot selectively
contact the individual user on the multi-user system to setup an IKE 
session. Please note the analogy between RSIP server and multi-user system.

IKE works best when the responder node has a uniquely identifiable address 
and no two responder nodes share the same address. When an external node
initiates an IKE session to a user on multi-user system, there is no way 
for the responder node (as opposed to the responder user) to determine who 
to direct the message to. Both rekeying and inbound session initiation are 
tied to the same inherent problem. Even in the aggressive mode, the first 
IKE message contains the ID of the initiator, but does not contain the ID 
of the responder the initiator is trying to contact.
 
> 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.
> 
I agree, the limitation is worth noting in the framework/protocol documents.

> -Mike

cheers,
suresh
> 
> 
> 
> "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
> 
> 
> 
> 
> 

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Mike Borella" <[email-masked]>
Date: Thu, 9 Dec 1999 08:33:27 -0600

Yes, I'm suggesting that IKE act like a "normal" protocol. :-)

I still don't understand why the fixation with port 500, and it seems like
it is a point of confusion.  If there is no benefit to forcing source and dest
to use 500, then why bother?

And yes, we'll still have to support the cookie mechanism for implementations
that need it.

-Mike

"Bernard Aboba" <[email-masked]> on 12/03/99 07:39:38 AM

Please respond to [email-masked]

Sent by:  "Bernard Aboba" <[email-masked]>

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

>This may be alleviated if IKE is not fixed

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.

-