Spencer Dawkins at IETF writes: > The reason optional ports in URIs work, is that someone handed you a URI with > that port number who has some reason to believe that the port number is OK to > use with the host included in the URI. > > Is that a reasonable assumption about the way IPsec and IKE over TCP will be > deployed? That no Initiator would assume that another host is an IKE > Responder, without being configured to use that host?
I have been using following matrix to understand the IETF security protocols: +---------------------+-----------------------+------------------+ | | "Kernel" mode | Application mode | +---------------------+-----------------------+------------------+ | Pre-configuration | IPsec | Secure Shell | | required | | | +---------------------+-----------------------+------------------+ | No per host | HIP | SSL/TLS | | pre configuration | / | | | needed / | TCPINC | | | opportunistic | | | +---------------------+-----------------------+------------------+ Kernel mode means it is implemented inside the operating system kernel or libraries, and Application mode means it is part of the application level implementation. Pre-configuration required means that both ends needs to be pre-configured to accept the connection. I.e., there is no point of trying to use ssh to connect host kivinen.iki.fi unless you have account and some method of authentication token for that host. Same with IPsec, you cannot assume that other end talks IPsec and allows you to connect unless you have pre-configured both ends to support it. Even when using opportunistic IPsec this is mostly same, there is no point of even trying to use opportunistic IPsec to www.google.com, and assume it would work. It might be that at some day we are there, and we have opportunistic IPsec installed in every single host, but we are not there now, and main use of IPsec is with pre-configuration. With HIP and TCPINC you always assume that you simply connect the other end and you do not need per host configuration. The connection either works or not, and if not you fall back to TCP (TCPINC), or just fail (with HIP adding configuration might help). With TLS you can just assume that other end allows you to connect if it supports TLS at all, and this is because everybody is "pre-configured" with same trusted anchor list, but there is no need for per-host configuration. So short answer to your question is: IPsec do require pre-configuration, so if configuration says that IP address x.y.z.0 talks IPsec over TCP on port 1234, then you do that. If there is no configuration then you usually just fail, as you do not know what authentication credentials you are supposed to use. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
