Opportunistic Security: Some Protection Most of the Time
RFC 7435
Document | Type |
RFC
- Informational
(December 2014)
Was
draft-dukhovni-opportunistic-security
(individual in sec area)
|
|
---|---|---|---|
Author | Viktor Dukhovni | ||
Last updated | 2015-10-14 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
IESG | Responsible AD | Stephen Farrell | |
Send notices to | (None) |
RFC 7435
Network File System Version 4 T. Haynes Internet-Draft Hammerspace Intended status: Standards Track 19 March 2024 Expires: 20 September 2024 Add CB_LAYOUTRECLL_DEVICE to NFSv4.2 draft-haynes-nfsv4-recalldevice-00 Abstract The Parallel Network File System (pNFS) allows for the metadata server to use CB_LAYOUTRECALL to recall a layout from a client by file id or file system id or all. It also allows the server to use CB_NOTIFY_DEVICEID to delete a devicid. It does not provide a mechanism for the metadata server to recall all layouts that have a data file on a specific deviceid. This document presents an extension to RFC8881 to allow the server recall layouts from clients based on deviceid. Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the NFSv4 working group mailing list (nfsv4@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group information can be found at https://datatracker.ietf.org/wg/nfsv4/ about/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 September 2024. Haynes Expires 20 September 2024 [Page 1] Internet-Draft RECALL_DEVICE March 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Do we need RFC8435? . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Extension to Operation 5: CB_LAYOUTRECALL - Recall Layout from Client . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extraction of XDR . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Code Components Licensing Notice . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the Network File System version4 (NFSv4) with a Parallel NFS (pNFS) metadata server ([RFC8881]), there is no mechanism for the metadata server to recall layouts from the client for when a particular deviceid (see Section 3.3.14 of [RFC8881]) either temporarily or permanently is no longer available. One use case is when the deviceids in a layout are separated by power fault domains. Each layout might describe 3 different devices, each contained in a different power fault domain. In such a scenario, a single fault domain can have the power removed and not cause the loss of access to the data. However, client I/O will be impacted as the client still has to perform WRITEs (see Section 18.32 of [RFC8881]) to the unavailable device, send LAYOUTERRORs (see Section 15.6 of [RFC7862]) to inform the metadata server of NFS4ERR_NXIO (see Section 15.1.16.3 of [RFC8881]). Haynes Expires 20 September 2024 [Page 2] Internet-Draft RECALL_DEVICE March 2024 If the metadata sever had the means to recall layouts by deviceid, a lot of this unnecessary traffic could be eliminated. Finally, while the metadata server could recall layouts one by one, this is again unnecessary traffic and can be offloaded to the client. Besides the use case above, consider if the metadata server wants to set the NOTIFY4_DEVICEID_DELETE in the CB_NOTIFY_DEVICEID callback (see Section 20.12 of [RFC8881]). This flag cannot be set if a layout is outstanding for a deviceid. While the metadata server can revoke all such layouts, there is no way to know that the client has acknowledged that revocation and hence is still not doing I/O to other data files in the layout. The metadata server could fence those layouts as well (see Section 12.5.5 of [RFC8881]), but that can be an expensive operation. Using the process detailed in [RFC8178], the revisions in this document become an extension of NFSv4.2 [RFC7862]. They are built on top of the external data representation (XDR) [RFC4506] generated from [RFC7863]. 1.1. Do we need [RFC8435]? This section is to be removed before publishing as an RFC. The authors have tried to introduce this new functionality outside of a particular pNFS Layout Type. Does that work? 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Extension to Operation 5: CB_LAYOUTRECALL - Recall Layout from Client The original union layoutrecall4 (see Section 20.3.1 of [RFC8881]) is: Haynes Expires 20 September 2024 [Page 3] quot;Block unintelligible". The Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped. Step 4: For each block in the bundle that is an extension block that the BPA cannot process: * If the block processing control flags in that block indicate that a status report is requested in this event and if status reporting is enabled, then a bundle reception status report with reason code "Block unsupported" SHOULD be generated, destined for the bundle's report-to endpoint ID. * If the block processing control flags in that block indicate that the bundle must be deleted in this event, then the BPA MUST delete the bundle for the reason "Block unsupported"; the Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped. * If the block processing control flags in that block do *NOT* indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the BPA MUST remove this block from the bundle. * If the block processing control flags in that block neither indicate that the bundle must be deleted nor indicate that the block must be discarded, then processing continues with the next extension block that the BPA cannot process, if any; otherwise, processing proceeds from Step 5. Step 5: Processing proceeds from Step 1 of Section 5.3. 5.7. Local Bundle Delivery The steps in processing a bundle that is destined for an endpoint of which this node is a member are as follows: Step 1: If the received bundle is a fragment, the ADU Reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original ADU, processing of the fragmentary bundle whose payload has been replaced by the reassembled ADU (whether this bundle or a previously received fragment) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" MUST be added to the bundle, and all remaining steps of this procedure MUST be skipped. Step 2: Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle: * An additional implementation-specific delivery deferral procedure MAY optionally be associated with the registration. * If the registration is in the Active state, then the bundle MUST be delivered automatically as soon as it is the next bundle that is due for delivery according to the BPA's bundle delivery scheduling policy (an implementation matter). * If the registration is in the Passive state, or if delivery of the bundle fails for some implementation- specific reason, then the registration's delivery failure action MUST be taken. The delivery failure action MUST be one of the following: - Defer delivery of the bundle subject to this registration until (a) this bundle is the least recently received of all bundles currently deliverable subject to this registration and (b) either the registration is polled or the registration is in the Active state, and also perform any additional delivery deferral procedure associated with the registration, or - Abandon delivery of the bundle subject to this registration (as defined in Section 3.1). Step 3: As soon as the bundle has been delivered, if the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1 and bundle status reporting is enabled, then a bundle delivery status report SHOULD be generated, destined for the bundle's report-to endpoint ID. Note that this status report only states that the payload has been delivered to the application agent, not that the application agent has processed that payload. 5.8. Bundle Fragmentation It may at times be advantageous for BPAs to reduce the sizes of bundles in order to forward them. This might be the case, for example, if a node to which a bundle is to be forwarded is accessible only via intermittent contacts and no upcoming contact is long enough to enable the forwarding of the entire bundle. The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" -- new bundles with the same source node ID and creation timestamp as the original bundle -- whose payloads MUST be the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M. Note that fragments are bundles and therefore may themselves be fragmented, so multiple episodes of fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one "level" of fragmentation, as in IP fragmentation.) Any bundle whose primary block's bundle processing control flags do *NOT* indicate that it must not be fragmented MAY be fragmented at any time, for any purpose, at the discretion of the BPA. *NOTE*, however, that some combinations of bundle fragmentation, replication, and routing might result in unexpected traffic patterns. Fragmentation SHALL be constrained as follows: * The concatenation of the payloads of all fragments produced by fragmentation MUST always be identical to the payload of the fragmented bundle (that is, the bundle that is being fragmented). Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the fragmented bundle's payload. * The primary block of each fragment MUST differ from that of the fragmented bundle, in that the bundle processing control flags of the fragment MUST indicate that the bundle is a fragment and both fragment offset and total application data unit length must be provided. Additionally, the CRC of the primary block of the fragmented bundle, if any, MUST be replaced in each fragment by a new CRC computed for the primary block of that fragment. * The payload blocks of fragments will differ from that of the fragmented bundle as noted above. * If the fragmented bundle is not a fragment or is the fragment with offset zero, then all extension blocks of the fragmented bundle MUST be replicated in the fragment whose offset is zero. * Each of the fragmented bundle's extension blocks whose "Block must be replicated in every fragment" flag is set to 1 MUST be replicated in every fragment. * Beyond these rules, rules for the replication of extension blocks in the fragments must be defined in the specifications for those extension block types. 5.9. Application Data Unit Reassembly Note that the Bundle Fragmentation procedure described in Section 5.8 may result in the replacement of a single original bundle with an arbitrarily large number of fragmentary bundles. In order to be delivered at a destination node, the original bundle's payload must be reassembled from the payloads of those fragments. The "material extents" of a received fragment's payload are all continuous sequences of bytes in that payload that do not overlap with the material extents of the payloads of any previously received fragments with the same source node ID and creation timestamp. If the concatenation -- as informed by fragment offsets and payload lengths -- of the material extents of the payloads of this fragment and all previously received fragments with the same source node ID and creation timestamp as this fragment forms a continuous byte array whose length is equal to the total application data unit length noted in the fragment's primary block, then: * This byte array -- the reassembled ADU -- MUST replace the payload of that fragment whose material extents include the extent at offset zero. Note that this will enable delivery of the reconstituted original bundle as described in Step 1 of Section 5.7. * The "Reassembly pending" retention constraint MUST be removed from every other fragment with the same source node ID and creation timestamp as this fragment. Note: Reassembly of ADUs from fragments occurs at the nodes that are members of destination endpoints as necessary; an ADU MAY also be reassembled at some other node on the path to the destination. 5.10. Bundle Deletion The steps in deleting a bundle are as follows: Step 1: If the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1 and if status reporting is enabled, then a bundle deletion status report citing the reason for deletion SHOULD be generated, destined for the bundle's report-to endpoint ID. Step 2: All of the bundle's retention constraints MUST be removed. 5.11. Discarding a Bundle As soon as a bundle has no remaining retention constraints, it MAY be discarded, thereby releasing any persistent storage that may have been allocated to it. 5.12. Canceling a Transmission When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the BPA MUST delete that bundle for the reason "Transmission canceled". For this purpose, the procedure defined in Section 5.10 MUST be followed. 6. Administrative Record Processing 6.1. Administrative Records Administrative records are standard ADUs that are used in providing some of the features of the Bundle Protocol. Bundle Protocol administrative record types are registered in the IANA "Bundle Administrative Record Types" registry [RFC5050]; of these, only administrative record type 1, "Bundle status report", is defined for BPv7 at this time. Note that additional types of administrative records may be defined by supplementary DTN protocol specification documents. Every administrative record consists of: * A record type code (an unsigned integer for which valid values are as defined below). * Record content in type-specific format. Each BP administrative record SHALL be represented as a CBOR array comprising two items. The first item of the array SHALL be a record type code, which SHALL be represented as a CBOR unsigned integer. The second element of this array SHALL be the applicable CBOR encoding of the content of the record. Details of the CBOR encoding of administrative record type 1 are provided below. Details of the CBOR encoding of other types of administrative records are included in the specifications defining those records. 6.1.1. Bundle Status Reports The transmission of "bundle status reports" under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, forwarding, final delivery, and deletion. They are transmitted to the report-to endpoints of bundles. Each bundle status report SHALL be represented as a CBOR array. The number of elements in the array SHALL be either 6 (if the subject bundle is a fragment) or 4 (otherwise). The first element of the bundle status report SHALL be bundle status information represented as a CBOR array of at least four elements. The first four elements of the bundle status information shall provide information on the following four status assertions, in this order: * Reporting node received bundle. * Reporting node forwarded the bundle. * Reporting node delivered the bundle. * Reporting node deleted the bundle. Each element of the bundle status information SHALL be a bundle status item encoded as a CBOR array. The number of elements in each bundle status item SHALL be either 2 (if the value of the first element of the bundle status item is 1 AND the "Report status time"undefined". With unauthenticated, encrypted communication, OS protocols may employ more liberal settings than would be best practice when security is mandated by policy. Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. Compatibility with these systems avoids the need to resort to cleartext fallback. For greater assurance of channel security, an OS protocol may enforce more stringent cryptographic parameters when the session is authenticated. For example, the set of enabled Transport Layer Security (TLS) [RFC5246] cipher suites might exclude deprecated algorithms that would be tolerated with unauthenticated, encrypted communication. OS protocols should produce authenticated, encrypted communication when authentication of the peer is "expected". Here, "expected" means a determination via a downgrade-resistant method that authentication of that peer is expected to work. Downgrade-resistant methods include: validated DANE DNS records, existing TOFU identity information, and manual configuration. Such use of authentication is "opportunistic", in that it is performed when possible, on a per- session basis. When communicating with a peer that supports encryption but not authentication, any authentication checks enabled by default must be disabled or configured to soft-fail in order to avoid unnecessary communications failure or needless downgrade to cleartext. The support of cleartext and the use of outdated algorithms, and especially broken algorithms, is for backwards compatibility with systems already deployed. Protocol designs based on Opportunistic Security prefer to encrypt and prefer to use the best available encryption algorithms available. OS protocols employ cleartext or broken encryption algorithms only with peers that do not appear to be capable of doing otherwise. The eventual desire is to transition away from cleartext and broken algorithms, and particularly for broken algorithms, it is highly desirable to remove such functionality from implementations. Dukhovni Informational [Page 7] RFC 7435 Opportunistic Security December 2014 4. Example: Opportunistic TLS in SMTP Most Message Transfer Agents (MTAs) [RFC5598] support the STARTTLS [RFC3207] ESMTP extension. MTAs acting as SMTP [RFC5321] clients generally support cleartext transmission of email. They negotiate TLS encryption when the SMTP server announces STARTTLS support. Since the initial ESMTP negotiation is not cryptographically protected, the STARTTLS advertisement is vulnerable to MiTM downgrade attacks. Recent reports from a number of large providers (e.g., [fb-starttls] and [goog-starttls]) suggest that the majority of SMTP email transmission on the Internet is now encrypted, and the trend is toward increasing adoption. Various MTAs that advertise STARTTLS exhibit interoperability problems in their implementations. As a work-around, it is common for a client MTA to fall back to cleartext when the TLS handshake fails, or when TLS fails during message transmission. This is a reasonable trade-off, since STARTTLS only protects against passive attacks. In the absence of an active attack, TLS failures are generally one of the known interoperability problems. Some client MTAs employing STARTTLS abandon the TLS handshake when the server MTA fails authentication and immediately start a cleartext connection. Other MTAs have been observed to accept unverified self- signed certificates, but not expired certificates; again falling back to cleartext. These and similar behaviors are NOT consistent with OS principles, since they needlessly fall back to cleartext when encryption is clearly possible. Protection against active attacks for SMTP is described in [SMTP-DANE]. That document introduces the terms "Opportunistic TLS" and "Opportunistic DANE TLS", and is consistent with the OS design principles defined in this document. With "Opportunistic DANE TLS", authenticated, encrypted communication is enforced with peers for which appropriate DANE records are present. For the remaining peers, "Opportunistic TLS" is employed as before. 5. Operational Considerations OS protocol designs should minimize the possibility of failure of negotiated security mechanisms. OS protocols may need to employ "fallback", to work-around a failure of a security mechanisms that is found in practice to encounter interoperability problems. The choice to implement or enable fallback should only be made in response to significant operational obstacles. Dukhovni Informational [Page 8] RFC 7435 Opportunistic Security December 2014 When protection only against passive attacks is negotiated over a channel vulnerable to active downgrade attacks and the use of encryption fails, a protocol might elect non-intrusive fallback to cleartext. Failure to encrypt may be more often a symptom of an interoperability problem than an active attack. In such a situation, occasional fallback to cleartext may serve the greater good. Even though some traffic is sent in the clear, the alternative is to ask the administrator or user to manually work-around such interoperability problems. If the incidence of such problems is non- negligible, the user or administrator might find it more expedient to just disable Opportunistic Security. 6. Security Considerations OS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or cleartext. And yet the security provided to communicating peers is not reduced by the use of OS because the default OS policy employs the best security services available based on the capabilities of the peers, and because explicit security policies take precedence over the default OS policy. OS is an improvement over the status quo; it provides better security than the alternative of providing no security services when authentication is not possible (and not strictly required). While the use of OS is preempted by a non-OS explicit policy, such a non-OS policy can be counter-productive when it demands more than many peers can in fact deliver. A non-OS policy should be used with care, lest users find it too restrictive and act to disable security entirely. When protocols follow the OS approach, attackers engaged in large- scale passive monitoring can no longer just collect everything, and have to be more selective and/or mount more active attacks. In addition, OS means active attacks on everyone all the time are much more likely to be noticed. Specific techniques for detection and mitigation of active attacks in the absence of authentication are out of scope for this document. Some existing protocols that could support OS may be vulnerable to relatively low-cost downgrade attacks for attackers on the path. However, when such attacks are employed pervasively in order to facilitate, for example, surveillance, this is often detectable; hence, even in such scenarios, OS protocols provide a positive benefit. Protocols following the OS approach may need to define additional measures to make systematic downgrades less likely to succeed or more likely to be detected. When we have more experience in this space, Dukhovni Informational [Page 9] RFC 7435 Opportunistic Security December 2014 future revisions of this or related documents may be able to make more generally applicable recommendations. 7. References 7.1. Normative References [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>. 7.2. Informative References [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>. Dukhovni Informational [Page 10] RFC 7435 Opportunistic Security December 2014 [SMTP-DANE] Dukhovni, V. and W. Hardaker, "SMTP security via opportunistic DANE TLS", Work in Progress, draft-ietf- dane-smtp-with-dane-13, October 2014. [fb-starttls] Facebook, "The Current State of SMTP STARTTLS Deployment", May 2014, <https://www.facebook.com/notes/protect-the- graph/the-current-state-of-smtp-starttls-deployment/ 1453015901605223>. [goog-starttls] Google, "Safer email - Transparency Report - Google", June 2014, <https://www.google.com/transparencyreport/ saferemail/>. Acknowledgements I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman, Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete Resnick, Martin Thomson, Nico Williams, Paul Wouters, and Stephen Farrell for their many helpful suggestions and support. Author's Address Viktor Dukhovni Two Sigma EMail: ietf-dane@dukhovni.org Dukhovni Informational [Page 11] Internet-Draft RECALL_DEVICE March 2024