Re: [IPsec] TCP Encapsulation draft

["Valery Smyslov" <[e-mail]>]

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.