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

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