> On Dec 14, 2015, at 6:46 AM, Valery Smyslov <[email protected]> wrote:
>
> Hi,
Hi Valery,
Thanks for your comments! Responses inline.
>
> I have some comments on the TCP Encapsulation draft.
>
> 1. The draft assumes that using TCP encapsulation is always pre-configured,
> i.e. for each peer there is a configuration option with two possible values
> - either "use traditional UDP transport" or "use TCP (TLS) transport".
> I think that this is inflexible since network topology can change over time
> as well as middleboxes' capabilities. Since TCP encapsulation is a "last
> resort" with a lot of drawbacks, I'd rather make it use only when it is
> really needed. Granted the use of TCP encapsulation
> cannot be negotiated, however the case when it is needed can be detected.
> So, I suggest to add the third option - "try first UDP transport and fall
> back
> to TCP (TLS) encapsulation if no response was received". Note, that this
> behaviour
> is already defined in the draft when peer's addresses are changed via
> MOBIKE, I just suggest to make it available from the beginning of SA
> establishment.
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.
> 2. Please, emphasize that TCP encapsulation cannot replace traditional
> transport, otherwise we can run into interoperability problem. Something
> along the lines:
>
> 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.
>
> 3. The following text in Section 3 is unclear to me:
>
> 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.
> 4. The draft is silent about AH. I presume AH cannot be used with TCP
> encapsulation (as it cannot be used with UDP encapsulation),
> however I think it must be spelled out.
Okay, we can say this only applies to ESP, not AH.
>
> 5. For the following text:
>
> 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.
>
> 6. Section 5 allows presence of multiple TCP connections for a single IKE SA,
> however this is allowed for some corner cases. It is my impression, that
> in most cases there will be one TCP connection per IKE SA. If it is the
> case, then some clarification should be added how
> situations when peer temporarily has more TCP commections per
> IKE SA are resolved. Consider the example from the comment above, but
> when RST is sent only to the original initiator. In this case the initiator
> restores TCP connection, that leads to an existence of 2 TCP
> connections on the original responder - the old, which is defunct,
> but the responder thinks it's up, and the newly created. Which
> connection the responder should use? It seems that
> some clarification should be added along the lines:
>
> If an IKE endpoint receives cryptographically protected message
> on a new TCP connection, that is different from the TCP connection
> associated with the IKE/ESP
> SA the message was received over, the endpoint MUST
> tear down existing TCP connection and MUST use the new
> one for their outgoing traffic.
>
> I'm not sure this text alignes witth the allowance to have
> multiple TCP connections per SA, though…
I think that recommendation makes sense. We’ll work on it and add to the next
version.
>
> 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.
>
> 8. In my opinion Section 8 is a mess. It mixes up all kinds of
> keepalive-like messages used for different purposes.
> First, I don't think NAT keepalive messages are needed
> for TCP encapsulation. As far as I know NAT boxes keep track
> of TCP state and keep mapping until TCP is torn down
> (unlike UDP where no explicit indication of session state exists
> and therefore it is only determided by existence of traffic).
> Disclaimer: I'm not an expert in modern NATs and probably
> things get changed and I'm wrong. In this case the TCP encapsulation of
> NAT keepalive messages must be described in the document,
> since they are neither IKE nor ESP messages.
> Then, there is no such thing as "TCP NAT keepalives". The referenced
> RFC1122 describes TCP keep-alives (no "NAT"!)
> and their sole purpose is to allow server to clear up stale
> TCP connections when clients reboot. RFC1122 never suggested
> to use them as NAT keepalives (note the recommended default interval for
> them - no less than 2 hours!). Disclaimer: again,
> I'm not an expert in modern TCP trends, but if currently TCP
> keep-alives are used differently, then appropriate source
> should be referenced.
>
> I'm not familiar with TLS keepalives, but I'd rather let TLS
> along and let it use its mechanisms as specified in TLS RFC,
> without imposing additional requirements in this document.
>
> 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. 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. 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.
We can remove the spurious “NAT” qualifier from the TCP keepalives.
>
> 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, 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.
- 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!
Thanks for your time looking at this!
Tommy
>
> Regards,
> Valery Smyslov.
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
