From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 B103B81E69 for ; Wed, 18 Jan 2017 19:09:47 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 18 Jan 2017 19:09:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,251,1477983600"; d="scan'208";a="32489713" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 18 Jan 2017 19:09:47 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Jan 2017 19:09:47 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Jan 2017 19:09:46 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by shsmsx102.ccr.corp.intel.com ([169.254.2.88]) with mapi id 14.03.0248.002; Thu, 19 Jan 2017 11:09:43 +0800 From: "Wu, Jiaxin" To: Gary Lin , Laszlo Ersek CC: "edk2-devel@ml01.01.org" , "Justen, Jordan L" , "Long, Qin" Thread-Topic: [edk2] [PATCH 2/3] OvmfPkg: correct the set of modules included for the IPv6 stack Thread-Index: AQHScH2XV043vXIcYkatzDUAWoZQN6E730+AgAGBoWD///6VAIAAEfAAgAGsA5A= Date: Thu, 19 Jan 2017 03:09:42 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B727416294E59@SHSMSX103.ccr.corp.intel.com> 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> In-Reply-To: <20170118092140.2kjvl5w5327e4pst@GaryWorkstation> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzMxZGZiYzYtZTI2Ny00MTE1LTliZWQtN2U3Y2JiNDhkMGViIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjlHUXRMRDRxVnRBRDJNT1IyZFRcL3c3XC9yQW1wQlpWXC9RdjRtSkZ6cHhRNWc9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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 03:09:47 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > > 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 u= sage > 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=3DTRUE && NETWORK_IP6_ENABLE=3DFALSE would mean > > IPv4 only + IpSec. While this may be a theoretically useful > > combination, I wonder how often people would actually want this. > > > > - IPSEC_ENABLE=3DTRUE && NETWORK_IP6_ENABLE=3DTRUE -- this is a valid > > combination, especially for a full-fledged build of OVMF > > > > - IPSEC_ENABLE=3DFALSE && NETWORK_IP6_ENABLE=3DTRUE -- as far as I > > understand, this is actually an invalid (incomplete) build for the > > IPv6 stack. > > > > - IPSEC_ENABLE=3DFALSE && NETWORK_IP6_ENABLE=3DFALSE -- 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? >=20 > 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 prop= er > user interface (e.g. config UI or a shell command) to setup IpSec. The us= er > 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.=20 Previously, IPsec implementation was mandatory requirement for IPv6. But i= n RFC 6434 (IPv6 Node Requirements), the document updates that recommendat= ion by making support of the IPsec Architecture a *SHOULD* for all IPv6 nod= es. 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, Jiaxin >=20 > Thanks, >=20 > Gary Lin >=20 > > > > Thanks! > > Laszlo > > > > > > > > Thanks, > > > Jiaxin > > >