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

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Jul 2012 10:54:42 +0300

Hi.

I've posted version -01 of the draft, addressing some of the issues raised.

Still open issues:
 * Should we care about IKEv1?
 * Should retransmissions be forbidden, or just discouraged?
 * Should liveness checks be sent over TCP?
 * Should Initial exchange be send over TCP?

Hope we can have a fruitful discussion of this both on the list and in Vancouver.

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-01.txt
Date: July 16, 2012 10:07:17 AM GMT+03:00
To: Yoav Nir <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-nir-ipsecme-ike-tcp-01.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

Filename: draft-nir-ipsecme-ike-tcp
Revision: 01
Title: A TCP transport for the Internet Key Exchange
Creation date: 2012-07-16
WG ID: Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-01.txt
Status:          http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp
Htmlized:        http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-nir-ipsecme-ike-tcp-01

Abstract:
  This document describes using TCP for IKE messages.  This facilitates
  the transport of large messages over paths where fragments are either
  dropped, or packet loss makes them unreliable.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2012 00:47:17 +0300

>  * Should we care about IKEv1?

I do not think there is any point of making extensions to the already
obsoleted prorotol. If this is one more reason for people to move from
IKEv1 to IKEv2 even better... It would also make the document easier
to understand when we can use only terminologiy from IKEv2 document.

In the section 2.1 you describe that the TCP connection MUST be closed
immediately when all responses have been received, but that will
create VERY, VERY inefficient protocol, where the packet flow for
IKEv2 SA creation would be:

      TCP SYN ->
	  <- TCP SYN ACK
      TCP ACK ->
      TCP IKE_SA_INIT ->

      (As we know this is last request at this time we SHOULD
      half-close the session)

      TCP FIN ->
	     <- TCP IKE_SA_INIT response
	     <- TCP FIN, ACK
      TCP ACK ->

      (If we didn't half-close the TCP session before hand we MUST do
      it know, as we received last response, the IKE_AUTH is new
      separate request, and it has not yet sent so we do not have any
      outstanding request waiting for the response).

      TCP SYN ->
	  <- TCP SYN ACK
      TCP ACK ->
      TCP IKE_AUTH ->

      (As we know this is last request at this time we SHOULD
      half-close the session)

      TCP FIN ->
	     <- TCP IKE_AUTH response
	     <- TCP FIN, ACK
      TCP ACK ->

      (and now if we start CREATE_CHILD_SA exchange we need to
      recreate TCP session again!)

I think it would be much better to say that the TCP session can be
kept open as long as either end wants and it can be reused for as many
requests/responses needed. Also say that the TCP session can be closed
at any time by either end, and if it is closed and either end wants to
send response then it must recreate it.

Note, that it might not be possible for the responder to recreate the
TCP session as the initiator might be behind NAT.

In section 2.2 you say:

	   If the connection has closed before the Responder had
   had a chance to respond, it MUST NOT respond over UDP, but MUST
   instead wait for a retransmission over UDP or over another TCP
   connection.

What does the text "but MUST instead wait for a retransmission over
UDP" mean?

Also why do you forbid responder of reusing the TCP connection created
by the initiator in section 2.2?

In section 3 you say:
   
		This way the first messages use UDP, and the
   Initiator can set up the TCP connection at the same time, eliminating
   the latency penalty of using TCP.

but section 2.1 says:

				 When the three-way
   handshake completes, the Initiator MUST send the request.

Which I read to indicate that we cannot create TCP sessions before it
is needed, meaning we must immediately send the request when the
three-way handshake is completed. Now when I re-read this sentence it
does not have any timelimits there, so in theory it would be ok to
open the TCP session then keep it open for an hour, and then send
CREATE_CHILD_SA exchange over it, and then as there is no more
request to send close it after receiving the response, and then go to
beginning i.e create TCP session again waiting for the next
request.... I do not think this was what was meant to be said there.

The 3rd paragraph in the section 3 is against the section 2.1 which
says you MUST close when last response is received. You can only have
multiple requests outgoing if you have window size larger than 1,
which it not the common case. Also window size is 1 until the IKE_AUTH
is finished, thus when IKE_SA_INIT response is received that is your
last response... 

>  * Should retransmissions be forbidden, or just discouraged?

I think it is ok to forbid retransmissions on the same channel, but I
think it is mandatory to allow them on different channels, i.e. if the
first TCP session gets RST while waiting for the response from the
other end, then when new TCP connection is recreated it should resend
the request to the other end.

>  * Should liveness checks be sent over TCP?

Why should the be forbidden? Of course nobody should be sending
periodic liveness checks and recreate TCP session every 30 seconds,
but should have the mechanims described in the RFC5996 and send
liveness checks only when needed... 

>  * Should Initial exchange be send over TCP?

Again why should that be exception. 
-- 
[email-masked]