> 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, 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
