Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Jun 2012 00:59:04 +0300

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>

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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Jun 2012 01:40:21 +0300

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?
- The draft kind of skirts the question, and I would prefer to be clear: 
we are standardizing new behavior for IKEv2, not for IKEv1.
- 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".
- 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.
- 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.

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: *"[email-masked] <mailto:[email-masked]>"
>> <[email-masked] <mailto:[email-masked]>>
>> *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 <[email-masked] <mailto:[email-masked]>>
>>
>>
>> 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
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Jun 2012 20:39:05 +0300

Hi Yaron

Responses are inline.

Yoav

> 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.

> 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>

> 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.

> 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.

> 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.

> Scanned by Check Point Total Security Gateway.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Jun 2012 22:12:49 +0300

Hi Yoav,

please see below.

Thanks,
	Yaron

> 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…

Alternatively, one could use TCP keepalives. If you have a NAT device in 
the path (and you probably do, in the cases we're discussing here), its 
behavior will differ between the two options.
> 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 ciph…

With a Chair hat on, I strongly object to standardizing this for IKEv1.
> 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…

Firewalls have been known to eat up SYN packets with no RST, as you well 
know... Also, if UDP/500 goes through, you are basically guaranteed to 
have TCP/500, too. And implementations can be simplified if the usual 
case is: negotiate in IKE_SA_INIT, then switch to TCP.
>>>> *From: *"[email-masked]<mailto:[email-masked]>"
>>>> <[email-masked]<mailto:[email-masked]>>
>>>> *To: *Yoav Nir<[email-masked]<mailto:[email-masked]>>
>>>>
>>>>

---

From: John Leser <[email-masked]>
Date: Thu, 14 Jun 2012 15:34:10 -0400

> 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…

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.

> 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 ciph…

I'd rather settle on the best possible solution for IKEv2 without 
worrying about making sure it works for IKEv1 as well.

> 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).

> 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…

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.

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.

> 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 w…

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.

-John

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Jun 2012 23:25:16 +0300

> 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.

> 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.

> from the peer should never constitute a failed exchange (which in many 

Agree

> close any TCP connection that doesn't present an IKE header with an SPI 

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. 

> 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.

> any duplicates that get through.

Maybe as implementation advice. It doesn't affect interoperability.

---

From: John Leser <[email-masked]>
Date: Thu, 14 Jun 2012 18:21:43 -0400

On 06/14/12 16:25, Yoav Nir wrote:
>>>> - 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>
>>
> 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.
>

It's the typical gray area of how far you go beyond simple interop in 
trying to standardize "good" behavior.

-John

>>>> Thanks, Yaron
>>>>> 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:
>>>>>> *"[email-masked]<mailto:[email-masked]>"
>>>>>>
>>>>>>
>>>>>> *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<[email-masked]<mailto:[email-masked]>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> 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 [email-masked]
>>> _______________________________________________ IPsec mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
> _______________________________________________ IPsec mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jun 2012 13:13:59 +0300

Yoav Nir writes:
> 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. 

As liveness checks are supposed to check whether other end is there,
not whether the path you send packets is there, it does not matter
which path is used. And also note that you are NOT supposed to send
periodic liveness checks like some implementations are doing. You are
only supposed to do them when you suspect something is wrong (i.e. no
traffic from other end, ICMP error message, or in this case the TCP
connection we have with other end is reset). 

> 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.

I would be strongly against adding this to IKEv1. IKEv2 was published
7 years ago, people should start updating their products...

> <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 would be more happy if you would as a vendor try to get people to
move IKEv2 not add some stuff to IKEv1.

IKEv2 is much more robust protocol and provides standarized features
for lots of things IKEv1 does with private extensions (configuration
mode, xauth etc).

> 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

I have not read your draft so I do not know how you do it (I am on
vacation now), but I think capability indication is needed, not
really negotiation, but indication from either or both ends that they
do support this so it is worth of trying to establish the TCP
connection. At least that would provide some better feedback, i.e if
the other end do support it but TCP connection fails, then there is
most likely firewall filtering TCP packets, compared to the other end
not supporting this feature at all. 

> 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.

We already have Hash and URL format for transmitting large CERTs, and
we have mechanism in the PKIX to provide CRLs over some other
transport than IKE. I think we can keep the current 64k limit. 

> 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.

With MOBIKE it does make sense to retransmit at the application level,
as it might be possible that the path used to send the first packet
failed, but some other path can be used. Also if you send request over
TCP and get TCP reset back, it might be useful to try to recreate the
TCP connection and then retransmit. Some cases NAT boxes simply forget
about the TCP session (reboots) and you only get indication that this
TCP session is reset after you try to send data over the connection.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jun 2012 13:34:09 +0300

Yoav Nir writes:
> 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.

I do not understand your statement above. Especially what does "server
has to wait for an ACK to continue"? If there is space in window there
is no need to wait for ACKs, you can just send next packet to the
other end immediately when you have it.

In normal case I would expect the flow being something like

   UDP: IKE_SA_INIT --->
		    <--- UDP: IKE_SA_INIT response
   TCP Syn --->
		    <--- TCP Syn, ACK
   TCP Ack --->
   TCP IKE_AUTH ---> (note there is no need to wait anything here this
		      packet can go immediately after the TCP Ack, if
		      I remember right the data could even be in the
		      ACK pcaket, but operating systems APIs usually
		      do not support it)

		      <--- TCP ACK (this might be delayed and combined
				    with the packet below)
		      <--- TCP IKE_AUTH response

   (IKEv2 Negotiation done)

   TCP Ack --->

I probably need to read your draft before I comment further, as it
might already be explained there. 

> 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 reason UDP port 4500 is allowed for even IKE_SA_INIT is that the
client might have prior knowledge that the other end do support NAT-T.
It might have had connection few minutes ago, that got teared down for
some reason and it wants to re-establish it, or it might have been
configured always to use port 4500. Note, that NAT_DETECTION_*_IP
packets are supposed to be included even then... 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 15 Jun 2012 14:23:12 +0300

> other end immediately when you have it.

The application (in this context that is the IKE implementation) does not need to wait, it can send everything immediately. But TCP has slow start. Depending on OS, the first flight can be either 1 or 2 segments. If your IKE_AUTH message takes more than two segments, the third segment will wait for a TCP ack, effectively adding a round-trip.

If you do the IKE_SA_INIT over TCP as well, then the ACK for the IKE_SA_INIT (usually delivered in the IKE_SA_INIT response) doubles the receive window, so the next request can be up to four segments.

I don't think this is particularly significant, but this issue has come up in proposals for TLS, where the ServerHello-Certificate-[ServerKeyExchange]-ServerHelloDone flight can be very large, and break the 2 segment limit.

Yoav