[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: addresses and IKEv2



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

Isn't this more of a question for the SPD spec? If you're talking about a
message with recognized cookies, but an unexpected source, that is something
we could handle in SOI.


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

Yes, this is an important case. Currently we perform this check during SA
establishment. Doing it via a user mode callback could be a much more
expensive proposition, especially if someone got their hands on a captured
packet and started replaying it from thousands of different IPs.


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

There is an allusion to this issue in the requirements document. Having an
IKE message for updating the mobile IP makes a lot of sense. It seems to be
the only good way to securely deliver the update to the right place in the
stack without introducing a lot of extra overhead (e.g. a new phase 1
negotiation).

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Eric Nielsen
> Sent: Monday, June 03, 2002 3:49 PM
> To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com
> Subject: RE: addresses and IKEv2
>
>
> 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
>
>