Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 23 Mar 2016 15:03:16 +0300

Hi Tommy,

I reviewed the draft. 

Generally, the draft is in a good shape. It is well written and contains almost no
editorial issues. There are however some places where I'd like to see more
clarification, all of them are listed below.

My main problem with the draft is that it has an intended status Standards Track and 
at the same time its main goal, as specified in the Introduction, is to invent
some hack to cheat middleboxes that don't pass UDP. In this context
the proposal to use TLS (and port 443) looks especially ugly, however it is probably
the most "penetrating" solution. I understand that the world is not perfect and 
we must deal with it. However I think that the Standards Track documents must try
to model more or less ideal world (to some extent) and should not standardize hacks, 
tricks and so on.

On the other hand, TCP encapsulation per se doesn't look bad, and I think it is worth 
to have standard interoperable solution to encapsulate IKE and ESP in TCP. 
I would have had much less problems with this proposal it the draft was splitted 
into two documents - one Standards Track document describing TCP encapsulation
per se, and the other Informational document describing all the hacks and tricks 
to cheat the middleboxes that try not to pass anything except e.g. http and/or https.
And I'd like all the TLS encapsulation stuff go into that draft.

1. The requirement that direct use of ESP or UDP Encapsulation SHOULD be preferred over using TCP
    Encapsulation is present twice in the document (in Sections 1 and 2). I think it's OK to reemphasize 
    this requirement, however since both of them use RFC2119 language, they look duplicated. 
    I'd suggest to change one of the SHOULDs to lower case.

2. Section 3.

   Although a TCP stream may be able to send very long messages,
   implementations SHOULD limit message lengths to typical UDP datagram
   ESP payload lengths.  The maximum message length is used as the
   effective MTU for connections that are being encrypted using ESP, so
   the maximum message length will influence characteristics of inner
   connections, such as the TCP Maximum Segment Size (MSS).

    this text is not clear for me. IKE and ESP message length can be up
    to 64Kbytes, so how it can be used as effective MTU (that is less than or
    equal to the interface MTU, that is usually about 1500 bytes)?
    How it can influence MSS, that is usually less than or equal to 
    path MTU to avoid IP fragmentation? Am I missing something?

3. Section 4.

   Any specific IKE SA, along with its Child SAs, is either TCP
   encapsulated or not.  A mix of TCP and UDP encapsulation for a single
   SA is not allowed.  The exception to this rule is SAs that are
   migrated between addresses using MOBIKE Section 7.

    the last sentence is not accurate. As far as I understand, if IKE SA (along with 
    its Child SAs) migrated from one address to another via MOBIKE, then 
    either all these SAs (IKE & its children) use TCP encapsulation
    or all them use traditional encapsulation. So, it is not an exception
    from the rule. Well, my reading of the rule that "the mix is not allowed"
    is that by "mix" you mean situation when IKE SA uses one type
    of encapsulation while some of its children use different type.
    I'd suggest to clarify this text so that any ambiguity is eliminated.
    
4. Section 5.

   A peer must discard a partially received message due to a broken
   connection.

    s/must/MUST ?

5. Section 9.

    NAT keep-alive packets over a TCP
   encapsulated IPSec connection will be sent with a length value of 1
   byte, whose value is 0xFF Figure 2.

    Shouldn't "Figure 2" be enclosed in brackets?

6. Section 11.

    There is no subsection describing additional overhead to the size of the ESP 
    and IKE messages when using TCP encapsulation.
    This overhead may be important for some implementations. Consider some
    application (e.g. VoIP) that sends small packets, e.g. about 50 bytes in size.
    With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = 36 bytes.
    With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 (IP) = 52 bytes.
    The difference may be significant for low bandwith networks or low power consumption
    devices. With TLS the situation will be worse.

7. Section 11.3
    
    It is not clear from the text where NULL cipher should be used - in ESP
    or in TLS? If it is about TLS, then does by NULL cipher you mean
    TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS 
    (I'm not a TLS expert)? If it is about ESP NULL cipher, 
    then it contradicts to last para in Section 12... I think it should be clarified.

8. The draft is silent about ESP Sequence Numbers. I think a few words could 
    be added that while the ESP SN are unnecessary with TCP encapsulation,
    the sender still must increnet it in every sent packet.

Regards,
Valery Smyslov.

  ----- Original Message ----- 
  From: Tommy Pauly 
  To: [email-masked] 
  Sent: Tuesday, February 16, 2016 12:52 AM
  Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft

  Hello all,

  I’ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation draft. The changes include:

  - Making the use case (as a last resort if UDP is blocked) more clear in the introduction
  - Clarify connection establishment and teardown section (allowing a resumed connection to start with either IKE or ESP traffic, allowing multiple SAs on one TCP connection)
  - Adding more details about interactions with IKEv2 fragmentation, and TCP MSS and QoS markings
  - Clarifying the keep-alive/DPD section
  - A new appendix written by a new author from Cisco giving four example exchanges with TCP encapsulation of IKEv2.

  https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt
  https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03

  I believe this should address many of the comments the last draft received. Please take a look and provide your feedback! If the working group is in favor, I’d like to see if this can be adopted by the working group.

  Thanks,
  Tommy

------------------------------------------------------------------------------

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

---

From: Samy Touati <[email-masked]>
Date: Thu, 24 Mar 2016 20:04:04 +0000

Hi Valery,

I agree with you that the TLS/HTTPS should be separated from the main TCP encapsulation descriptions, but I think it must stay in the current draft and moved to an appendix section at the end of the draft. 
The purpose is to show why TCP encapsulation is required in the first place.

Thanks.

Samy.

From: IPsec <[email-masked]> on behalf of Valery Smyslov <[email-masked]>
Date: Wednesday, March 23, 2016 at 5:03 AM
To: Tommy Pauly <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft

Hi Tommy,

I reviewed the draft. 

tricks and so on.

 

2. Section 3.

3. Section 4.

4. Section 5.

    s/must/MUST ?

5. Section 9.

6. Section 11.

7. Section 11.3

Regards,

Valery Smyslov.

 

----- Original Message ----- 

From: Tommy Pauly 

To: [email-masked] 

Hello all, 

Thanks,

Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 28 Mar 2016 16:35:59 -0700

Hi Valery,

Thanks for reviewing the draft. I appreciate your time looking at it!

Regarding the status of mentioning TLS in the draft, I think it is important for the standardization aspect of running IKEv2/IPSec over a stream. While much of the reason to run IPSec over TCP/TLS is to work on networks that currently do not pass UDP traffic, there is broader benefit in describing how the IKEv2 protocol should work over a streaming protocol, and when a layer like TLS is used. The main points I want to make sure we retain in the spec are:
- If you use a streaming protocol like TCP to transport your IKEv2/IPSec traffic, use the framing described in the document to define the boundaries of IKE and ESP messages
- TCP segments and TLS frames (if used) should not affect the creation or parsing of IKEv2/IPSec messages
- Extra layers that use a security protocol, like TLS, should not be considered to provide any security or authentication assurances at the IKE level.

Since we expect deployments for the short to use TLS, I want to make sure we are clear on these details so that deployments do the right thing. I do believe there is a need for the basic elements of this in a standards document.

I do like the idea of having a follow-on draft that is not Standards Track that describes current best practices for how to use TLS and TCP encapsulation to solve current problems. Note that the current draft does not specify what port to use, etc, and only mentions that implementations may end up choosing to use port 443. This follow-on draft can go into detail about exactly what algorithms deployments end up choosing (try first over UDP with N packets, then try over TLS port 443, etc). 

Responses to specific points inline.

Thanks,
Tommy

> On Mar 23, 2016, at 5:03 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Tommy,
>  
> I reviewed the draft. 
>  

Good point, will change one of the SHOULDs to lower case in the next version.

>     path MTU to avoid IP fragmentation? Am I missing something?

The point I’m trying to get at is this: if the IPSec tunnel is represented to the client system as a virtual interface, that virtual interface will have an MTU which determines the packet size of packets within the tunnel. Depending on how IPSec over TCP is implemented on the server end, the ESP packets could eventually be sent over UDP before being decrypted (specifically, if the TCP connection is terminated at a device before the IKE endpoint). As such, we want to make sure that there are not very large (such as 64K bytes) IKE and ESP messages being sent on a tunnel that may have to then fragmenting the ESP datagrams before decrypting them.

>     I'd suggest to clarify this text so that any ambiguity is eliminated.

You are correct that there is not a case in which there is a mix between IKE and Child SAs. We will clarify this in the next version.

>    A peer must discard a partially received message due to a broken

I think we can make this a MUST.

>     Shouldn't "Figure 2" be enclosed in brackets?

Agreed, this can be in brackets.

>     devices. With TLS the situation will be worse.

This calculation does not work exactly, since TCP is a stream and the IKE/ESP payloads will not correspond directly with TLS frames or TCP segments. We can mention the overhead in general, but it is not a deterministic factor.

>     then it contradicts to last para in Section 12... I think it should be clarified.

This should refer to the TLS NULL cipher, not ESP.

>     the sender still must increnet it in every sent packet.

Okay, we can add a comment for that.

>> From: Tommy Pauly <mailto:[email-masked]>
>> To: [email-masked] <mailto:[email-masked]>
>> https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt <https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt>
>> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 <https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>