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

[Spencer Dawkins at IETF <[e-mail]>]

Tero,

Top-posting, because I'm only saying "thank you, that's very helpful".

Spencer

On Thu, Apr 27, 2017 at 8:50 AM, Tero Kivinen <[e-mail]> wrote:

> 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]
>