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) <jun...@nokia.com> wrote: > >> From: Paul Wouters [mailto:p...@nohats.ca] >> Sent: Monday, May 23, 2016 4:26 PM >> To: Hu, Jun (Nokia - US) >> Cc: IPsecME WG >> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for >> adoption >> >> On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote: >> >>>> 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. > > _______________________________________________ > 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
