idnits 2.17.1 draft-wu-pce-discovery-priority-allocation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC5088], [RFC5089]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4657' is mentioned on line 108, but not defined == Missing Reference: 'RFC5557' is mentioned on line 109, but not defined == Missing Reference: 'RFC6006' is mentioned on line 109, but not defined ** Obsolete undefined reference: RFC 6006 (Obsoleted by RFC 8306) -- Duplicate reference: RFC5440, mentioned in 'RFC5440', was also mentioned in 'RFC5246'. Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE working group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track October 21, 2013 5 Expires: April 24, 2014 7 IGP extension for PCEP transport capability support in the PCE discovery 8 draft-wu-pce-discovery-priority-allocation-01 10 Abstract 12 [RFC5088][RFC5089] define a method to advertise path computation 13 capabilities using IGP flooding. OSPF and ISIS are extended to 14 support such capabilities advertisement. However 15 [RFC5088][RFC5089]don't provide a method to advertise PCEP over TLS 16 support capability. 18 This document proposes new capability flag bit for PCE-CAP-FLAGS sub- 19 TLV that can be announced as attribute in the IGP advertisement 20 (defined in [RFC5088 ][RFC5089]) to distribute transport support 21 information. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 24, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 2 59 3. IGP extension for PCEP transport capability support . . . . . 3 60 3.1. Use of PCEP transport capability support for PCE 61 discovery . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 6.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 As described in [RFC5440], PCEP communication privacy is one 72 importance issue, especially in an inter-AS context, where PCEP 73 communication end-points do not reside in the same AS, as an attacker 74 that intercepts a PCE message could obtain sensitive information 75 related to computed paths and resources. 77 Among the possible solutions mentioned in these documents, Transport 78 Layer Security (TLS) [RFC5246] provides support for peer 79 authentication, and message encryption and integrity. In order for a 80 PCC to begin a connection with a PCE server using TLS, PCC should 81 know whether PCE server Support TLS as transport. 83 [RFC5088][RFC5089] define a method to advertise path computation 84 capabilities using IGP flooding. OSPF and ISIS are extended to 85 support such capabilities advertisement. However 86 [RFC5088][RFC5089]don't provide a method to advertise PCEP over TLS 87 support capability. 89 This document proposes new capability flag bit for PCE-CAP-FLAGS sub- 90 TLV that can be announced as attribute in the IGP advertisement 91 (defined in [RFC5088 ][RFC5089]) to distribute transport support 92 information. 94 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC2119 [RFC2119]. 99 3. IGP extension for PCEP transport capability support 101 The PCE-CAP-FLAGS sub-TLV is defined in section 4.5 of 102 [RFC5088][RFC5089] and an optional sub-TLV used to advertise PCE 103 capabilities. In this section, we extend the PCE-CAP-FLAGS sub-TLV 104 to include the capability and indications that are described for PCEP 105 over TLS support in the present document. 107 In the PCE-CAP-FLAGS sub-TLV defined in [RFC5088][RFC5089], nine 108 capability flags defined in [RFC4657] and two capability flags 109 defined [RFC5557][RFC6006]are included and follows the following 110 format: The PCE-CAP-FLAGS sub-TLV has the following format: 112 o TYPE: 5 113 o LENGTH: Multiple of 4 115 o VALUE: This contains an array of units of 32 bit flags with the 116 most significant bit as 0. Each bit represents one PCE capability 118 and the processing rule of these flag bits are defined in 119 [RFC5088][RFC5089]. In this document, we define one new capability 120 flag bit that indicate TCP MD5 support, TCP AO support, PCEP over TLS 121 support and PCEP over TLS and TCP AO support respectively as follows: 123 Bit Capability Description 124 xx TCP MD5 support 125 xx TCP AO Support 126 xx PCEP over TLS support 127 xx PCEP over TLS support and TCP AO support 129 3.1. Use of PCEP transport capability support for PCE discovery 131 TCP MD5, TCP AO, PCEP over TLS support and PCEP over TLS and TCP AO 132 support flag bits are advertised using IGP flooding. If the PCE 133 server supports only TCP MD5 as transport, IGP advertisement Should 134 not include PCEP over TLS support flag bit or TCP AO support flag 135 bit. If the PCE server supports both TCP MD5 and TCP AO, IGP 136 advertisment Should include both TCP AO support flag bit and TCP MD5 137 support flag bit in the PCE-CAP-FLAGS sub-TLV. If the PCE server 138 only supports TLS over TCP as transport, IGP advertisement MUST 139 include PCEP over TLS support flag bit in the PCE-CAP-FLAGS sub-TLV. 141 If the client is looking for connecting with PCE server with TCP AO 142 support, the client MUST check if TCP AO support flag bit in the PCE- 143 CAP-FLAGS sub-TLV is set before retrieving PCE location information 144 from IGP message. if not, the client should discard PCEPD TLV with 145 TCP AO support flag bit clear. If the client is looking for 146 connecting with PCE server using TLS, the client MUST check if PCEP 147 over TLS support flag bit in the PCE-CAP-FLAGS sub-TLV is set before 148 retrieving PCE location information from IGP message. If not, then 149 the client should discard PCED TLV with PCEP over TLS support flag 150 bit clear. 152 4. Security Considerations 154 This document raises no new security issues beyond those described in 155 [RFC5088][RFC5089]. 157 5. IANA Considerations 159 IANA is requested to allocate a new bit in "PCE Capability Flags" 160 registry for PCEP over TLS support capability. 162 6. References 164 6.1. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", March 1997. 169 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 170 Computation Element (PCE) Discovery", RFC 5088, January 171 2008. 173 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 174 Computation Element (PCE) Discovery", RFC 5089, January 175 2008. 177 6.2. Informative References 179 [RFC5246] Dierks, T., "The Transport Layer Security (TLS) Protocol 180 Version 1.2", RFC 5440, August 2008. 182 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 183 Communication Protocol (PCEP)", RFC 5440, March 2009. 185 Author's Address 186 Qin Wu 187 Huawei 188 101 Software Avenue, Yuhua District 189 Nanjing, Jiangsu 210012 190 China 192 Email: sunseawq@huawei.com