From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 58B3A81E85 for ; Thu, 19 Jan 2017 00:36:50 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E5FD4C05AA4C; Thu, 19 Jan 2017 08:36:50 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-25.phx2.redhat.com [10.3.116.25]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0J8amd1030818; Thu, 19 Jan 2017 03:36:49 -0500 To: "Wu, Jiaxin" , Gary Lin References: <20170117045232.4765-1-glin@suse.com> <20170117045232.4765-3-glin@suse.com> <895558F6EA4E3B41AC93A00D163B72741629483A@SHSMSX103.ccr.corp.intel.com> <6e2dc3db-8657-cf9d-39d9-e604d7b2f92c@redhat.com> <20170118092140.2kjvl5w5327e4pst@GaryWorkstation> <895558F6EA4E3B41AC93A00D163B727416294E59@SHSMSX103.ccr.corp.intel.com> Cc: "edk2-devel@ml01.01.org" , "Justen, Jordan L" , "Long, Qin" From: Laszlo Ersek Message-ID: Date: Thu, 19 Jan 2017 09:36:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <895558F6EA4E3B41AC93A00D163B727416294E59@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 19 Jan 2017 08:36:50 +0000 (UTC) Subject: Re: [PATCH 2/3] OvmfPkg: correct the set of modules included for the IPv6 stack X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 08:36:50 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 01/19/17 04:09, Wu, Jiaxin wrote: >>>> Laszlo, >>>> >>>> I also agree with (a). >>>> >>>> For IpSec, we can do the below update later: >>>> >>>> 1), Include it under NETWORK_IP6_ENABLE directly but with the limit usage >> for IPv4. >>>> >>>> Or >>>> >>>> 2), Define new flag "IPSEC_ENABLE" for both of them. >>>> >>>> I prefer 2). >>> >>> Hmmm, I'm not so sure. Personally I've never used either IpSec or IPv6. >>> >>> If I understand correctly: >>> >>> - IPSEC_ENABLE=TRUE && NETWORK_IP6_ENABLE=FALSE would mean >>> IPv4 only + IpSec. While this may be a theoretically useful >>> combination, I wonder how often people would actually want this. >>> >>> - IPSEC_ENABLE=TRUE && NETWORK_IP6_ENABLE=TRUE -- this is a valid >>> combination, especially for a full-fledged build of OVMF >>> >>> - IPSEC_ENABLE=FALSE && NETWORK_IP6_ENABLE=TRUE -- as far as I >>> understand, this is actually an invalid (incomplete) build for the >>> IPv6 stack. >>> >>> - IPSEC_ENABLE=FALSE && NETWORK_IP6_ENABLE=FALSE -- the most >> common >>> build, gives you just IPv4 >>> >>> Based on the above, I think I prefer (1); that is, I believe we >>> shouldn't introduce IPSEC_ENABLE. For IPv6, IpSec is apparently >>> mandatory, so turning it off makes no sense. And in an IPv4-only build >>> of OVMF, I see quite limited usefulness for IpSec; turning it on with a >>> dedicated flag looks overkill, at least for a virtual machine firmware. >>> >>> Jordan, Gary, what do you think? >> >> IpSec is optional for me. The Ip6 driver detects the protocol dynamically, >> so we don't really need IpSec for IPv6. (PXEv6 and HTTPBoot v6 works for >> me with the current settings.) Besides, it seems we didn't provide a proper >> user interface (e.g. config UI or a shell command) to setup IpSec. The user >> probably has to find a tool, e.g. NetworkPkg/Application/IpsecConfig, to >> config it properly. So I feel it's not mandatory and would prefer 2). > > I did quick investigation for the IpSec deployment requirement for IPv4 and IPv6. > > Now, the goal of the IpSec is to provide the security service for both the IPv4 and IPv6 environments. > > Previously, IPsec implementation was mandatory requirement for IPv6. But in RFC 6434 (IPv6 Node Requirements), the document updates that recommendation by making support of the IPsec Architecture a *SHOULD* for all IPv6 nodes. That means it has been made optional for IPv6 since RFC 6434. Detailed see RFC 6434 section 11: > > " > Previously, IPv6 mandated implementation of IPsec and recommended the > key management approach of IKE. This document updates that > recommendation by making support of the IPsec Architecture [RFC4301] > a SHOULD for all IPv6 nodes. > " > > " > This document recognizes that there exists a range of device types > and environments where approaches to security other than IPsec can be > justified. For example, special-purpose devices may support only a > very limited number or type of applications, and an application- > specific security approach may be sufficient for limited management > or configuration capabilities. Alternatively, some devices may run > on extremely constrained hardware (e.g., sensors) where the full > IPsec Architecture is not justified. > " > > So, according above information, IPSEC_ENABLE should be fine to > include the feature or just keep the current until it truly > required:). Thanks a lot for tracking this down! Given that we're apparently unaware of any actual need for IpSec in OVMF, I suggest that we postpone it. And, when the need arises, we should do -D IPSEC_ENABLE (affecting both IPv4 and IPv6); I understand now that that will be the right thing to do. Cheers! Laszlo