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

[Tommy Pauly]

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

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

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.

> 
> 4. Section 5.
>  
>A peer must discard a partially received message due to a broken
>connection.
>  
> s/must/MUST ?

I think we can make this a 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?

Agreed, this can be 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.

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.

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

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

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

Okay, we can add a comment for that.

>  
> Regards,
> Valery Smyslov.
> 
>  
>  
>  
>> - Original Message - 
>> From: Tommy Pauly <mailto:tpa...@apple.com>
>> To: ipsec@ietf.org <mailto:ipsec@ietf.org>
>> 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/id/draft-pa

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

[Samy Touati]

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 <ipsec-boun...@ietf.org> on behalf of Valery Smyslov 
<sva...@gmail.com>
Date: Wednesday, March 23, 2016 at 5:03 AM
To: Tommy Pauly <tpa...@apple.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft

 

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 b

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

[Valery Smyslov]

ds,
Valery Smyslov.




  - Original Message - 
  From: Tommy Pauly 
  To: ipsec@ietf.org 
  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
  IPsec@ietf.org
  https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] New version of IKEv2 TCP Encapsulation draft

[Tommy Pauly]

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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec