Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]