Hi Tommy,
thank you for the answers. See my comments inline.
The idea of using TCP as the fallback from UDP is exactly what the entire draft
is about.
The preconfiguration is not whether to always use TCP, but whether to use TCP
once
UDP fails, and upon which port. Since the entire idea of using TCP is
predicated on the
idea that UDP was already blocked on a previous attempt, this must be
preconfigured.
TCP is only used when UDP fails:
"If both of the other two methods are not
available or appropriate, both IKEv2 negotiation packets as
well as ESP packets can be sent over a single TCP connection to
the peer."
As it says in the configuration section, UDP is the preferred transport:
"Since TCP encapsulation of IKEv2 and IPSec packets adds overhead and
has potential performance trade-offs compared to direct or UDP-
encapsulated tunnels (as described in Performance Considerations, Section 7),
implementations SHOULD prefer IKEv2 negotiation over UDP.”
We can make it more explicit that UDP should be tried first, but that is
certainly the intent.
Yes, please. The current text is not very explicit about that, at least in me
reading.
Those implementations that support TCP encapsulation MUST still support
traditional transport, defined in [RFC7296] for IKE and in [RFC4303] and
[RFC3948] for ESP.
Sure, although I think clarifying (1) that UDP is always tried first should
cover this as well.
Agree.
Although a TCP stream may be able to send very long messages,
implementations SHOULD limit message lengths to typical UDP datagram
ESP payload lengths.
I wonder what is a "typical UDP datagram ESP payload lengths"?
How implementation could limit upper-level's message length?
Based on discussion on the list, we decided not to specify a specific value.
The point is to not send very
large messages in the TCP stream, since they will often be sent back into a
traditional unix
networking kernel once decrypted. The message length can be simply limited by
setting the
MTU to a normal value on the virtual interface being used for the VPN.
I think it would be benefitical for implemeters if you clarify this giving them
some
concrete guidelines.
An unexpected FIN or a RST on the TCP connection may indicate either
a loss of connectivity, an attack, or some other error. ... The original
initiator (that is, the endpoint that initiated the TCP connection
and sent the first IKE_SA_INIT message) is responsible for re-
establishing the TCP connection if it is torn down for any unexpected
reason.
I think this is not enough. Consider the situation when attacker manages to
send RST to only one peer, say it be the original responder. In this case
the states of the peers become de-syncronized: while the original responder
tearns down its TCP session, the original initiator thinks it is up.
If the original responder has some data to be sent while the original initiator has no such data, then we have
some kind of deadlock.
It seems that the original initiator must send keepalive messages
with a pretty high frequency whenever it becomes idle.
RST attacks are inherent to TCP. What do you propose on top of this? I don’t
think we want
to recommend for more frequent keepalives, necessarily. Note that any time the
client will
try to send any traffic (this is any ESP traffic, so it will probably be fairly
quickly),
the connection will get a RST if the server thinks the port is no longer open.
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.
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.
7. I think it's worth to clarify that with TCP encapsulation the IKE SA
establishment starts using port 4500 from the very beginning, so no port
switching from 500 to 4500 takes place.
It’s not necessarily port 4500 at all! In fact, it will likely not be. But that is true that port switching does not
take place. We can add a line to re-iterate that.
Oh, I see that the port is not necessary 4500. However I think
the clarification that no port switching takes place would be useful.
Conclusion: among the listed only the IKE check liveness messages
are relevant to TCP encapsulation. But their usage in this case should be
clarified (see my comment #5).
I disagree that the other keep alive types are not relevant. This section is
simply a list
of "mechanisms [that] may be employed” for keepalives, and it is useful for an
implementer
to know which keep alive mechanisms may be taking place on their connection.
From my naive :-) literal reading the section lists the keepalive methods that
are available
for the implementation to choose from:
It is up to the implementation to decide which keepalives are
appropriate for TCP-encapsulated connections.
So, I read that as the implementations should be aware of all these methods and
use an appropriate one. But this reading differs from your clarification below:
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.
The ESP implementation
in a kernel may not know that the traffic will be sent over a TCP flow, and if
MOBIKE is being used,
it may switch between UDP and TCP on different networks. Therefore, we should
not recommend
that NAT keepalives be disabled.
Well, I think that IPsec level must always know what encapsulation is currently
active and use NAT keepalives only when UDP encapsulation takes place.
For example, it doesn't send NAT keepalives if "direct" encapsulation is used.
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:
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.
We can remove the spurious “NAT” qualifier from the TCP keepalives.
OK.
9. Please, add text that some of IKEv2 (and its extensions) mechanisms
become useless with TCP encapsulation and MUST NOT (SHOULD NOT?)
be used. In particular - cookie has a little value with TCP since it is no
longer
allows responder to remain stateless. Moreover, TCP handshake determines
peer IP address and protects to some extend from spoofing (I assume ISN
is unpredictable as it should be). Another thing that becomes useless is
sending NAT keepalive messages (but see previous comment).
And IKEv2 extension that becomes useless with TCP encapsulation is
IKEv2 fragmentation.
I do not think we should recommend that any of these extensions MUST NOT be
used,
Note, that I've also included "SHOULD NOT" as an alternative since MUST NOT is
probably too strong.
specifically since TCP encapsulation is something done as fallback for
connections in which
UDP is blocked, and in the case of MOBIKE, may be used on a connection that
uses UDP
on other networks.
- Cookies: the TCP connection here should not be considered ‘state’ from the
perspective of IKE.
The TCP connection is independent of the IKE sessions. It still may be useful
to keep the cookie mechanism.
Well, I see the only useful application for the cookie in case of TCP
encapsulation -
if puzzle mechanism is adopted then the cookie must be used even in this case.
- We already address NAT keepalives: "If TCP keep-alives are used, IPSec ESP
NAT keep-alives may be
considered redundant and can safely be disabled.”
- Fragmentation is still useful, depending on the implementation. One way of
implementing is by taking
the TCP messages, re-encapsulating them as traditional UDP, and forwarding them
onto a legacy stack.
There is also the consideration of MOBIKE—we want to negotiate fragmentation
support in case we
switch back to a network that supports UDP!
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.
Thank you,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
