On Tue, 15 Dec 2015, Valery Smyslov wrote:
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.
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.
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.
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. (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?)
It is very important
that TCP encapsulation can be implemented as a layer transparent to
existing TCP, TLS, and ESP
implementations. By default, these layers may have keepalives of their
own.
I agree that layer separation is important, so the only available keepalives
for the IPsec layer are NAT keepalives and liveness check messages.
The other methods are irrelevant here. An implementation can be aware
of their an existance, but usually cannot control them. I think it must be
clarified.
Something along the lines of "Since the goal is to move back to UDP as
soon as possible, most properties of the IKE connection that only make
sense on UDP should still be kept for TCP".
In any case, if for the purposes of simplicity the draft allowed an
implementation
to send NAT keepalives in case of TCP encapsulation, then their layout and
processing should have been described (a la Sections 3.1 and 3.2).
And in this case the text from Section 3:
NAT keepalives and ESPinTCP packets have the same property of needing to
take packets from the TCP stream and not send them to userland. I'm not
sure if that's easy to do. Does an application need to see any lowlevel
TCP stuff like sequence numbers? Or can it just do a read() and not
worry? If this is transparent to the userland, eg it wont see the NAT
keepalives, then we might as well just allow them simiarly to UDP.
Although with DPD/liveness, it makes more sense to never use NAT
keepalives as the latter only keeps the mapping open but you don't
know if there is still anyone at the other end.
In order to encapsulate IKEv2 and ESP messages within a stream (which
may be raw TCP, or TLS over TCP), a 32-bit length field precedes
every message. If the first 32-bits of the message are zeros (a Non-
ESP Marker), then the contents comprise an IKEv2 message. Otherwise,
the contents comprise an ESP message.
is not correct, since NAT keepalives are neigther IKE nor ESP messages.
Oh, if we allow this inside a TLS stream, then I guess NAT keepalives
cannot be eaten by the kernel, so I would recommend not using them and
use a liveness probe instead.
I think that all the mechanisms that seem to become unnecessary with TCP
encapsulation
must be separately discussed in the document. There must be some text
describing under which
circumstances these mechanisms are still useful and when it is safe to
abandon them. I don't insist
on MUST NOT (or SHOULD NOT), but some guidlines must be given, otherwise
implementers will wonder: why should we spent resources doing useless things.
Isn't it more the other way around? When we cannot use these things we
need new code to track when NOT to do things. Still I agree we need
to guide implementors properly.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
