From owner-freebsd-net@freebsd.org Mon Mar 13 14:53:13 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADBD6D0A306 for ; Mon, 13 Mar 2017 14:53:13 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 422CC1753 for ; Mon, 13 Mar 2017 14:53:13 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id t189so41975865wmt.1 for ; Mon, 13 Mar 2017 07:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=ZiuboS7ENANxv56kNAq6sOsrXh+kWX6lUtHJ9tmT2m4=; b=jICI87ehW2PQTZorLk0jHPGC/WO5MJ4NMyY+j0VkfomqIvST3xsOVeZ7rVN37L89GM Wg6sqOX32kjH6xpUrXjooVtqc1Ub8rmO3OivSzS5byBOds4R9v2HQWEWGu4zKTf9+Ayy 6KC8h51GjgGRmvuxPy55wOHn59nJ4ROmnN/VJeMDgF3nKZSzIzVKNuuZvw0YXTPHn42o ARO3WfZKzVCojcWobH60XptXZavxS36vVlhHKcQf/5YmrS+CUSrVL1BdfKg+0w8CH1up 5+hfXUsKYzMtv3TAnSgEcLtH4eZMWDX7opBhinScUQzRBD3B8DZP7danKZa9dsHAqv14 0rug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=ZiuboS7ENANxv56kNAq6sOsrXh+kWX6lUtHJ9tmT2m4=; b=jvz4+/jM+gk9y/kyrd28GFKRFI/onYaUM1t1Cg5e5F3Q0t22OPZUraR+ljITFhcUGv L8D6rq+3NfIKHTLS+7DcNr4eD8PWiNpApA7zsxJ/IIXK3vZaCfIB3Q1HHnTFt5+bdpL/ b8V8qRuxlsqCK/AVHTHEUvVoyhdzDpd/+RF6zWLjvZ/n+HcQZF2t0USN2WeHhDtJAxgf AGDb7/JUnYqUDQmKNejRFk3yYjus3kZRIUc6Xsixkspco0uq6JGgnvTZFZNcuq+YNgA4 fR17qsXph1lu+8Qgn75F8U6cGy6+iRlwzmM8QtmJVQwf0Z8h/mjG8CACb/slWlQDuTFj WApQ== X-Gm-Message-State: AFeK/H2C3ry+0hUiYtfcGReULYgs7AlIBWPOsQ2bzKyvScbvp49+Z6J4Z/ZNkLOb1aFWHQ== X-Received: by 10.28.28.69 with SMTP id c66mr11324396wmc.28.1489416791811; Mon, 13 Mar 2017 07:53:11 -0700 (PDT) Received: from [192.168.2.30] ([2.190.184.71]) by smtp.googlemail.com with ESMTPSA id 53sm15277215wrt.52.2017.03.13.07.53.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 07:53:11 -0700 (PDT) Message-ID: <58C6B254.1070606@gmail.com> Date: Mon, 13 Mar 2017 18:23:08 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Andrey V. Elsukov" CC: "freebsd-net@freebsd.org" Subject: Re: ipsec with ipfw References: <58C46AE0.7050408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 14:53:13 -0000 On 2017-03-13 11:01, Andrey V. Elsukov wrote: > On 12.03.2017 00:23, Hooman Fazaeli wrote: >> Hi, >> >> As you know the ipsec/setkey provide limited syntax to define security >> policies: only a single subnet/host, protocol number and optional port >> may be used to specify traffic's source and destination. >> >> I was thinking about the idea of using ipfw as the packet selector for >> ipsec, >> much like it is used with dummeynet. Something like: >> >> ipfw add 100 ipsec 2 tcp from to >> 80,443,110,139 > What this rule should do? How do you plan implement policy lookup for > inbound packets? > For instance, Outbound packets matching the rule would go through the tunnel whose index is 2. The tunnel itself is defined using setkey. Something like: spdadd 2 esp/tunnel/1.1.1.1-2.2.2.2/require It's basically the same as spdadd without the src/dst/proto/port specification. A similar rule would be written for inbound packets. This is just to indicate the idea. Obviously, exact mechanism needs further thought & investigation (i.e., the issue of stateful vs. stateless rules). One important aspect, as slw@zxy.spb.ru pointed out, is how to deal with IKE/ISAKMP to support the mechanism, as the current protocol requires that negotiating parties to exchange & match subject-to-ipsec-traffic specification in SA payloads (which is restricted to single subnet+proto+port). I was thinking about some form of labeling (like MPLS) plus custom payload types or DOIs. Your ideas are welcome. -- Best regards Hooman Fazaeli