Hi,
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.
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.
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?
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.
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.
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...
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.
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).
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.
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
