RE: [Ipsec] comment on "empty message" in IKEv2 draft

["Charlie Kaufman" <charliek@microsoft.com>]

Issue: it might be useful in an otherwise empty "are you still there"
Informational exchange to have the initiator place an unpredictable
value in the request and have the responder echo it back. This prevents
the (admittedly arcane) attack where the responder pre-generates a
series of "yes I'm still here" messages and then forgets the session
key. As the protocol exists today, you can't be sure that the responder
still knows the session key - only that when he did he generated
messages ahead. (I personally would prefer to ignore such threats, but
it turns out there are some other more real uses for the protocol change
in the context of MOBIKE). A discussion has taken place under this
subject line as to whether it would be better to encode this
unpredictable value as a nonce or a cookie.

Tero writes: COOKIE is the only option, nonce is not an option, as it is
not sent back.

Francis responds: I don't buy this argument: I prefer Yonghui's one,
i.e., cookie has already this connotation (a weak form of the "least
astonishment" argument).

Charlie chimes in: I agree with Francis that we can do whatever we want.
It's a matter of taste which encoding is most natural in this context.
I'd be happy with either one, but I would prefer a third. My logic
follows:

I consider it too late to get this into the IKEv2 spec. I hope I'm not
wrong about that. If so, we should think of this as the first of many
extensions to IKEv2. IKEv2 was designed for extensibility. If we can't
make this one, we clearly blew it.

The IKEv2 spec goes out of its way to say what an implementation is
supposed to do if it gets a request it doesn't understand (sometimes it
ignores it, sometimes it rejects it, etc). This is so that we can extend
IKEv2 and predict how existing implementations will act when they see
the extensions. But the spec doesn't say what to do if you get a payload
that you *do* understand in a context where you don't expect it. Getting
either a cookie or a nonce in an informational exchange is an example of
such an event. I wish the spec had said to ignore such payloads, and I
hope that without any guidance that is what implementations do. But it
would be legal for them to do something else - like close the
connection.

So my preference would be to invent a new notify type for this purpose.
Existing implementations *are* directed to ignore notification types
they don't understand, so older implementations would not echo the nonce
back, but neither would they complain.

But this desire is only a matter of taste - in my case motivated by
theoretical purity. Assuming we can get this recommendation out in less
than a few years :-), all implementations of IKEv2 will handle either a
cookie or a nonce correctly.

	--Charlie

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec