aside: IPsec tunnels for carrying options/headers end-to-end

RJ Atkinson <rja.lists@gmail.com> Mon, 10 February 2014 20:17 UTC

From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: aside: IPsec tunnels for carrying options/headers end-to-end
Date: Mon, 10 Feb 2014 15:17:39 -0500
Message-Id: <D62E725B-1685-4609-84FD-0683B125D654@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
Precedence: list

On 2/10/14, Fernando Gont wrote, in part:
>  On 02/07/2014 09:06 PM, Mark ZZZ Smith wrote:
>  > End-to-end crypto might the backup plan.
> 
> Depends on what you mean by end-to-end crypto, and in what context.
> 
> SSL/TLS for say, web servers and mailservers, fine.
> 
> IPsec for the general case...mmm.. unlikely.
> 
> Is there any plan for solving the authentication of nodes?

The IETF DANE WG.  Their initial focus seems to be TLS,
but the same approach ought to work fine for IPsec
(and was always what I expected to happen, although
I thought it would have happened sooner. :-)

> Is everyone expected to get/buy a certificate?

No.   See above.  Folks are expected to have DNS,
which is already an expectation.

To Mark's point at the very top, tunnelling is indeed
one method to permit options/headers/new-protocols
to be deployed, but it assumes cooperating endpoints
who can encapsulate/decapsulate as appropriate.  

Yours,

Ran

aside: IPsec tunnels for carrying options/headers… RJ Atkinson