PCE Working Group Q. Wu Internet-Draft D. Dhody Intended status: Standards Track Huawei Expires: April 14, 2014 D. King Old Dog Consulting D. Lopez Telefonica I+D October 11, 2013 Path Computation Element (PCE) Discovery using Domain Name System(DNS) draft-wu-pce-dns-pce-discovery-03 Abstract Discovery of the Path Computation Element (PCE) within an IGP area or routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, it has been established that in certain deployment scenarios PCEs may not wish, or be able to participate within the IGP process. In those scenarios, it is beneficial for the Path Computation Client (PCC) (or other PCE) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support PCE type and capability discovery via DNS. 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/. 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 April 14, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Wu, et al. Expires April 14, 2014 [Page 1] Internet-Draft DNS based PCED October 2013 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . . 6 3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . 7 3.2.1. Query-Response versus Advertisement . . . . . . . . . 7 3.3. Network Address Translation Gateway . . . . . . . . . . . 7 4. Additional Capabilities . . . . . . . . . . . . . . . . . . . 8 4.1. Load Sharing of Path Computation Requests . . . . . . . . 8 5. Extended Naming Authority Pointer ( NAPTR )Service Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. IETF Standards Track PCE Applications . . . . . . . . . . 10 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 7. Discovering a Path Computation Element . . . . . . . . . . . . 12 7.1. Determining the PCE Service and transport protocol . . . . 13 7.2. Determining the IP Address of the PCE . . . . . . . . . . 13 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Determining path computation scope,capability,the PCE domains and Neighbor PCE domains . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.1. IETF PCE Application Service Tags . . . . . . . . . . . . 17 8.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Wu, et al. Expires April 14, 2014 [Page 2] Internet-Draft DNS based PCED October 2013 1. Introduction The Path Computation Element Communication Protocol (PCEP) is a transaction-based protocol carried over TCP [RFC4655]. In order to be able to direct path computation requests to the Path Computation Element (PCE), a Path Computation Client (PCC) (or other PCE) needs to know the location and capability of a PCE. In a network where an IGP is used and where the PCE participates in the IGP, discovery mechanisms exist for PCC (or PCE) to learn the identity and capability of each PCE. [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using IS-IS. Scope of the advertisement is limited to IGP area/level or Autonomous System (AS). However in certain scenarios not all PCEs will participate in the IGP instance, section 3 (Motivation) outlines a number of use cases. In these cases, current PCE Discovery mechanisms are therefore not appropriate and another PCE discovery function would be required. This document describes PCE discovery via DNS. The mechanism with which DNS comes to know about the PCE and its capability is out of scope of this document. 1.1. Terminology The following terminology is used in this document. PCE-Domain: As per [RFC4655], any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASs). Domain-Name: An identification string that defines a realm of administrative autonomy, authority, or control on the Internet. Any name registered in the DNS is a domain name. DNS Domain names are used in various networking contexts and application-specific naming and addressing purposes. In general, a domain name represents an Internet Protocol (IP) resource. Examples of DNS domain name is "www.example.com" or "example.com"[RFC1035]. 1.2. Requirements As described in [RFC4674], the PCE Discovery information should at least be composed of: Wu, et al. Expires April 14, 2014 [Page 3] Internet-Draft DNS based PCED October 2013 o The PCE location: an IPv4 and/or IPv6 address that is used to reach the PCE. It is RECOMMENDED to use an address that is always reachable if there is any connectivity to the PCE; o The PCE path computation scope (i.e., inter-area, inter-AS, or inter-layer); o The set of one or more PCE-Domain(s) into which the PCE has visibility and for which the PCE can compute paths; o The set of zero, one, or more neighbor PCE-Domain(s) toward which the PCE can compute paths; These PCE discovery information allows PCCs to select appropriate PCEs: This document specifies the procedures and extension to facilitate DNS-based PCE information discovery for specific use cases, and to complement existing IGP discovery mechanism. Wu, et al. Expires April 14, 2014 [Page 4] Internet-Draft DNS based PCED October 2013 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Wu, et al. Expires April 14, 2014 [Page 5] Internet-Draft DNS based PCED October 2013 3. Motivation This section discusses in more detail the motivation and use cases for an alternative DNS-based PCE discovery mechanism. 3.1. Outside the Routing Domain When the PCE is a router participating in the IGP, or even a server participating passively in the IGP, with all PCEP speakers in the same routing domain, a simple and efficient way to announce PCEs consists of using IGP flooding. It has been identified that the existing PCE discovery mechanisms do not work in following scenarios: Inter-AS: Per domain path computation mechanism [RFC5152] or Backward recursive path computation (BRPC) [RFC5441] MAY be used by cooperating PCEs to compute inter-domain path. In which case these cooperating PCEs should be known to other PCEs. In case of inter-AS where the PCEs do not participate in a common IGP, the existing IGP discovery mechanism cannot be used to discover inter-AS PCE. Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require disclosure of internals of a child domain to the parent PCE. It may be necessary for a third party to manage the parent PCEs according to commercial and policy agreements from each of the participating service providers [PCE-QUESTION]. [RFC6805] specifies that a child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. However handling changes in parent PCE identities and coping with failure events would be an issue for a configured system. There is no scope for parent PCEs to advertise their presence to child PCEs when they are not a part of the same routing domain. BGP: [BGP-LS] describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. An external PCE MAY use this mechanism to populate its TED and not take part in the same IGP routing domain. NMS/OSS: PCE MAY gain the knowledge of Topology information from some management system (e.g.,NMS/OSS) and not take part in the same routing domain. Also note that in some case PCC may not be a router and instead be a management system like NMS and may not be able to discover PCE via IGP discovery. Wu, et al. Expires April 14, 2014 [Page 6] Internet-Draft DNS based PCED October 2013 3.2. Discovery Mechanisms 3.2.1. Query-Response versus Advertisement Advertisement based PCE discovery using IGP methods [RFC5088] and [RFC5089] floods the PCE information to an area, a subset of areas or to a full routing domain. By the very nature of flooding and advertisements it generates unwanted traffic and may lead to unnecessary advertisement, especially when PCE information needs frequent changes. DNS is a query-response based mechanism, a client (a PCC) can use DNS to discover a PCE only when it needs to compute a path and does not require any other node in the network to be involved. In case of Intermittent PCEP session, where PCEP sessions are systematically open and closed for each PCEP request, a DNS-based query-response mechanism is more suitable. One may also utilize DNS- based load-balancing and recovery functions. 3.3. Network Address Translation Gateway PCEP uses TCP as the transport mechanism between PCC and PCE, and PCE to PCE, communications [RFC5440]. To secure TCP connection that underlay PCEP sessions, Transport Layer Security (TLS) can be used besides using TCP-MD5 [RFC2385] and TCP-AUTH [RFC5295]. When PCC and PCE support TCP-MD5 or TCP-AUTH while NAT does not, TCP connection establishment fails. When NAT gateway is in presence, a TCP or TCP/ TLS connection can be opened by Interactive Connectivity Establishment (ICE) [RFC5245] for the purpose of connectivity checks. However the TCP connection cannot be established in cases where one of the peers is behind a NAT with connection-dependent filtering properties [RFC5382]. Therefore IGP discovery is limited within an IGP domain and cannot be used in this case. Wu, et al. Expires April 14, 2014 [Page 7] Internet-Draft DNS based PCED October 2013 4. Additional Capabilities 4.1. Load Sharing of Path Computation Requests Multiple PCEs can be present in a single network domain for redundancy. DNS supports inherent load balancing where multiple PCEs (with different IP addresses) are known in DNS for a single PCE server name and are hidden from the PCC. In an IGP advertisement based PCE discovery, one learns of all the PCEs and it is the job of the PCC to do load-balancing. A DNS-based load-balancing mechanism works well in case of Intermittent PCEP sessions and request are load-balanced among PCEs similar to HTTP request without any complexity at the client. Wu, et al. Expires April 14, 2014 [Page 8] Internet-Draft DNS based PCED October 2013 5. Extended Naming Authority Pointer ( NAPTR )Service Field Format The NAPTR service field format defined by the S-NAPTR DDDS application in [RFC3958] follows this Augmented Backus-Naur Form (ABNF) [RFC5234]: service-parms = [ [app-service] *(":" app-protocol)] app-service = experimental-service / iana-registered-service app-protocol = experimental-protocol / iana-registered-protocol experimental-service = "x-" 1*30ALPHANUMSYM experimental-protocol = "x-" 1*30ALPHANUMSYM iana-registered-service = ALPHA *31ALPHANUMSYM iana-registered-protocol = ALPHA *31ALPHANUMSYM ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." ALPHANUMSYM = ALPHA / DIGIT / SYM ; The app-service and app-protocol tags are limited to 32 ; characters and must start with an alphabetic character. ; The service-parms are considered case-insensitive. This specification refines the "iana-registered-service" tag definition for the discovery of PCE supporting a specific PCE application or capability as defined below. iana-registered-service =/ pce-service pce-service = "pce+ap" appln-id appln-id = 1*10DIGIT ; Application Identifier expressed as ; a decimal integer without leading ; zeros. The appln-id element is the Application Identifier used to identify a specific PCE application. The PCE Application Identifier is a 32-bit unsigned integer, and values are allocated by IANA as defined in section 8.1. This specification also refines the "iana-registered-protocol" tag definition for the discovery of PCE supporting a specific transport protocol as defined below. iana-registered-protocol =/ pce-protocol pce-protocol = "pce." pce-transport pce-transport = "tcp" / "tls.tcp" Similar to application protocol tags defined in the [RFC6408],the S-NAPTR application protocol tags defined by this specification MUST NOT be parsed in any way by the querying application or Resolver. Wu, et al. Expires April 14, 2014 [Page 9] Internet-Draft DNS based PCED October 2013 The delimiter (".") is present in the tag to improve readability and does not imply a structure or namespace of any kind. The choice of delimiter (".") for the application protocol tag follows the format of existing S-NAPTR application protocol tag registry entries, but this does not imply that it shares semantics with any other specifications that create registry entries with the same format. The S-NAPTR application service and application protocol tags defined by this specification are unrelated to the IANA "Service Name and Transport Protocol Port Number Registry" (see [RFC6335]). The maximum length of the NAPTR service field is 256 octets, including a one-octet length field (see Section 4.1 of [RFC3403] and Section 3.3 of [RFC1035]). 5.1. IETF Standards Track PCE Applications A PCE Client MUST be capable of using the extended S-NAPTR application service tag for dynamic discovery of a PCE supporting Standards Track applications. Therefore, every IETF Standards Track PCE application MUST be associated with a "PCE-service" tag formatted as defined in this specification and allocated in accordance with IANA policy (see Section 8). For example, a NAPTR service field value of: 'PCE+ap1:pce.tcp' means that the PCE in the SRV or A/AAAA record supports the Global Concurrent Optimization Application ('1') (See section 8.1)and the Transport Control Protocol (TCP) as the transport protocol (See section 8.2). Wu, et al. Expires April 14, 2014 [Page 10] Internet-Draft DNS based PCED October 2013 6. Backwards Compatibility Domain Name System (DNS) administrators SHOULD also provision legacy NAPTR records [RFC3403] in order to guarantee backwards compatibility with legacy PCE that only support S-NAPTR DDDS application in [RFC3958]. If the DNS administrator provisions both extended S-NAPTR records as defined in this specification and legacy NAPTR records defined in [RFC3403], then the extended S-NAPTR records MUST have higher priority(e.g., lower order and/or preference values) than legacy NAPTR records. Wu, et al. Expires April 14, 2014 [Page 11] Internet-Draft DNS based PCED October 2013 7. Discovering a Path Computation Element The extended-format NAPTR records provide a mapping from a domain to the SRV record or A/AAAA record for contacting a server supporting a specific transport protocol and PCE application. The resource record will contain an empty regular expression and a replacement value, which is the SRV record or the A/AAAA record for that particular transport protocol. The assumption for this mechanism to work is that the DNS administrator of the queried domain has first provisioned the DNS with extended-format NAPTR entries. When the PCC or other PCEs performs a NAPTR query for a server in a particular realm, the PCC or other PCEs has to know in advance the search path of the resolver, i.e.,in which realm to look for a PCE, and in which Application Identifier it is interested. The search path of the resolver can either be pre-configured, or discovered using Diameter, DHCP or other means. For example, the realm could be deduced from the Network Access Identifier (NAI) in the User-Name attribute-value pair (AVP) or extracted from the Destination-Realm AVP in Diameter [RFC6733]. When pre-configuration is used, PCE domain(e.g.,AS200)can be added as "subdomains" of the first-level domain of the underlying service (e.g., AS200.example.com), which allows a NAPTR query for a server in a PCE domain associated with DNS domain-name. When DHCP is used, it SHOULD know the domain-name of that realm and use DHCP to discover IP address of the PCE in that realm that provides path computation service along with some PCE location information useful to a PCC (or other PCE) for a PCE selection, and contact it directly. In some instances, the discovery may result in a per protocol/application list of domain-names that are then used as starting points for the subsequent S-NAPTR lookups [RFC3958]. If neither the IP address nor other PCE location information can be discovered with the above procedure, the PCC (or other PCE) MAY request a domain search list, as described in [RFC3397] and[RFC3646], and use it as input to the DDDS application. When the PCC (or other PCE) does not find valid domain-names using the mechanisms above, it MUST stop the attempt to discover any PCE. The following procedures result in an IP address, PCE domain, neighboring PCE domain and PCE Computation Scope where the PCC (or other PCE) can contact the PCE that hosts the service it is looking for. Wu, et al. Expires April 14, 2014 [Page 12] Internet-Draft DNS based PCED October 2013 7.1. Determining the PCE Service and transport protocol The PCC (or other PCE) should know the service identifier for the Path Computation service and associated transport protocol. The service identifier for the Path Computation service is defined as "PCE+apX" as specified in section 5, The PCE supporting "PCE" service MUST support TCP as transport, as described in [RFC5440]. The services relevant for the task of transport protocol selection are those with S-NAPTR service fields with values "PCE+apX:Y", where 'PCE+apX' is the service identifier defined in the previous paragraph, and ' Y' is the letter that corresponds to a transport protocol supported by the PCE. This document also establishes an IANA registry for mappings of S-NAPTR service name to transport protocol. These NAPTR [RFC3958] records provide a mapping from a domain to the SRV [RFC2782] record for contacting a PCE with the specific transport protocol in the S-NAPTR services field. The resource record MUST contain an empty regular expression and a replacement value, which indicates the domain name where the SRV record for that particular transport protocol can be found. As per [RFC3403], the client discards any records whose services fields are not applicable. The PCC (or other PCE) MUST discard any service fields that identify a resolution service whose value is not valid. The S-NAPTR processing as described in [RFC3403] will result in the discovery of the most preferred PCE that is supported by the client, as well as an SRV record for the PCE. 7.2. Determining the IP Address of the PCE If the returned NAPTR service fields contain entries formatted as "pce+apX:Y" where "X" indicates the Application Identifier and "Y" indicates the supported transport protocol(s), the target realm supports the extended format for NAPTR-based PCE discovery defined in this document. o If "X" contains the required Application Identifier and "Y" matches a supported transport protocol, the PCEP implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field. o If "X" does not contain the required Application Identifier or "Y" does not match a supported transport protocol, the PCEP implementation abandons the peer discovery. If the returned NAPTR service fields contain entries formatted as Wu, et al. Expires April 14, 2014 [Page 13] Internet-Draft DNS based PCED October 2013 "pce+apX" where "X" indicates the Application Identifier, the target realm supports the extended format for NAPTR-based PCE discovery defined in this document. o If "X" contains the required Application Identifier, the PCEP implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field and attempts to connect using all supported transport protocols. o If "X" does not contain the required Application Identifier, the PCEP implementation abandons the PCE discovery. If the returned NAPTR service fields contain entries formatted as "pce:X" where "X" indicates the supported transport protocol(s), the target realm supports PCEP but does not support the extended format for NAPTR-based PCE discovery defined in this document. o If "X" matches a supported transport protocol, the PCEP implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field. If the returned NAPTR service fields contain entries formatted as "pce", the target realm supports PCEP but does not support the extended format for NAPTR-based PCE discovery defined in this document. The PCEP implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field and attempts to connect using TCP (in future it SHOULD attempt all supported transport Protocols) . Note that the regexp field in the S-NAPTR example above is empty. The regexp field MUST NOT be used when discovering PCE, as its usage can be complex and error prone. Also, the discovery of the PCE does not require the flexibility provided by this field over a static target present in the TARGET field. As the default behavior, the client is configured with the information about which transport protocol is used for a path computation service in a particular domain. The client can directly perform an SRV query for that specific transport using the service identifier of the path computation Service. For example, if the client knows that it should be using TCP for path computation service, it can perform a SRV query directly for_PCE._tcp.example.com. Once the server providing the desired service and the transport protocol has been determined, the next step is to determine the IP address. Wu, et al. Expires April 14, 2014 [Page 14] Internet-Draft DNS based PCED October 2013 According to the specification of SRV RRs in [RFC2782], the TARGET field is a fully qualified domain-name (FQDN) that MUST have one or more address records; the FQDN must not be an alias, i.e., there MUST NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query already has reported a sufficient number of these address records in the Additional Data section of the DNS response (as recommended by [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) of the domain-name, as appropriate. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously. 7.2.1. Examples As an example, consider a client that wishes to find PCED service in the as100.example.com domain. The client performs a S-NAPTR query for that domain, and the following NAPTR records are returned: Order Pref Flags Service Regexp Replacement IN NAPTR 50 50 "s" "pce:pce.tls.tcp" "" _PCE._tcp.as100.example.com IN NAPTR 90 50 "s" "pce:pce.tcp" "" _PCE._tcp.as100.example.com This indicates that the domain does have a PCE providing Path Computation services over TCP, in that order of preference. If the client only supports TCP, TCP will be used, targeted to a host determined by an SRV lookup of _PCE._tcp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 XXXX server1.as100.example.com IN SRV 0 2 XXXX server2.as100.example.com where XXXX represents the port number at which the service is reachable. As an alternative example, a client wishes to discover a PCE in the ex2.example.com realm that supports the GCO application over TCP. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: Wu, et al. Expires April 14, 2014 [Page 15] Internet-Draft DNS based PCED October 2013 ;; order pref flags service regexp replacement IN NAPTR 150 50 "a" "pce:pce.tcp" "" server1.ex2.example.com IN NAPTR 150 50 "a" "pce:pce.tls.tcp" "" server2.ex2.example.com IN NAPTR 150 50 "a" "pce+ap1:pce.tcp" "" server1.ex2.example.com IN NAPTR 150 50 "a" "pce+ap1:pce.tls.tcp" "" server2.ex2.example.com This indicates that the server supports GCO(ID=1) over TCP and TLS/ TCP via hosts server1.ex2.example.com and server2.ex2.example.com, respectively. 7.3. Determining path computation scope,capability,the PCE domains and Neighbor PCE domains DNS servers MAY use DNS TXT record to give additional information about PCE service and add such TXT record to the additional information section (See section 4.1 of [RFC1035]) that are relevant to the answer and have the same authenticity as the data (Generally this will be made up of A and SRV records)in the answer section. The additional information may include path computation scope, capability, the PCE domains and Neighbor PCE domains associated with the PCE. If discovery of PCE supporting a specific PCE capability described in section 7.2 has already been performed, capability associated with the PCE does not need to be included in the additional information. To store new types of information, the TXT record uses a structured format in its TXT-DATA field [RFC1035]. The format consists of the attribute name followed by the value of the attribute. The name and value are separated by an equals sign (=). The general syntax is defined in section 2 of [RFC1464] as follows: TXT "=" For example, the following TXT records contain attributes specified in this fashion: ex2.example.com IN TXT "path computation scope=inter-as" ex2.example.com IN TXT "capability=link constraint" ex2.example.com IN TXT "pce domain = as10" ex2.example.com IN TXT "neighbor pce domain= area1" The PCC MAY inspect those Additional Information section in the DNS message and be capable of handling responses from nameservers that never fill in the Additional Information part of a response. Wu, et al. Expires April 14, 2014 [Page 16] Internet-Draft DNS based PCED October 2013 8. IANA Considerations 8.1. IETF PCE Application Service Tags IANA specifies to create a new registry ' S-NAPTR application service tags' for existing IETF PCE applications. +------------------+----------------------------+ | Tag | PCE Application | +------------------+----------------------------+ | pce+ap1 | GCO [RFC5557] | | pce+ap2 | P2MP [RFC5671] | | pce+ap3 | Stateful [STATEFUL-PCE] | | pce+ap4 | GMPLS [RFC7025] | | pce+ap5 | Inter-AS[RFC5376] | | pce+ap6 | Inter-Area [RFC4927] | | pce+ap7 | Inter-layer [RFC6457] | +------------------+----------------------------+ Future IETF PCE applications MUST reserve the S-NAPTR application service tag corresponding to the allocated PCE Application ID as defined in Section 3. 8.2. PCE Application Protocol Tags IANA has reserved the following S-NAPTR Application Protocol Tags for the PCE transport protocols in the "S-NAPTR Application Protocol Tag" registry created by [RFC3958]. +------------------+----------+ | Tag | Protocol | +------------------+----------+ | pce.tcp | TCP | | pce.tls.tcp | TLS/TCP | +------------------+----------+ Future PCE versions that introduce new transport protocols MUST reserve an appropriate S-NAPTR Application Protocol Tag in the "S-NAPTR Application Protocol Tag" registry created by [RFC3958]. Wu, et al. Expires April 14, 2014 [Page 17] Internet-Draft DNS based PCED October 2013 9. Security Considerations This document specifies an enhancement to the NAPTR service field format. The enhancement and modifications are based on the S-NAPTR, which is actually a simplification of the NAPTR, and therefore the same security considerations described in [RFC3958] are applicable to this document. For most of those identified threats, the DNS Security Extensions [RFC4033] does provide protection. It is therefore recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC6781] when deploying Path Computation Services. In deployments where DNSSEC usage is not feasible, measures should be taken to protect against forged DNS responses and cache poisoning as much as possible. Efforts in this direction are documented in [RFC5452]. However a malicious host doing S-NAPTR queries learns applications supported by PCEs in a certain realm faster, which might help the malicious host to scan potential targets for an attack more efficiently when some applications have known vulnerabilities. Where inputs to the procedure described in this document are fed via DHCP, DHCP vulnerabilities can also cause issues. For instance, the inability to authenticate DHCP discovery results may lead to the Path Computation service results also being incorrect, even if the DNS process was secured. Wu, et al. Expires April 14, 2014 [Page 18] Internet-Draft DNS based PCED October 2013 10. Acknowledgements The author would like to thank Claire Bi,Ning Kong, Liang Xia, Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart Cheshire for their review and comments that help improvement to this document. Wu, et al. Expires April 14, 2014 [Page 19] Internet-Draft DNS based PCED October 2013 11. References 11.1. Normative References [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987. [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3958] Daigle, D. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [RFC4033] Arends, R., "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4674] Droms, R., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, December 2003. [RFC5440] Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, April 2007. [RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, October 2012. [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, Wu, et al. Expires April 14, 2014 [Page 20] Internet-Draft DNS based PCED October 2013 December 2012. [RFC6805] King, D. and A. Farrel, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012. 11.2. Informative References [ALTO] Kiesel, S., "ALTO Server Discovery", ID draft-ietf-alto-server-discovery-08, March 2013. [BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and TE Information using BGP", ID draft-ietf-idr-ls-distribution-03, May 2013. [PCE-QUESTION] Farrel, A., "Unanswered Questions in the Path Computation Element Architecture", ID http://tools.ietf.org/html/draft-ietf-pce-questions-00, July 2013. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC4927] Le Roux, JL., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007. [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5295] Touch, J., "The TCP Authentication Option", RFC 5295, June 2010. [RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. Wu, et al. Expires April 14, 2014 [Page 21] Internet-Draft DNS based PCED October 2013 [RFC5382] Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382, October 2008. [RFC5452] Hubert, A., "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009. [RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", RFC 6457, June 2007. [RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE", RFC 7025, September 2013. Wu, et al. Expires April 14, 2014 [Page 22] Internet-Draft DNS based PCED October 2013 Authors' Addresses Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: sunseawq@huawei.com Dhruv Dhody Huawei Leela Palace Bangalore, Karnataka 560008 INDIA Email: dhruv.dhody@huawei.com Daniel King Old Dog Consulting UK Email: daniel@olddog.co.uk Diego R. Lopez Telefonica I+D Email: diego@tid.es Wu, et al. Expires April 14, 2014 [Page 23]