RE: addresses and IKEv2

["Eric Nielsen" <Eric.Nielsen@sylantro.com>]

From: Charlie_Kaufman@notesdev.ibm.com
Sent: Saturday, June 01, 2002 4:02 PM
> I think the conclusion from this string was that an implementation
> MUST ignore both addresses, and base its processing solely on the SPI.
Does
> anyone object to that?

I believe that IKE should allow some sort of policy
be applied regarding how to respond to the message. 
There needs to include the ability to perform some 
external check, too. 


Example:

If "A" was to reboot and come up at IP "1.1.1.3" it would
need to retain the SPI context over reboots. This is possible.
The real problem is upon initial connection, or if the SPI
is lost. The mechanism for startup should be the same as it
is for ongoing address changes. 

In this example assume there is an endpoint named "A@domain" 
expected to be deployed at IP address 1.1.1.1. Also assume 
manual symmetric keys are used. 

The server needs to be pre-configured saying that "A" is 
at IP address "1.1.1.1" with key "KEY_A". However, when
unit "A" is plugged in DHCP gives "A" the address 
"1.1.1.123". There is no way that the server can know to 
match "A"'s communications with "KEY_A" unless the installer 
calls back to the server to reconfigure it.

There should be an optional generic way to link the security 
key to information other than IP address and/or port. 

If I also have an endpoint "B@domain.com" at address 1.1.1.2,
I do not want "A" to be able to send spoofed but authenticated
packets that say that packet came from "B" at IP address ".2".
There needs to be some policy limiting whether to accept this
packet. Possibly a hook for a third-party check would go 
nicely to handle this case.

Eric


-----Original Message-----
From: Charlie_Kaufman@notesdev.ibm.com
[mailto:Charlie_Kaufman@notesdev.ibm.com]
Sent: Saturday, June 01, 2002 4:02 PM
To: ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2






I apologize for the formatting mishap in my last posting. Some people
received it correctly; others with all the EOLs stripped out. I haven't
figured out why. I hope it doesn't happen again with this message.

I'm trying to figure out whether we reached any implementable conclusions
on this topic.

The IKEv2 spec doesn't say what an IKE implementation should do if it gets
a message with a recognized SPI but an unexpected source (or destination)
address. I think the conclusion from this string was that an implementation
MUST ignore both addresses, and base its processing solely on the SPI. Does
anyone object to that?

The IKEv2 spec says "An implementation MUST accept incoming connection
requests even if not received from UDP port 500, and should respond to the
address and port from which the request was received." (Section 2.11). I
propose that language be extended to say that the source IP address and
port should be remembered with the connection state and that all messages
subsequent to connection setup be sent to the IP address and port
associated with the connection (ignoring the source of subsequent
messages). Does anyone object to that?

I am sympathetic to Francis Dumont's suggestion that there be a new
optional payload that securely tells the other end that its address is
changing and that all future IKE, ESP, and AH traffic to this entity should
be directed to a new IP address and possibly port. This would allow a
better and more secure integration with MobileIP allowing connections to
stay up when nodes move without introducing yet another layer of headers.
But I'm reluctant to specify it without at least consulting with MobileIP
savvy people and what I'd really like is for someone to express an intent
to implement it.

What do people think?

      --Charlie