On 06/14/12 16:25, Yoav Nir wrote:
On Jun 14, 2012, at 10:34 PM, John Leser wrote:
On 06/14/12 13:39, Yoav Nir wrote:
Hi Yaron
Responses are inline.
Yoav
On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote:
Hi Yoav,
thank you for the new draft. A few comments:
- Please mention the question of IKE keepalive messages
("liveness check"). Do you expect these messages to each be on
a new connection? Or to preserve one long-lived one?
I think section 2.1 makes it clear that the TCP connections
should be short-lived. Specifically, I would not send liveness
checks, which are very short requests and responses over TCP. I
would use UDP exclusively for those.
This section is a little unclear to me. Is the idea that the
initiator of the exchange(s) may send up to<IKEv2 request window>
requests, wait for the responses to arrive and then must close the
connection? Or can the initiator perform as many exchanges as it
likes over one TCP connection, so long as "knows" that it has
requests it wants to send? If this connection closing requirement
is designed to interact with the IKEv2 request window, please make
it more clear.
OK, I will. It has nothing to do with the request window. The
Initiator can send as many requests as it wants as long as it has any
to send. When it's idle (like if all the necessary child SAs are
ready) it should close the connection rather than leave it idle.
Thanks for clarifying. This does make the MUST in that section seem a
little out of place, since the condition of the initiator knowing it has
no more requests seems rather vague for a MUST.
I'd rather just allow either side to close the TCP connection at any
time. This may seem a bit drastic, but if you think about it, you're
balancing needs on both sides: 1. to not keep too much state, and 2. to
not incur the latency and overhead of establishing new TCP connections.
I suspect the state (memory) for a TCP connection could be
significantly larger than for an IKEv2 SA, depending on buffers and
implementation, etc. So it may be in either side's interest to drop
the connection to conserve resources, or leave it open to optimize for
performance when plenty of resources are available. I think we're
already in agreement that implementations will have to handle TCP
disconnects gracefully.
- The draft kind of skirts the question, and I would prefer to
be clear: we are standardizing new behavior for IKEv2, not for
IKEv1.
I think it's suitable for both versions. If this gets adopted by
the working group, and people object to standardizing new stuff
for IKEv1, I can remove all mention of it.
<hat type="vendor"> Our present implementation works with IKEv1,
and has done so for over 10 years. I could submit an
Informational describing how Check Point's implementation does
IKEv1 over TCP. But just as new ciphers would apply to both
versions, I think this transport can also be independent of
version. </hat>
I'd rather settle on the best possible solution for IKEv2 without
worrying about making sure it works for IKEv1 as well.
If that's where the group consensus is going, I am fine with making
an Informational document about IKEv1 over TCP in CP products.
- In the security considerations, we should mention that (under
certain assumptions), it is easier for an off-path attacker to
reset a TCP connection than a UDP "connection".
Yes, TCP presents some DoS opportunities not available for UDP.
I'll look for an RFC that talks about this. And if there isn't
one, there d**n well should be.
I suggest adding a MUST that a lost TCP connection or truncated
packet from the peer should never constitute a failed exchange
(which in many cases, closes the SA).
Agree
- There are obvious advantages to negotiating this capability:
you don't have clients sending SYNs that will get rejected by
firewalls/endpoints. Especially in IKEv2 where the heavy stuff
only happens on message #3.
SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending
a notification over UDP that says "I support TCP" doesn't help
much, because it cannot vouch for the path allowing TCP port 500.
I wonder if there's an actual use case for increasing the length
field of payloads, so that IKE can support larger payloads when
working over TCP. One use for this would be to send large CRLs in
a CERT payload.
I agree with the concerns Yaron has raised here. I would much
prefer that this be negotiated via notifications during the SA_INIT
exchange. I see a number of benefits:
1. The TCP listening port could be explicitly exchanged (as data in
the notification), rather than always assumed 500. This would
allow operation in parallel with any legacy/proprietary use of that
server port, and in general more deployment flexibility.
2. Since INIT always happens over UDP, as responder, I can
immediately close any TCP connection that doesn't present an IKE
header with an SPI I recognize.
I don't agree that IKE_SA_INIT should always be over UDP. The first
flight of packets from the server in TCP includes at most 2 packets.
Then the server has to wait for an ACK to continue. Same goes for the
request. So beginning with the IKE_AUTH exchange for TCP can add up
to three roundtrips. This is a shame when dealing with a peer that we
know supports IKE.
You incur the latency of the TCP handshake during either SA_INIT or
AUTH; I don't see the difference. A clever initiator could even
initiate the TCP connection for AUTH concurrently with computation of
the shared secret for the IKEv2 SA.
3. It fits better with the IKEv2 design of never assuming the peer
has capabilities beyond the base requirements without a
notification/vendor payload indicating otherwise.
Just as clients may start IKE over UDP port 4500, they should be able
to begin IKE_SA_INIT over TCP. We can still have those notifications
for clients using UDP for IKE_SA_INIT, but it would be silly to send
them over TCP.
The difference is port 4500 is part of RFC 5996 - a core IKEv2 capability.
I could be convinced we should support SA_INIT over TCP, since it would
allow IKEv2 to work when UDP transport is not functional, and would
allow transit of large SA_INIT messages (8192-bit KE with man SA
proposals could exceed 1280 bytes) when fragmented UDP is blocked. I'd
like to see more opinions as to whether it is worthwhile.
- 2.3: disallowing retransmissions implies a change on both
transmitter and receiver, and I think this is unnecessary. You
can change the IKE timeouts on the sender to achieve the same
behavior, even if rarely an odd retransmission does slip
through.
I guess. There is a MUST in section 2.4 for keeping
retransmission detection, so when implementing the transmitter,
you can do either. It doesn't make sense to retransmit at the
application level when TCP does it for you.
Do we want to specify (maybe as a SHOULD) a fairly rapid fallback
to UDP for retransmissions? This would help avoid protocol
failures when the UDP path is functional but TCP is not. Messages
ids should filter out any duplicates that get through.
Maybe as implementation advice. It doesn't affect interoperability.
It's the typical gray area of how far you go beyond simple interop in
trying to standardize "good" behavior.
-John
-John
Thanks, Yaron
On 06/14/2012 12:59 AM, Yoav Nir wrote:
Hi
I've submitted this draft as a possible solution to the
problem discussed in the thread about fragmentation causing
IKE to fail.
Comments are welcome.
Yoav
Begin forwarded message:
*From:
*"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>"
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
*Subject: **New Version Notification for
draft-nir-ipsecme-ike-tcp-00.txt* *Date: *June 13, 2012
7:13:55 PM GMT+03:00 *To: *Yoav
Nir<y...@checkpoint.com<mailto:y...@checkpoint.com>>
A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt has
been successfully submitted by Yoav Nir and posted to the
IETF repository.
Filename:draft-nir-ipsecme-ike-tcp Revision:00 Title:A TCP
transport for the Internet Key Exchange Creation
date:2012-06-13 WG ID:Individual Submission Number of
pages: 7 URL:
http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt
Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp
Htmlized:
http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00
Abstract: This document describes using TCP for IKE
messages. This facilitates the transport of large messages
over paths where fragments are dropped.
The IETF Secretariat
_______________________________________________ IPsec mailing
list IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________ IPsec mailing
list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________ IPsec mailing list
IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
