On Tue, 15 Dec 2015, Valery Smyslov wrote:
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?
I think the subsystem should "send" it, whether it gets dropped or
queued up for a new TCP session would be up to the implementation?
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?
Yes, since about 1997 :)
If you did not realise that you spend too much time on IETF networks :)
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?
Yes. around 15-20 minutes if you are on stable (non-coffee, not-hotel) NATworks.
> 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.
That I disagree with. I want to cleanup roadwarriors who have left at
some point, which means a liveness probe without me having traffic
pending for them.
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?
I guess it assumes the other end acts the same, so if any endpoint wants
to send, they will do liveness. But I agree the RFC text could be
better.
(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.
I know. But I still can't do that :) I'm not even sure if most IKEv2
implementations can run fine without port 500. Also I would have
prefered to get rick of 4500, not 500, which is not what 7296 allows.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
