--- 1/draft-ietf-ipsecme-labeled-ipsec-02.txt 2020-07-13 15:13:12.181405175 -0700 +++ 2/draft-ietf-ipsecme-labeled-ipsec-03.txt 2020-07-13 15:13:12.201405676 -0700 @@ -1,56 +1,56 @@ Network P. Wouters Internet-Draft S. Prasad Updates: 7296 (if approved) Red Hat -Intended status: Standards Track November 4, 2019 -Expires: May 7, 2020 +Intended status: Standards Track July 13, 2020 +Expires: January 14, 2021 Labeled IPsec Traffic Selector support for IKEv2 - draft-ietf-ipsecme-labeled-ipsec-02 + draft-ietf-ipsecme-labeled-ipsec-03 Abstract This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. 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 http://datatracker.ietf.org/drafts/current/. + 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 May 7, 2020. + This Internet-Draft will expire on January 14, 2021. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 - (http://trustee.ietf.org/license-info) in effect on the date of + (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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -176,24 +176,24 @@ length of this Traffic Selector substructure including the header. o Security Label - An opaque byte stream of at least one octet. 2.2. TS_SECLABEL properties The TS_SECLABEL Traffic Selector Type does not support narrowing or wildcards. It MUST be used as an exact match value. If the TS_SECLABEL is present in a TSi/TSr, at least one Traffic - Selector of type TS_IPV4_ADDR_RANGE or TS_IPV4_ADDR_RANGE MUST also + Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE MUST also be present in that TSi/TSr. - The Security Label contents are opague to the IKE implementation. + The Security Label contents are opaque to the IKE implementation. That is, the IKE implementation might not have any knowledge of the meaning of this selector, other than as a type and opaque value to pass to the SPD. A zero length Security Label MUST NOT be used. If a received TS payload contains a TS_TYPE of TS_SECLABEL with a zero length Security Label, that specific Traffic Selector MUST be ignored. If no other Traffic Selector of TS_TYPE TS_SECLABEL can be selected, a TS_UNACCEPTABLE Error Notify message MUST be returned. A zero length Security Label MUST NOT be interpreted as a wildcard security label. @@ -312,22 +312,22 @@ A large part of the introduction text was taken verbatim from [draft-jml-ipsec-ikev2-security-label] whose authors are J Latten, D. Quigley and J. Lu. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + DOI 10.17487/RFC2119, March 1997, + . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, .