Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

From: Daniel Migault <[email-masked]>
Date: Fri, 6 May 2016 16:39:27 -0400

Hi,

I have read the draft. TCP encapsulation is a topic that matters, and I
would like different vendors to implement a standard version of this. I
think the draft is in good shape to be adopted and discussed as a WG
document. I am volunteering to continue reviewing the draft and contribute
to the text once adopted.

Please find here my comments. None of them are controversial and they
should not prevent the adoption of the draft.

BR,
Daniel

abstract:

s/IPSec/IPsec

"This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP."

This seems to indicates that the method should only be used with IKEv2
which contradicts the title. Thus I would mention. When used with IKE,
this method...

We have to chose IKE or IKEv2. If IKE is chosen, then may specify that
IKE means IKEv2. I have seen IKEV@ in appendix A

section 2:
"""
The configuration defined on each peer should include the following
parameters:

   o  One or more TCP ports on which the responder will listen for
      incoming connections.  Note that the initiator may initiate TCP
      connections to the responder from any local port.

This document leaves the selection of TCP ports up to
   implementations.  It's suggested to use TCP port 4500, which is
   allocated for IPSec NAT Traversal.
"""
I think that for interoperability, we should define a port at the
IANA. If that port is 4500 we should detail why an how the two
encapsulation method works. Are there any disadvantages of using an
allocated port? One reason reason I suspect port agility may be needed
is NAT. If so that should be clearly documented.

"""
Optionally, an extra framing protocol to use on top of TCP to
      further encapsulate the stream of IKEv2 and IPSec packets.  See
      Appendix A for a detailed discussion.
"""

If I am correct the extra framing is TLS. If so I think it woudl be
clearer to mention extra framing such as TLS.

section 3.2
I think that we shoudl specify that ESP SPI MUST be non zero to avoid
the confusion between ESP SPI and Non-ESP marker.

section 4:

My understanding is that the stream prefix is needed if because tcp
does not have a mechanism that indicates the content of the streams.
An IANA allocated port could could be such indicaton. In that case,
would we need this prefix ?

section 5:

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

If I understand this correctly it means:
    - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
encapsulation.
    - b) an IKEv2 connection OR an ESP session cannot use TCP
encapsulation or UDP or no encapsulation.

I propose to have something similar to this:

When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
encapsulated with TCP.
In fact a network may have different firewall rules for IKEv2 and ESP
traffic. IKEv2 is an application identified with specific ports
whereas ESP packets do not have ports.If the IKEv2 traffic and ESP
were not using the same encapsulation method (non encapsulation, UDP
encapsulation or TCP encapsulation), then IKEv2 would not be able to
proceed to reachability tests of the ESP path, as IKEv2 and ESP would
use different paths. In addition, IKEv2 would be expected to negotiate
the ESP encapsulation between the peers.

With UDP and TCP encapsulation, IKEv2 and ESP packet use the same port
and transport protocol, which means that IKEv2 proceeds to the
connectivity tests and set the tunnel. In the case non-encapsulated
IKEv2 are not blocked, but that ESP packets are blocked, it is the
responsibility of the IKEv2 client to DELETE the IKE_SA on both peers
and than renegotiate the IKEv2 exchange using UDP and then TCP
encapsulation.

If IKEv2 peers are using TCP encapsulation, and both peer support UDP
encapsulation as well as MOBIKE, then it can switch from TCP to UDP
encapsulation for both IKEv2 and ESP traffic by using MOBIKE. The peer
can advertise their respective support with MOBIKE_SUPPORTED and
NAT_DETECTION_*_IP Notify Payloads. When one of the IKEv2 peer
decides to switch from TCP to UDP encapsulation, all IKEv2 and ESP
traffic is switched from TCP to UDP. Note that the other way around is
not possible as IKEv2 does not advertise its support for TCP encapsulation.

[note that using NAT_DETECTION_*_IP as an UDP_ENCAPSULATION_SUPPORTED  only
works when not encapsulated with UDP/TCP]

section 6:

Because of this text, I think it would be good to have a TCP
encapsulation and TCP decapsulation sections that describes TCP and

IPsec interactions.

"""
 The original initiator (that is, the endpoint that initiated the TCP
connection and sent the first IKE_SA_INIT message) is responsible for
reestablishing the TCP connection if it is torn down for any
unexpected reason.  Since new TCP connections may use different ports
due to NAT mappings or local port allocations changing, the responder
MUST allow packets for existing SAs to be received from new source
ports.
"""

Section 7:

This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may
currently seen as a UDP_ENCAPSULATION_SUPPORTED notify payload to. This
won't be the case anymore with IKEv2. Maybe we should provide more text on
this.

On Wed, Apr 27, 2016 at 2:38 PM, Tommy Pauly <[email-masked]> wrote:

> Hello,
>
> Based on our discussions at IETF 95 and on the list, I’ve posted a new
> revision of the TCP Encapsulation draft (
> draft-pauly-ipsecme-tcp-encaps-04):
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-04
>
> The highlights of the new version are:
> - Moved all references to TLS to an appendix, so it is not part of the
> standard directly (Valery, I think this should address your concerns)
> - Changed the length field to 16 bits to match 3GPP implementations
> (thanks to Tero for this suggestion)
> - Added a magic value to put once at the beginning of any TCP stream to
> indicate that it is being used for IKEv2, to allow differentiation from
> other streams if we re-use well-known ports (thanks to Yoav for this
> suggestions)
>
> I believe this addresses all of the concerns brought up previously, so I’d
> like to see if we could get adoption from the working group to move this
> draft forward. Please reply with your thoughts on this!
>
> Thanks,
> Tommy Pauly
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 May 2016 19:48:51 -0400 (EDT)

> s/IPSec/IPsec

If Tommy could also fix that auto-correct for my iphone, that would be
great too :)

> which contradicts the title. Thus I would mention. When used with IKE,

This has happened in this group a few times now in different documents.
People want to say IKEv2 to exclude IKE, but we should really say IKE
so these documents don't look weird when/if we get IKEv3.

> is NAT. If so that should be clearly documented.

We should not define a port unless it is 443, which we kind of cannot.

> the confusion between ESP SPI and Non-ESP marker. 

First I thought this was not needed, because RFC-3948 would define that,
but it does look confusing because it is mentioned in the section titled
"UDP-Encapsulated ESP Header format":

https://tools.ietf.org/html/rfc3948#section-2.1

So the draft should probably include something simiar to that section.

> would we need this prefix ?

We all know SSL VPNs exist because some networks block (4)500 on
purpose.

> encapsulated or not.  A mix of TCP and UDP encapsulation for a single

Note: what it you suddenly notice you can go back to UDP. Wouldn't you
have a mix while you migrate all the TCP-ESP to UDP-ESP?

> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be

It might be best to avoid making any statement on this. For example
libreswan introduced a force-encaps= option to work around Amazon not
routing ESP packets. If you mention anything for IKE vs ESP you might
add limitations that might cause problems later on. While I think we
should have SHOULD language on trying to move TCP sessions to UDP, I
wouldn't go as far to forbid certain combinations.

> This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may currently seen as a
> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case anymore with IKEv2. Maybe we
> should provide more text on this.

well, on UDP it is obvious the port can change and you can just update
the port on the receiver based on the last received udp port. with tcp
clearly you know when it is being shut down. I'm not sure if the
receiver should keep such an orphaned IKE SA while waiting for another
TCP session to come in though. It might make sense of there is a DOS
attack using spoofed RST packets, but the attacker can't be stopped
anyway.

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 16 May 2016 13:15:16 -0700

Hi Paul, Daniel,

Thanks for the comments! Responses inline.

I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is satisfactory to resolve those issues.

Thanks,
Tommy

> On May 6, 2016, at 4:48 PM, Paul Wouters <[email-masked]> wrote:
> 

Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks makes most sense is fine with me.

> We should not define a port unless it is 443, which we kind of cannot.

Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do generic TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the future, so we specifically leave this port option as a configuration property.

We also specifically don't mention that the extra framing protocol will likely be TLS until we are in the appendix, due to comments from the group on inclusion of direct references to TLS in the standard.

> So the draft should probably include something simiar to that section.

We can add a mention that the ESP SPI must be non-zero to match the other RFCs.

> We all know SSL VPNs exist because some networks block (4)500 on

That's correct.

> have a mix while you migrate all the TCP-ESP to UDP-ESP?

We can make this section more clear. The main point it was trying to avoid was a technique used in previous drafts or protocols that used TCP for IKE in which only long packets would use TCP, and other would use UDP. The idea here is that all the IKE and ESP packets should share the same stream, and only switch potentially to use UDP if they do a MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break in message IDs.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 16 May 2016 16:52:03 -0400

Hi Tommy,

Thank you very much for the response. They are addressing all my concerns.

BR,
Daniel

On Mon, May 16, 2016 at 4:15 PM, Tommy Pauly <[email-masked]> wrote:

> I'd like to also hear feedback from people who brought up issues last time
> if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP
> spec conformity, and Yoav regarding the magic value) to validate that this
> draft is satisfactory to resolve those issues.
>
> Thanks,
> Tommy
>
>
> Agreed. The most common port in practice will end up being 443; we do have
> 4500 allocated if people want to do generic TCP testing, but to get through
> NATs and firewalls, we need to often use 443 today. This may change in the
> future, so we specifically leave this port option as a configuration
> property.
>
> We also specifically don't mention that the extra framing protocol will
> likely be TLS until we are in the appendix, due to comments from the group
> on inclusion of direct references to TLS in the standard.
>
> >
> We can make this section more clear. The main point it was trying to avoid
> was a technique used in previous drafts or protocols that used TCP for IKE
> in which only long packets would use TCP, and other would use UDP. The idea
> here is that all the IKE and ESP packets should share the same stream, and
> only switch potentially to use UDP if they do a MOBIKE switch. In that
> case, there could be packets on the wire that are mixed, but there would be
> a discrete break in message IDs.
>
> >

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 17 May 2016 09:53:20 +0300

Hi Tommy,

sorry for late reply. I'm mostly OK with the last version of the draft.

Few comments. It is a bit unclear how Stream Prefix is intended
to be used with TLS. Is it insterted at the beginning of the TLS data stream?

Then, I think some text should be added describing a situation
when the original responder having a valid (from its point of view)
TCP session receives a request from original initiator for a new
TCP session. This may happen if original initiator looses TCP
state for some reason (RST from an attacker, temporary network failure etc.).
In this case the responder will have two TCP sessions associated with
the IKE SA. Clearly, the new one should be used for further communications,
but only after it is proven to be authentic (some protected message is received
over it). But what the responder should do with the old TCP session?
Keep it? Send FIN? Send RST? Just discard?

Regards,
Valery.

> I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of 
> TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is 
> satisfactory to resolve those issues.
>
> Thanks,
> Tommy
>
>
> Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do generic 
> TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the future, so 
> we specifically leave this port option as a configuration property.
>
> We also specifically don't mention that the extra framing protocol will likely be TLS until we are in the appendix, 
> due to comments from the group on inclusion of direct references to TLS in the standard.
>
>>
> We can make this section more clear. The main point it was trying to avoid was a technique used in previous drafts or 
> protocols that used TCP for IKE in which only long packets would use TCP, and other would use UDP. The idea here is 
> that all the IKE and ESP packets should share the same stream, and only switch potentially to use UDP if they do a 
> MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break in 
> message IDs.
>
>>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 May 2016 11:11:29 -0700

Hi Valery,

Thanks for your reply! I think these are good points that we can clarify in future versions, although we can address these once it is a working group document. Responses inline.

Best,
Tommy

> On May 16, 2016, at 11:53 PM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Tommy,
> 

The intention is that the prefix is used at the beginning of the stream even when TLS is being used (specifically, inside the encrypted TLS stream). Since the point of the prefix is to identify which specific protocol is being used, to differentiate from other TLS or VPN traffic, it is relevant to use it even when going over TLS port 443 in case the server being used also supports other VPN protocols over the same port using TLS. This is one of the points Yoav brought up.

> Keep it? Send FIN? Send RST? Just discard?

In general, the approach of the draft is to clearly separate the TCP state from the IKE session state. If you look at Section 6, it specifically allows for multiple TCP connections between two peers even if there is only one IKE SA between them. If one of them becomes redundant (because the other peer opened up a new TCP flow for some reason), it would make sense to close the other in a usual way. I think this can be left to the implementation, but either a FIN or RST would be appropriate rather than a discard. We can add that to future versions.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 23 May 2016 09:39:13 +0300

Hi Tommy,

thank you for clarifications. One more point. The draft is silent about
what the responder is supposed to do with the stream prefix.
Should it check it? In this case what should it do if the prefix is
different from "IKEv2"? Discard the TCP session? Or should
it ignore the prefix completely? In this case how many bytes
should it skip from the beginning of the stream - exactly 5?

Regards,
Valery.

----- Original Message ----- 
From: "Tommy Pauly" <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; "Yoav Nir" <[email-masked]>
Cc: "Paul Wouters" <[email-masked]>; "Daniel Migault" <[email-masked]>; "IPsecME WG" <[email-masked]>
Sent: Friday, May 20, 2016 9:11 PM
Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

Hi Valery,

Thanks for your reply! I think these are good points that we can clarify in future versions, although we can address 
these once it is a working group document. Responses inline.

Best,
Tommy

> to be used with TLS. Is it insterted at the beginning of the TLS data stream?

The intention is that the prefix is used at the beginning of the stream even when TLS is being used (specifically, 
inside the encrypted TLS stream). Since the point of the prefix is to identify which specific protocol is being used, to 
differentiate from other TLS or VPN traffic, it is relevant to use it even when going over TLS port 443 in case the 
server being used also supports other VPN protocols over the same port using TLS. This is one of the points Yoav brought 
up.

> Keep it? Send FIN? Send RST? Just discard?

In general, the approach of the draft is to clearly separate the TCP state from the IKE session state. If you look at 
Section 6, it specifically allows for multiple TCP connections between two peers even if there is only one IKE SA 
between them. If one of them becomes redundant (because the other peer opened up a new TCP flow for some reason), it 
would make sense to close the other in a usual way. I think this can be left to the implementation, but either a FIN or 
RST would be appropriate rather than a discard. We can add that to future versions.

>> Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do 
>> generic TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the 
>> future, so we specifically leave this port option as a configuration property.
>>
>> MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break 
>> in message IDs.
>>
>>>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 May 2016 15:57:32 -0400 (EDT)

> should it skip from the beginning of the stream - exactly 5?

That might not work well if we get IKEv2.1

Actually, I'd argue it should be a unique identifier but not contain a
verion number of the IKE protocol at all.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 23 May 2016 23:22:25 +0300

Hi Paul,

> That might not work well if we get IKEv2.1

That was the point. But please see below.

> verion number of the IKE protocol at all.

Not sure. Actually, this prefix is meaningful only for middleboxes,
so it is not linked with any particular IKE version and can be an arbitrary string,
that is different from TLS ClienHello and other existing prefixes Yoav mentioned.

On the other hand the prefix can be used as an indication of teh encapsulation
format. For example, in the unlikely event we later want to change length field size 
to 4 bytes, we can change the prefix to distinguish between old and new formats. 
In this case the responder should discard the TCP session if 
the prefix doesn't match an expected value, since it means
that the encapsulation format is different from what it understands.

But my point was that in any case - whether the prefix should be checked or ignored
by responder, - the behaviour must be clearly described in the draft.

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 May 2016 00:13:09 +0300

> On 23 May 2016, at 9:39 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Tommy,
> 

This prefix is used for de-multiplexing. For example, if we listen for IKE on TCP port 443 and also have an HTTPS server there (perhaps as an administrative interface).

Assuming we don’t encrypt IKE in TLS, then we need the prefix to differentiate between IKE and TLS. Currently, there’s no way a valid ClientHello begins with “IKEv2”, and hopefully that will not change with TLS 1.3 or any future version. If we do encapsulate IKEv2 in TLS, we still need to differentiate IKEv2 from HTTP. And again, there is no HTTP method called “IKEv2”.

So I think the parsing and consuming of this prefix is not part of the IKE, but part of the de-multiplexer. If the port has several services, then not having the “IKEv2” prefix means that the stream should be processed by some other processor. If IKEv2 is the only service on that particular port, then we need a very simple de-multiplexer: if the first 5 bytes are “IKEv2” then consume them and forward the rest to the IKEv2 service. If it’s anything else, close the connection.

Yoav

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Mon, 23 May 2016 22:55:14 +0000

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
> Sent: Monday, May 23, 2016 2:13 PM
> To: Valery Smyslov
> Cc: IPsecME WG; Daniel Migault; Paul Wouters; Tommy Pauly
> > thank you for clarifications. One more point. The draft is silent
> > about what the responder is supposed to do with the stream prefix.
> > different from "IKEv2"? Discard the TCP session? Or should it ignore
> > the prefix completely? In this case how many bytes should it skip from
> > the beginning of the stream - exactly 5?
> 
> This prefix is used for de-multiplexing. For example, if we listen for IKE on TCP
> port 443 and also have an HTTPS server there (perhaps as an administrative
> interface).
> 
> Assuming we don’t encrypt IKE in TLS, 

[HJ] this part is a bit confusing for me, if we don't use TLS level encryption, then what's the benefit of using TLS over plain TCP encapsulation?  In fact, I don't know why TLS encapsulation is needed at all, it is said in the draft that " The security of the IKEv2 session is entirely derived from the IKVEv2 negotiation and key establishment", so encryption/authentication of TLS level are not needed at all. 

> then we need the prefix to differentiate
> between IKE and TLS. Currently, there’s no way a valid ClientHello begins with
> “IKEv2”, and hopefully that will not change with TLS 1.3 or any future version. If
> we do encapsulate IKEv2 in TLS, we still need to differentiate IKEv2 from HTTP.
> And again, there is no HTTP method called “IKEv2”.

> 
> So I think the parsing and consuming of this prefix is not part of the IKE, but
> part of the de-multiplexer. If the port has several services, then not having the
> “IKEv2” prefix means that the stream should be processed by some other
> processor. If IKEv2 is the only service on that particular port, then we need a
> very simple de-multiplexer: if the first 5 bytes are “IKEv2” then consume them
> and forward the rest to the IKEv2 service. If it’s anything else, close the
> connection.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 May 2016 19:14:45 -0400 (EDT)

> [HJ] this part is a bit confusing for me, if we don't use TLS level encryption, then what's the benefit of using TLS over plain TCP encapsulation?  In fact, I don't know why TLS encapsulation is ne…

To get past middleware boxes that tend to not touch "real" TLS traffic
but mangle anything else.

Paul

---

From: Samy Touati <[email-masked]>
Date: Mon, 23 May 2016 23:16:13 +0000

Hi 

We use TLS to facilitate traversal of IPSEC traffic through http proxies.
The client would use the HTTP Connect command to connect to the proxy.
TLS is only used for this purpose and not for securing the IPSec link.

Thanks.
Samy.

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Mon, 23 May 2016 23:23:14 +0000

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Monday, May 23, 2016 4:15 PM
 
> To get past middleware boxes that tend to not touch "real" TLS traffic but
> mangle anything else.

[HJ]  so there is middle box that will only allow TLS traffic (and dropping all plain tcp traffic)? that sounds pretty extreme, but even in such case, nothing prevent such middle box to have a new rule to drop TLS encapsulated IPsec traffic if TLS level encryption is not used.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 May 2016 19:25:49 -0400 (EDT)

> [HJ]  so there is middle box that will only allow TLS traffic (and dropping all plain tcp traffic)? that sounds pretty extreme, but even in such case, nothing prevent such middle box to have a new…

Correct. There will always be that battle of deep packet inspection and
proxies versus people who want to be protected from them.

Paul

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Mon, 23 May 2016 23:42:16 +0000

> Sent: Monday, May 23, 2016 4:26 PM
> To: Hu, Jun (Nokia - US)
> Cc: IPsecME WG
> >> To get past middleware boxes that tend to not touch "real" TLS
> >> traffic but mangle anything else.
> >
> > [HJ]  so there is middle box that will only allow TLS traffic (and dropping all
> plain tcp traffic)? that sounds pretty extreme, but even in such case, nothing
> prevent such middle box to have a new rule to drop TLS encapsulated IPsec
> traffic if TLS level encryption is not used.
> 
> Correct. There will always be that battle of deep packet inspection and proxies
> versus people who want to be protected from them.

[HJ] ok, so my takeaway is TLS encapsulation without encryption is useful for HTTP proxy traversal and some middle box only allows TLS traffic; however the draft doesn't prevent TLS encapsulation with encryption, which might be useful to get around some really strict middle box which inspects TLS payload.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 23 May 2016 17:27:31 -0700

Hi Jun,

You are correct—the draft specifically allows for the possibility of doing encrypted TLS as a tunnel for the purposes of getting through some middleboxes. There are some that will validate that traffic is either HTTP or TLS, and since IKE traffic will not look like HTTP, one could use TLS instead.

Thanks,
Tommy

> On May 23, 2016, at 4:42 PM, Hu, Jun (Nokia - US) <[email-masked]> wrote:
>

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Tue, 24 May 2016 02:38:15 +0000

Thanks all for the clarification. 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, May 23, 2016 5:28 PM
> To: Hu, Jun (Nokia - US)
> Cc: Paul Wouters; IPsecME WG
> You are correct—the draft specifically allows for the possibility of doing
> encrypted TLS as a tunnel for the purposes of getting through some
> middleboxes. There are some that will validate that traffic is either HTTP or TLS,
> and since IKE traffic will not look like HTTP, one could use TLS instead.
> 
> Thanks,
> Tommy
> 
> >> plain tcp traffic)? that sounds pretty extreme, but even in such
> >> case, nothing prevent such middle box to have a new rule to drop TLS
> >> encapsulated IPsec traffic if TLS level encryption is not used.
> >>
> >> Correct. There will always be that battle of deep packet inspection
> >> and proxies versus people who want to be protected from them.
> >
> > [HJ] ok, so my takeaway is TLS encapsulation without encryption is useful for
> HTTP proxy traversal and some middle box only allows TLS traffic; however the
> draft doesn't prevent TLS encapsulation with encryption, which might be useful
> to get around some really strict middle box which inspects TLS payload.
> >