Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt

From: [email-masked]
Date: Mon, 03 Dec 2012 14:34:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : A TCP transport for the Internet Key Exchange
	Author(s)       : Yoav Nir
	Filename        : draft-ietf-ipsecme-ike-tcp-01.txt
	Pages           : 9
	Date            : 2012-12-03

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-ike-tcp-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ike-tcp-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 11 Dec 2012 16:16:18 +0400

Hi,

I'm a bit uncomfortable with the requirement that IKE peer "MUST"
advertise NAT device port if it is reachable and "MUST NOT"
if it isn't. I think, that IKE Initiator in most cases cannot
reliably determine whether it is reachable or not. For example,
even if you manually configured port forwarding on your home
network border NAT box and then configured IKE to advertise this
port, that wouldn't imply that this port is actually reachable
as your ISP may have another NAT and, as CGN become more
common, number of those nested NAT's will increase.
Even STUN might not be a good solution - it is pretty 
expensive in terms of round trips, requires the presence of STUN 
server in the same network segment as IKE Responder,  
utilizes TLS and, most important, deals with UDP only (AFAIK).

So, I think that the requirement for IKE Initiator to advertise
its support for TCP and port it thinks it is reachable at
should be listed as "SHOULD" or even "MAY". Otherwise
it sounds like a paradox - protocol requires IKE to do
or not to do some action depending on condition 
that IKE in most cases is unable to determine.

Related issues.
- in description to TCP Port field in IKE_TCP_SUPPORTED Notification 
    it is written that "If the sender is not subject to network address 
    translation, the port SHOULD be 500." Again, IKE Initiator
    cannot reliably determine whether it is behind NAT or not.
    It becomes clear only after initial request completes and
    NAT_TRAVERSAL_*_IP are processed.
- as it is quite possible that the port advertised by IKE Initiator
    in IKE_TCP_SUPPORTED Notification is actually 
    not reachable, I think it is worth to mention, that if original
    Responder after IKE SA is established wants to 
    make some request using TCP port advertised by
    original Initiator and this port appears to be not reachable,
    this Responder MUST NOT tear down IKE SA but MUST 
    instead fall back to UDP transport.

Regards,
Valery Smyslov.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Dec 2012 17:20:42 +0000

Hi Valery

Thinking it over, I kind of regret adding the port field to the TCP_SUPPORTED notification. We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap liveness checks to keep the mapping in the NAT so that requests can be initiated to the original initiator, while TCP does not. 

But your points are well taken. Leaving the advertised TCP port to configuration or auto-discovery is error prone and adds unnecessary complications to the protocol.  

I propose that:
 1. We remove the port from the Notify
 2. All connections will be done to port 500.
 3. We warn against trying to use TCP to a peer behind NAT

This loses the ability to use port forwarding to have a reachable TCP port (unless that port is 500), but I think the simplification justifies it.

Yoav

On Dec 11, 2012, at 2:16 PM, Valery Smyslov <[email-masked]> wrote:

> Even STUN might not be a good solution - it is pretty expensive in terms of round trips, requires the presence of STUN server in the same network segment as IKE Responder,  utilizes TLS and, most important, deals with UDP only (AFAIK).
> 
> or not to do some action depending on condition that IKE in most cases is unable to determine.
> 
> Related issues.
> - in description to TCP Port field in IKE_TCP_SUPPORTED Notification    it is written that "If the sender is not subject to network address    translation, the port SHOULD be 500." Again, IKE Initiator
>   in IKE_TCP_SUPPORTED Notification is actually    not reachable, I think it is worth to mention, that if original
>   Responder after IKE SA is established wants to    make some request using TCP port advertised by
>   this Responder MUST NOT tear down IKE SA but MUST    instead fall back to UDP transport.
> 
> Regards,
> Valery Smyslov.
> 
> 
> Email secured by Check Point

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2012 09:26:48 -0800

> This loses the ability to use port forwarding to have a reachable TCP port (unless that port is 500), but I think the simplification justifies it.

+1. It was getting too complex and iffy.

--Paul Hoffman

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 14 Dec 2012 09:37:06 +0400

Hi Yoav,

> Hi Valery
>
> Thinking it over, I kind of regret adding the port field to the 
> TCP_SUPPORTED notification.
> We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap 
> liveness checks
> to keep the mapping in the NAT so that requests can be initiated to the 
> original initiator, while TCP does not.
>
> But your points are well taken. Leaving the advertised TCP port to 
> configuration or auto-discovery is error
> prone and adds unnecessary complications to the protocol.
>
> I propose that:

Fully agree. And in this case please add the following to the list:
4. We remove TCP_SUPPORTED notification from Initiator's message
    (as it becomes redundant for most use cases).

> This loses the ability to use port forwarding to have a reachable TCP port 
> (unless that port is 500),
>  but I think the simplification justifies it.

Agree.

Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Dec 2012 01:03:30 -0500 (EST)

>>  3. We warn against trying to use TCP to a peer behind NAT

That's too bad, but I agree it added a lot of complexity. What is the
blocking rate for TCP 500 in the wild? And does anyone know why Cisco
moved to port 10000? A higher port does seem to have a better chance
at not being blocked.

>   (as it becomes redundant for most use cases).

So if the responder falls back to TCP, and later becomes the initiator,
should it assume TCP 500 is available, or do we go through another round
of udp fail to tcp? As implementor, I see no issue remembering TCP is
supported as longe as we have a parent SA. We don't need the TCP_SUPPORTED
notification in the original initiator for that. But firewall rules
might not be symmetric, and an outgoing TCP might work while an incoming
TCP is blocked. But I guess if UDP isn't working well, there is not much
choice left but try TCP.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 26 Dec 2012 10:11:09 +0400

Hi,

RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states:

   For session resumption, as specified in [RFC5723], the situation is
   similar.  The responder, which is necessarily the peer that has
   crashed, SHOULD send a new ticket within the protected payload of the
   IKE_SESSION_RESUME exchange.  If the Initiator is also a token maker,
   it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.

But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't
contain any protected payload - it is completely in clear and must be 
followed
by IKE_AUTH exchange. I suspect this error came from early versions
of IKE SA Resumption protocol that, as far as I remember, did contain
protected payload. But currently this para should look like:

   For session resumption, as specified in [RFC5723], the situation is
   similar.  The responder, which is necessarily the peer that has
   crashed, SHOULD send a new ticket in IKE_AUTH exchange
   that immediately followed IKE_SESSION_RESUME exchange.
   If the Initiator is also a token maker, it needs to send a QCD_TOKEN in
   the same IKE_AUTH exchange.

And one more consideration. In Section 4.1 RFC6290 states:

   o  Protocol ID (1 octet) MUST be 1, as this message is related to an
      IKE SA.

   o  SPI Size (1 octet) MUST be zero, in conformance with Section 3.10
      of [RFC5996].

I think here we have contradiction with RFC5996 (despite clamed
conformance with it). In abovementioned Section 3.10 it is written:

   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS and REKEY_SA.  If the SPI
      field is empty, this field MUST be sent as zero and MUST be
      ignored on receipt.

Let me emphasize that RFC5996 clearly requires that If the SPI
field is empty, Protocol ID field MUST be sent as zero and MUST be
ignored on receipt, but RFC6290 while requiring SPI field to be empty,
requres Protocol ID field to be non-zero. Actually, I see no value
in this requirement, as Protocol ID MUST be ignored on receipt
anyway (if SPI field is empty), so it just complicates protocol
and makes it cumbersome.

Merry Christmas,
Valery Smyslov.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Dec 2012 08:42:52 +0000

Hi

I agree with point #2. I'll leave it to some of the session resumption experts to comment on point #1.

It's a little late for "Merry Christmas", so just happy new year.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Wednesday, December 26, 2012 8:11 AM
To: [email-masked]
Subject: [IPsec] Error in RFC6290

Hi,

But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came from early versions of IKE SA Resumption protocol that, as far as I remember, did contain protected payload. But currently this para should look like:

I think here we have contradiction with RFC5996 (despite clamed conformance with it). In abovementioned Section 3.10 it is written:

Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates protocol and makes it cumbersome.

Merry Christmas,
Valery Smyslov.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Dec 2012 19:15:59 +0200

Hi Yoav, Valery,

Valery is right that the IKE_SESSION_RESUME exchange does not have a 
protected payload.

But his new text is incorrect, since the (session resumption) ticket is 
sent in IKE_SESSION_RESUME and not in the immediately following IKE_AUTH 
(he might have got it mixed with the ticket sent when *requesting* a 
ticket). So I guess we should just replace "within the protected payload 
of the IKE_SESSION_RESUME exchange" by "within the  IKE_SESSION_RESUME 
exchange".

According to http://en.wikipedia.org/wiki/Christmas#Listing, it's still 
more than a week until the Eastern Churches' Christmas. So Merry 
Christmas to some of us, and a Happy New Year to all.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 26 Dec 2012 21:58:41 +0400

Hi Yaron,

oh, you've catched one more error in this text - it mixed up terms "ticket"
(used in RFC5723 as Session Resumption ticket) and "token"
(used in RFC6290 as QCD token). I din't notice that. You are right,
that "ticket" (Session Resumption) is sent in IKE_SESSION_RESUME,
but RFC6290 talks where QCD token must be sent. And from my understanding
of the whole protocol it must not be sent in clear under any circumstances
(otherwise eavesdropper can easily tear down IKE SA), so the only logical
place for it in case of IKE SA resumption is IKE_AUTH exchange
that immediately follows IKE_SESSION_RESUME. So, I think,
correct text should be:

     For session resumption, as specified in [RFC5723], the situation is
     similar.  The responder, which is necessarily the peer that has
     crashed, SHOULD send a new QCD_TOKEN in IKE_AUTH exchange
     that immediately followes IKE_SESSION_RESUME exchange.
     If the Initiator is also a token maker, it needs to send a QCD_TOKEN in
     the same IKE_AUTH exchange.

Best wishes,
Valery.

> Hi Yoav, Valery,
>
> Valery is right that the IKE_SESSION_RESUME exchange does not have a protected payload.
>
> But his new text is incorrect, since the (session resumption) ticket is sent in IKE_SESSION_RESUME 
> and not in the immediately following IKE_AUTH (he might have got it mixed with the ticket sent 
> when *requesting* a ticket). So I guess we should just replace "within the protected payload of 
> the IKE_SESSION_RESUME exchange" by "within the  IKE_SESSION_RESUME exchange".
>
> According to http://en.wikipedia.org/wiki/Christmas#Listing, it's still more than a week until the 
> Eastern Churches' Christmas. So Merry Christmas to some of us, and a Happy New Year to all.
>
> Thanks,
> Yaron
>
>
>> But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - 
>> it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came 
>> from early versions of IKE SA Resumption protocol that, as far as I remember, did contain 
>> I think here we have contradiction with RFC5996 (despite clamed conformance with it). In 
>> abovementioned Section 3.10 it is written:
>>
>> Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field 
>> MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be 
>> empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as 
>> Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates 
>> protocol and makes it cumbersome.
>>
>> Merry Christmas,
>> Valery Smyslov.
>>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 30 Dec 2012 13:01:37 +0000

I agree.