Rewrite the Security Considerations section

This replacement is adapted from RFCs 8154 and 8434.

diff --git a/scsi_nvme_back_references.xml b/scsi_nvme_back_references.xml
index 446e6b1b2113bd7c51dadd08fb4648cd8c3db27b..7b0cfd7e1f5f8f49a9646987e1a5869387a7d567 100644 (file)
--- a/scsi_nvme_back_references.xml
+++ b/scsi_nvme_back_references.xml
@@ -21,6 +21,18 @@
     </front>
   </reference>
 
+  <reference  anchor='RFC5663' target='https://www.rfc-editor.org/info/rfc5663'>
+    <front>
+      <title>Parallel NFS (pNFS) Block/Volume Layout</title>
+      <author initials='D.' surname='Black' fullname='D. Black'><organization /></author>
+      <author initials='S.' surname='Fridella' fullname='S. Fridella'><organization /></author>
+      <author initials='J.' surname='Glasgow' fullname='J. Glasgow'><organization /></author>
+      <date year='2010' month='January' />
+    </front>
+    <seriesInfo name='RFC' value='5663'/>
+    <seriesInfo name='DOI' value='10.17487/RFC5663'/>
+  </reference>
+
   <reference anchor='RFC8154'>
     <front>
        <title>Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout</title>
@@ -41,6 +53,17 @@
     <seriesInfo name='DOI' value='10.17487/RFC8174'/>
   </reference>
 
+  <reference  anchor='RFC8881' target='https://www.rfc-editor.org/info/rfc8881'>
+    <front>
+      <title>Network File System (NFS) Version 4 Minor Version 1 Protocol</title>
+      <author initials='D.' surname='Noveck' fullname='D. Noveck' role='editor'><organization /></author>
+      <author initials='C.' surname='Lever' fullname='C. Lever'><organization /></author>
+      <date year='2020' month='August' />
+    </front>
+    <seriesInfo name='RFC' value='8881'/>
+    <seriesInfo name='DOI' value='10.17487/RFC8881'/>
+  </reference>
+
   <reference anchor='SPC4'>
     <front>
       <title>SCSI Primary Commands-4</title>
@@ -71,9 +94,39 @@
       <date month="May" year="2021"/>
     </front>
   </reference>
+
+  <reference anchor='NVME-PCIE'>
+    <front>
+      <title>NVMe over PCIe Transport Specification, Revision 1.0</title>
+      <author>
+         <organization>NVM Express, Inc.</organization>
+      </author>
+      <date month="May" year="2021"/>
+    </front>
+  </reference>
+
+  <reference anchor='NVME-TCP'>
+    <front>
+      <title>NVM Express TCP Transport Specification, Revision 1.0</title>
+      <author>
+         <organization>NVM Express, Inc.</organization>
+      </author>
+      <date month="May" year="2021"/>
+    </front>
+  </reference>
 </references>
 
-<references title="Non-Normative References">
+<references title="Informative References">
+  <reference  anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
+    <front>
+      <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
+      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
+      <date year='2018' month='August' />
+    </front>
+    <seriesInfo name='RFC' value='8446'/>
+    <seriesInfo name='DOI' value='10.17487/RFC8446'/>
+  </reference>
+
   <reference anchor='NVME-STLR'>
     <front>
       <title>NVM Express: SCSI Translation Reference Revision 1.5</title>

diff --git a/scsi_nvme_middle.xml b/scsi_nvme_middle.xml
index 61ff233978b24a99f815b04997eda08ff4822b93..3cd06fa56b4e8f170d65c6c3287de25de49ce723 100644 (file)
--- a/scsi_nvme_middle.xml
+++ b/scsi_nvme_middle.xml
@@ -144,23 +144,56 @@
 </section>
 
 <section anchor="sec:security" title="Security Considerations">
-  <!-- XXX this needs a complete rewrite.  Probably copying more from
-       8154, and we should also mention TLS for NVMe-TCP -->
   <t>
-   The new layout type described in the current document assumes
-   that NVMe Authentication commands are implemented in the NVMe
-   Security Protocol, as the format of the data to be transferred is
-   dependent on the Security Protocol. Authentication Receive/Response
-   commands return data corresponding to an Authentication Send command
-   as defined by the rules of the Security Protocol.
+    NFSv4 clients access NFSv4 metadata servers using the NFSv4
+    protocol. The security considerations generally described in
+    <xref target="RFC8881" /> apply to a client's interactions with
+    the metadata server. However, NFSv4 clients and servers access
+    NVMe storage devices at a lower layer than NFSv4. NFSv4 and
+    RPC security is not directly applicable to I/O to data servers
+    using NVMe.
   </t>
   <t>
-   As the layout type described in the current document supports only
-   the NVMe-over-Fabrics In-band protocol, the Authentication requirements
-   for security commands are based on the security protocol indicated
-   by the SECP field in the command and MUST NOT require authentication
-   when used for NVMe in-band authentication. When used for other
-   purposes, in-band authentication of the commands is REQUIRED.
+    pNFS with an NVMe layout can be used with NVMe transports
+    (e.g., NVMe over PCIe  <xref target="NVME-PCIE" />) that provide
+    essentially no additional security functionality. Or,
+    pNFS may be used with storage protocols such as NVMe on TCP
+    <xref target="NVME-TCP" /> that can provide significant transport
+    layer security.
+  </t>
+  <t>
+    It is the responsibility of those administering and deploying
+    pNFS with an NVMe layout to ensure that appropriate protection is
+    deployed to that protocol. When using IP-based storage protocols
+    such as NVMe on TCP, TLS <xref target="RFC8446" /> SHOULD be used
+    as outlined in <xref target="NVME-TCP" /> to protect traffic between
+    pNFS clients and NVMe storage devices.
+  </t>
+  <t>
+    Physical security is a common means for protocols not based on IP.
+    In environments where the security requirements for the storage
+    protocol cannot be met, pNFS with an NVMe layout SHOULD NOT be
+    deployed.
+  </t>
+  <t>
+    When security is available for the data server storage protocol,
+    it is generally at a different granularity and with a different
+    notion of identity than NFSv4 (e.g., NFSv4 controls user access
+    to files, and NVMe controls initiator access to volumes).  As
+    with pNFS with the block layout type <xref target="RFC5663" />,
+    the pNFS client is responsible for enforcing appropriate
+    correspondences between these security layers. In environments
+    where the security requirements are such that client-side
+    protection from access to storage outside of the layout is not
+    sufficient, pNFS with a NVMe layout SHOULD NOT be deployed.
+  </t>
+  <t>
+    As with other block-oriented pNFS layout types, the metadata
+    server MUST be able to fence off a client's access to the data
+    on an NVMe storage device.  When it revokes the layout, the
+    client's access MUST be terminated at the storage devices.  The
+    client has a subsequent opportunity to perform fresh security
+    checks and then reacquire a new layout.
   </t>
 </section>