Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 07 June 2017 22:13 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AA112EB2B for <dhcwg@ietfa.amsl.com>; Wed, 7 Jun 2017 15:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu_jr-JJj0QX for <dhcwg@ietfa.amsl.com>; Wed, 7 Jun 2017 15:13:02 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB5E1270A7 for <dhcwg@ietf.org>; Wed, 7 Jun 2017 15:13:02 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v57LwB8K072713; Wed, 7 Jun 2017 23:58:11 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201706072158.v57LwB8K072713@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Ted Lemon <mellon@fugue.com>
cc: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, dhcwg <dhcwg@ietf.org>
In-reply-to: Your message of Wed, 07 Jun 2017 17:19:15 -0400. <BF3C84F7-69CD-480E-A839-54B5F981C259@fugue.com>
Date: Wed, 07 Jun 2017 23:58:11 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ij0kMYP9r8qUFsxlAX3eb5KUbeg>
Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2017 22:13:04 -0000

 In your previous mail you wrote:

>  The point of this joke is that actually I don't have any problem with =
>  encryption being done in the kernel, but I don't see how to make it work =
>  for this use case, because we don't have end-to-end communication with =
>  the server.

=> the theory of IPsec operations is very simple: you have two databases:
 - the Security Association DataBase
 - the Security Policy Database.
When you have a packet you see in the SPD what to do. If the policy is
to do some IPsec processing on the packet you look for the parameters
in the SADB and if there is no SA when there should be one then you ask
IKE to create one (in fact a pair).
So the configuration consists into populating the SPD (e.g. by setkey)
and to say to IKE what to do (define peers, credentials, a zillion of
options).

Regards

Francis.Dupont@fdupont.fr