On Mon, 10 Jan 2022, Valery Smyslov wrote:
I am not sure this is a good idea. Tearing down and requiring a new 3way
handshake just to deliver the cookie seems useless. What is wrong with
using the existing TCP stream to reply?
The responder does use an existing TCP connection to reply,
but once it replies with cookie request, it should close this connection.
If it keeps this connection, then it keeps TCP state until the client
resends IKE_SA_INIT request (if ever) and thus thwarts the idea of being
stateless.
This is probably not so important for cookies, because the client
has already proved during TCP handshake, that its IP is a real IP address,
but it is more important in case of puzzles. But in both cases
I think that keeping responder stateless is a good idea.
Yes, stateless is good in those cases, but reality is we already used
state to setup the TCP connection. So why drop all that state now. It is
in a way too late for the "state creation savings". Instead, you are now
creating _more_ work for a server that might be under a DoS attack.
This might also make the code more complex, as currently, the TCP state
is kept during the entire negotiation.
No, RFC 8229 allows the responder to close TCP session at any time (Section 6).
Moreover, an attacker may reset TCP connection on its will.
In this case the TCP originator would restore it. So, no additional code
complexity,
you must already be able to handle this situation.
That's fair. I guess I have to test this on our code base :)
Additionally, a NAT router could give the client a different IP address
for a new TCP stream, making the COOKIE invalid.
Yes, it is possible and this situation is covered in the draft.
But if we choose between keeping the responder stateless and
the possibility of occasional failure of cookie verification,
I'd choose the former as more important.
I am choosing the other way around :)
I think we can slightly change this recommendation:
o if the Responder chooses to send Cookie request (possibly along
with Puzzle request), then the TCP connection that the IKE_SA_INIT
request message was received over SHOULD be closed after the Responder
sends its reply
and no repeated requests are received within some short period of time, so
that the
Responder remains stateless. Note that if this TCP connection is
closed, the Responder MUST NOT include the Initiator's TCP port
into the Cookie calculation (*), since the Cookie will be returned
over a new TCP connection with a different port.
Does it address your concern?
I don't really see much difference. If the attacker can setup a TCP
session, surely it can write 15 lines of python to replay the cookie
back as well. The question is really whether the responder under attack
is better of not needing as many TCP 3way handshakes versus keeping some
state. Since the document says to basically ignore cookies as much as
possible, it seems inline to just keep the TCP connection.
Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for
additional messages in case it receives error notification from the
Responder in the IKE_SA_INIT exchange.
This is true, but the code handlling this might not be aware of the
transport used. I'd rather see "an Initiator MAY skip the waiting time
for additional messages" so that this advice becomes "a good idea" and
not a "RFC violation" if not done.
Hmm, I think that "SHOULD NOT wait" leaves you a possibility to wait
if you have good reasons for it, without being accused in "RFC violation" :-)
I have no problems with MAY in general, but I think that it's better
to encourage implementers to make this optimization
(which MAY does not).
I'm looking at the damage here. There is again no good reason to tear
down the TCP connection for an INVALID_KE, so why tell implementations
to do that. Even if simple implementations might do that just because
that's how they do it for UDP (kill entire exchange, start a fresh one)
But I'd like to see us re-using the same TCP when receiving INVALID_KE,
even if it was only for the reduced latency of another 3way handshake.
Implementations that implement
both MOBIKE and TCP encapsulation MUST support dynamically enabling
and disabling TCP encapsulation as interfaces change.
I'm not sure of the MUST here. Nice for sure, but perhaps the
implementation supports MOBIKE or TCP and not both at once ?
Perhaps restate as "if MOBIKE and TCP encapsulation are allowed for a
configuration, the implementation MUST support ......
OK. So, the text would look like:
Implementations that implement both MOBIKE and TCP
encapsulation and both are allowed for a configuration
MUST support dynamically enabling and disabling TCP
encapsulation as interfaces change.
sure, just slightly different start:
Implementations that implement both MOBIKE and TCP
encapsulation within the same connection configuration
MUST ....
In case of TCP the NO_NATS_ALLOWED
notification SHOULD be ignored because TCP generally has no problems
with NAT boxes.
I would re-state it as:
In case of TCP the NO_NATS_ALLOWED notification MUST be ignored.
Although, re-reading why NO_NATS_ALLOWED was introduced, I think in
general this payload should be retired entirely, both for UDP and TCP.
(disclosure: libreswan completely ignores it)
I think "MUST be ignored" is quite a radical change to RFC 4555.
I prefer the current text since it leaves a possibility to not ignore
this notification , thus be compliant with RFC 4555. Otherwise
we would need to update it with this draft...
Fair enough.
8.3. IKEv2 Session Resumption
This section says that if a TCP encap session was suspended, that the
client MUST use TCP to resume this. I don't understand why. It is likely
that a resuming client has moved networks, and might be on a network
that would properly support ESP or ESPinUDP. The resumption is really
mostly meant to skip over DH and AUTH phases as these are costly. I see
no reason to tie the transport to this. If I missed a valid reason
for this to be needed, clarify what needs to happen when the server no
longer can or wants to resume the session. Does the client close the TCP
and go back to UDP?
I believe you are correct. The idea was to speed up SA resumption
(we know that this responder didn't support UDP, but worked with UDP),
however you are right that the situation may change.
So the correct recommendation for the client would be - act as if this is the
IKE_SA_INIT exchange.
Yes, perfect.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
