Hi Paul,
The situation described above is quite real. Suppose the client is
downloading a large file
from the server. In this case the server always has data to be sent, while
the client
only responses with ACKs. If the client receives no new data it just waits.
Of course
if it has something to send, the TCP connection will be restored. That's why
it is probably worth to send liveness check messages from the initiator to
the responder
if there is no incoming traffic for some period of time (say 10-20 seconds)
and the endpoint has no data to send to the peer.
Applications already need to deal with silent remote parties? It
does not depend on ESPinTCP. So I find this example not very convincing.
I don't care about applications, I care about IPsec implementations :-)
Currently an IPsec implementation can always send out a ESP packet
if ESP SA is up. With TCP encapsulation there may be situations
when ESP SA is up, however the encrypted packet cannot be
send out because there is no TCP session associated with this
ESP SA. What IPsec implementation is supposed to do with the data
that TCP/IP stack is trying to send out? Discard? Collect in a hope
that TCP is restored quickly?
However, NAT gateways do time out TCP connections, so if the IPsec SA is
genuinely idle, we might need to send something to keep it alive. But
then sending a liveness probe is fine for that.
Are you saying that if I open telnet session via NAT and then
go for dinner, that the session will be broken when I return?
Well, I agree that NAT and firewalls can drop any TCP session
at their will, but do they do it regularly in case of timeout?
And what is the typical timeout timeout for TCP?
Note, that it is a bit different from how liveness check messages are
supposed
to be used in IKEv2, where liveness check should be done if there is no
incoming
traffic for some period of time AND if the endpoint is about to send new data
to the peer.
That's not my understanding of livenss. What we do is time based
liveness probes that are skipped when we detected there was recent
traffic on the IPsec SA.
RFC7296 is not very explicit about that. Please see RFC3706 (DPD)
Section 5.5, that contains more speculations on this:
Since the liveliness of a peer is only questionable when no traffic
is exchanged, a viable implementation might begin by monitoring
idleness. Along these lines, a peer's liveliness is only important
when there is outbound traffic to be sent. To this end, an
implementation can initiate a DPD exchange (i.e., send an R-U-THERE
message) when there has been some period of idleness, followed by the
desire to send outbound traffic.
Compare with RFC7296, Section 2.4:
If no
cryptographically protected messages have been received on an IKE SA
or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer.
Here - if you don't want to send message to a peer, you don't care if
it is dead, do you?
Oh, I see that the port is not necessary 4500. However I think
the clarification that no port switching takes place would be useful.
When an RST happens, you do come back and if behind NAT you most likely
will come back on a different port. So be caerful with using terms as
port switching.
Agree.
(I wish we could get rid of that anyway, are there still
any ipsec passthrough devices in use mangling port 500? or is there any
reason why not to always start on 4500?)
You can. It is explicitely allowed by RFC7296.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
