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. On 5/23/16, 3:55 PM, "IPsec on behalf of Hu, Jun (Nokia - US)" <[email protected] on behalf of [email protected]> wrote: >> -----Original Message----- >> From: IPsec [mailto:[email protected]] 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 >> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for >> adoption >> >> >> > On 23 May 2016, at 9:39 AM, Valery Smyslov <[email protected]> wrote: >> > >> > 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? >> >> 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. >> > >_______________________________________________ >IPsec mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ipsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
