idnits 2.17.00 (12 Aug 2021) /tmp/idnits15421/draft-wu-pce-dns-pce-discovery-02.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 : ---------------------------------------------------------------------------- ** 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 (August 12, 2013) is 3204 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: 'RFC5152' is mentioned on line 165, but not defined == Missing Reference: 'RFC5441' is mentioned on line 166, but not defined == Unused Reference: 'RFC4848' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'ALTO' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'BGP-LS' is defined on line 517, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4674 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6781 ** Downref: Normative reference to an Informational RFC: RFC 6805 == Outdated reference: draft-ietf-alto-server-discovery has been published as RFC 7286 == Outdated reference: draft-ietf-idr-ls-distribution has been published as RFC 7752 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei 5 Expires: February 13, 2014 D. King 6 Old Dog Consulting 7 D. Lopez 8 Telefonica I+D 9 August 12, 2013 11 Path Computation Element (PCE) Discovery using Domain Name System(DNS) 12 draft-wu-pce-dns-pce-discovery-02 14 Abstract 16 Discovery of the Path Computation Element (PCE) within an IGP area or 17 routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. 18 However, in some deployment scenarios PCEs may not wish, or be able, 19 to participate within the IGP process, therefore it would be 20 beneficial for the Path Computation Client (PCC) (or other PCEs) to 21 discover PCEs via an alternative mechanism to those proposed in 22 [RFC5088] and [RFC5089]. 24 This document specifies the requirements, use cases, procedures and 25 extensions to support discovery via DNS for PCE. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 13, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 5 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . . 6 67 3.2. Query-Response v/s Advertisement . . . . . . . . . . . . . 7 68 3.3. Network Address Translation Gateway . . . . . . . . . . . 7 69 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Load Sharing of Path Computation Requests . . . . . . . . 8 71 5. Discovering a Path Computation Element . . . . . . . . . . . . 9 72 5.1. Determining the PCE Service and transport protocol . . . . 10 73 5.2. Determining the IP Address of the PCE . . . . . . . . . . 10 74 5.3. Determining path computation scope,capability,the PCE 75 domains and Neighbor PCE domains . . . . . . . . . . . . . 11 76 5.4. Relationship between PCE-Domain and DNS Domain-Name . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The Path Computation Element Communication Protocol (PCEP) is a 88 transaction-based protocol carried over TCP [RFC4655]. In order to 89 be able to direct path computation requests to the Path Computation 90 Element (PCE), a Path Computation Client (PCC) (or other PCEs) needs 91 to know the location and capability of a PCE. 93 In a network where an IGP is used and where the PCE participates in 94 the IGP, discovery mechanisms exist for PCC (or PCE) to learn the 95 identity and capability of each PCE. [RFC5088] defines a PCE 96 Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, 97 [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using 98 IS-IS. Scope of the advertisement is limited to IGP area/level or 99 Autonomous System (AS). 101 However in certain scenarios not all PCEs will participate in the IGP 102 instance, section 3 (Motivation) outlines a number of use cases. In 103 these cases, current PCE Discovery mechanisms are therefore not 104 appropriate and another PCE discovery function would be required. 106 This document describes PCE discovery via DNS. The mechanism with 107 which DNS comes to know about the PCE and its capability is out of 108 scope of this document. 110 1.1. Terminology 112 The following terminology is used in this document. 114 Domain: As per [RFC4655], any collection of network elements within 115 a common sphere of address management or path computational 116 responsibility. Examples of domains include Interior Gateway 117 Protocol (IGP) areas and Autonomous Systems (ASs). 119 Domain-Name: TBD. 121 1.2. Requirements 123 As described in [RFC4674], the PCE Discovery information should at 124 least be composed of: 126 o The PCE location: an IPv4 and/or IPv6 address that is used to 127 reach the PCE. It is RECOMMENDED to use an address that is always 128 reachable if there is any connectivity to the PCE; 130 o The PCE path computation scope (i.e., intra-layer, inter-area, 131 inter-AS, or inter-layer); 133 o The set of one or more PCE-Domain(s) into which the PCE has 134 visibility and for which the PCE can compute paths; 136 o The set of zero, one, or more neighbor PCE-Domain(s) toward which 137 the PCE can compute paths; 139 that allows PCCs to select appropriate PCEs: 141 This document specifies an extension to DNS for the above PCE 142 information discovery, which is complements the existing discovery 143 mechanism. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC2119 [RFC2119]. 151 3. Motivation 153 This section discusses in more detail the motivation and use cases 154 for an alternative DNS based PCE discovery mechanism. 156 3.1. Outside the Routing Domain 158 When the PCE is a router participating in the Interior Gateway 159 Protocol (IGP), or even a server participating passively in the IGP, 160 with all PCEP speakers in the same routing domain, a simple and 161 efficient way to announce PCEs consists of using IGP flooding. 163 But the existing mechanism does not work in following situations: 165 Inter-AS: Per domain path computation mechanism [RFC5152] or 166 Backward recursive path computation (BRPC) [RFC5441] MAY be used 167 by cooperating PCEs to compute inter-domain path. In which case 168 these cooperating PCEs should be known to other PCEs. In case of 169 inter-AS where the PCEs do not participate in a common IGP, the 170 existing IGP discovery mechanism cannot be used to discover 171 inter-AS PCE. 173 Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require 174 disclosure of internals of a child domain to the parent PCE. It 175 may be necessary for a third party to manage the parent PCEs 176 according to commercial and policy agreements from each of the 177 participating service providers [PCE-QUESTION]. [RFC6805] 178 specifies that a child PCE must be configured with the address of 179 its parent PCE in order for it to interact with its parent PCE. 180 However handling changes in parent PCE identities and coping with 181 failure events would be an issue for a configured system. There 182 is no scope for parent PCEs to advertise their presence to child 183 PCEs when they are not a part of the same routing domain. 185 BGP: [I.D.draft-ietf-idr-ls-distribution] describes a mechanism by 186 which links state and traffic engineering information can be 187 collected from networks and shared with external components using 188 the BGP routing protocol. An external PCE MAY use this mechanism 189 to populate its TED and not take part in the same IGP routing 190 domain. 192 NMS/OSS: PCE server MAY gain the knowledge of Topology information 193 from some management system (e.g.,NMS/OSS) and not take part in 194 the same routing domain. Also note that in some case PCC may not 195 be a router and instead be a management system like NMS and may 196 not be able to discover PCE via IGP discovery. 198 3.2. Query-Response v/s Advertisement 200 Advertisement based IGP PCE discovery [RFC5088] and [RFC5089] floods 201 the PCE information to an area, a subset of areas or to a full 202 routing domain. By the very nature of flooding and advertisements it 203 generates unwanted traffic and may lead to unnecessary advertisement, 204 especially when PCE information needs frequent changes. 206 DNS is a query-response based mechanism, a client (say PCC) can use 207 DNS to discover a PCE only when it needs it and does not require any 208 other node in the network to be involved. 210 Incase of Intermittent PCEP session, where PCEP sessions are 211 systematically open and closed for each PCEP request, a DNS based 212 query-response mechanism is more suitable. One may utilize DNS based 213 load-balancing and recovery functions. 215 3.3. Network Address Translation Gateway 217 PCEP uses TCP as the transport [RFC5440]. To secure TCP connection 218 that underlay PCEP sessions, TLS can be used besides using TCP-MD5 219 [RFC2385] and TCP-AUTH [RFC5295]. When PCC and PCE support TCP-MD5 220 or TCP-AUTH while NAT does not, TCP connection establishment fails. 221 When NAT gateway is in presence, a TCP or TCP/TLS connection can be 222 opened by Interactive Connectivity Establishment (ICE) [RFC5245] for 223 the purpose of connectivity checks. However the TCP connection 224 cannot be established in cases where one of the peers is behind a NAT 225 with connection-dependent filtering properties [RFC5382]. Therefore 226 IGP discovery is limited within an IGP domain and cannot be used in 227 this case. 229 4. Other Considerations 231 4.1. Load Sharing of Path Computation Requests 233 Multiple PCE servers can be present in a single network domain for 234 redundancy. DNS supports inherent load balancing where multiple PCEs 235 (with different IP addresses) are known in DNS for a single PCE 236 server name and are hidden from the PCC. 238 In an IGP advertisement based PCE discovery, one learns of all the 239 PCEs and it is the job of the PCC to do load-balancing. 241 A DNS based load-balancing mechanism works well in case of 242 Intermittent PCEP sessions and request are load-balanced among PCEs 243 similar to HTTP request without any complexity at the client. 245 5. Discovering a Path Computation Element 247 The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to 248 implement lazy binding of strings to data, in order to support 249 dynamically configured delegation systems. The DDDS functions by 250 mapping some unique string to data stored within a DDDS database by 251 iteratively applying string transformation rules until a terminal 252 condition is reached. When DDDS uses DNS as a distributed database 253 of rules, these rules are encoded using the Naming Authority Pointer 254 (NAPTR) Resource Record (RR). One of these rules is the First Well 255 Known Rule, which says where the process starts. 257 In current specifications, the First Well Known Rule in a DDDS 258 application [RFC3403] is assumed to be fixed, i.e., the domain in the 259 tree where the lookups are to be routed to, is known. This document 260 proposes the input to the First Well Known Rule to be dynamic, based 261 on the search path the resolver discovers or is configured to use. 263 The search path of the resolver can either be pre-configured, or 264 discovered using DHCP. 266 When the PCC or other PCEs needs to discover PCEs in the domain into 267 which the PCEP speaker has visibility (e.g.,local domain), the input 268 to the First Well Known Rule MUST be the domain the PCC knows, which 269 is assumed to be pre-configured in the PCC or discovered using DHCP. 271 When the PCC needs to discover PCE in the other domain (e.g., AS, 272 Parent PCE in the parent domain)into which the PCC has no visibility, 273 it SHOULD know the domain name of that domain and use DHCP to 274 discover IP address of the PCE in that domain that provides path 275 computation service along with some PCE location information useful 276 to a PCC for PCE selection, and contact it directly. In some 277 instances, the discovery may result in a per protocol/application 278 list of domain names that are then used as starting points for the 279 subsequent NAPTR lookups. If neither the IP address nor other PCE 280 location information can be discovered with the above procedure, the 281 PCC MAY request a domain search list, as described in [RFC3397] and 282 [RFC3646], and use it as input to the DDDS application. 284 When the PCC does not find valid domain names using the procedures 285 above, it MUST stop the attempt to discover any PCE. 287 The dynamic rule described above SHOULD NOT be used for discovering 288 services other than Path computation services described in this 289 document, unless stated otherwise by a future specification. 291 The procedures defined here result in an IP address, PCE domain, 292 neighboring PCE domain and PCE Computation Scope where the PCC can 293 contact the PCE that hosts the service the PCC is looking for. 295 5.1. Determining the PCE Service and transport protocol 297 The PCC should know the service identifier for the Path Computation 298 Discovery service. The service identifier for the Path Computation 299 Discovery service is defined as "PCED", The PCE supporting "PCED" 300 service MUST support only TCP as transport, as described in 301 [RFC5440]. 303 The services relevant for the task of transport protocol selection 304 are those with NAPTR service fields with values "ID+M2X", where ID is 305 the service identifier defined in the previous section, and X is a 306 letter that corresponds to a transport protocol supported by the 307 domain. This specification only defines M2T for TCP. This document 308 also establishes an IANA registry for mappings of NAPTR service name 309 to transport protocol. 311 These NAPTR [RFC3403] records provide a mapping from a domain to the 312 SRV [RFC2782] record for contacting a PCE with the specific transport 313 protocol in the NAPTR services field. The resource record MUST 314 contain an empty regular expression and a replacement value, which 315 indicates the domain name where the SRV record for that particular 316 transport protocol can be found. As per [RFC3403], the client 317 discards any records whose services fields are not applicable. 319 The PCC MUST discard any service fields that identify a resolution 320 service whose value is not "M2T", for values of T that indicate TCP 321 transport protocols supported by the client. The NAPTR processing as 322 described in RFC 3403 will result in the discovery of the most 323 preferred transport protocol of the PCE that is supported by the 324 client, as well as an SRV record for the PCE. 326 5.2. Determining the IP Address of the PCE 328 As an example, consider a client that wishes to find PCED service in 329 the example.com domain. The client performs a NAPTR query for that 330 domain, and the following NAPTR records are returned: 332 Order Pref Flags Service Regexp Replacement 333 IN NAPTR 50 50 "s" "PCED" "" 334 _PCED._tcp.example.com 335 IN NAPTR 90 50 "s" "PCED+M2T" "" 336 _PCED._tcp.example.com 338 This indicates that the domain does have a PCE providing Path 339 Computation services over TCP, in that order of preference. Since 340 the client only supports TCP, TCP will be used, targeted to a host 341 determined by an SRV lookup of _PCED._tcp.example.com. That lookup 342 would return: 344 ;; Priority Weight Port Target 345 IN SRV 0 1 XXXX server1.example.com 346 IN SRV 0 2 XXXX server2.example.com 348 where XXXX represents the port number at which the service is 349 reachable. 351 Note that the regexp field in the NAPTR example above is empty. The 352 regexp field MUST NOT be used when discovering path computation 353 services, as its usage can be complex and error prone. Also, the 354 discovery of the path computation service does not require the 355 flexibility provided by this field over a static target present in 356 the TARGET field. 358 If the client is already configured with the information about which 359 transport protocol is used for a path computation service in a 360 particular domain, it can directly perform an SRV query for that 361 specific transport using the service identifier of the path 362 computation Service. For example, if the client knows that it should 363 be using TCP for path computation service, it can perform a SRV query 364 directly for_PCED._tcp.example.com. 366 Once the server providing the desired service and the transport 367 protocol has been determined, the next step is to determine the IP 368 address. 370 According to the specification of SRV RRs in [RFC2782], the TARGET 371 field is a fully qualified domain name (FQDN) that MUST have one or 372 more address records; the FQDN must not be an alias, i.e., there MUST 373 NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query 374 already has reported a sufficient number of these address records in 375 the Additional Data section of the DNS response (as recommended by 376 [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) 377 of the domain name, as appropriate. The result will be a list of IP 378 addresses, each of which can be contacted using the transport 379 protocol determined previously. 381 5.3. Determining path computation scope,capability,the PCE domains and 382 Neighbor PCE domains 384 DNS servers MAY use DNS TXT record to give additional information 385 about PCE service and add TXT record to the additional information 386 section that are relevant to the answer and have the same 387 authenticity as the data (Generally this will be made up of A and SRV 388 records)in the answer section. The additional information includes 389 path computation scope, capability, the PCE domains and Neighbor PCE 390 domains associated with the PCE. the PCC MAY inspect those Additional 391 Information section and be capable of handling responses from 392 nameservers that never fill in the Additional Information part of a 393 response. 395 5.4. Relationship between PCE-Domain and DNS Domain-Name 397 As per [RFC4655], PCE-Domain is a collection of network elements 398 within a common sphere of address management or path computational 399 responsibility. Examples of PCE-domains include Interior Gateway 400 Protocol (IGP) areas and Autonomous Systems (ASs). The DNS domain- 401 name should have a mechanism to link the IGP area or AS to the DNS 402 namespace. 404 Editors Note - To be discussed further 406 6. IANA Considerations 408 The usage of NAPTR records described here requires well-known values 409 for the service fields for the transport supported by Path 410 Computation Services. The table of mappings from service field 411 values to transport protocols is to be maintained by IANA. 413 The registration in the RFC MUST include the following information: 415 Service Field: The service field being registered. 417 Protocol: The specific transport protocol associated with that 418 service field. This MUST include the name and acronym for the 419 protocol, along with reference to a document that describes the 420 transport protocol. 422 Name and Contact Information: The name, address, email address, 423 and telephone number for the person performing the registration. 425 The following values have been placed into the registry: 427 Service Fields Protocol 428 PCED+M2T TCP 430 New Service Fields are to be added via Standards Action as defined in 431 [RFC5226]. 433 IANA is also requested to register PCED as service name in the 434 Protocol and Service Names registry. 436 7. Security Considerations 438 It is believed that this proposed DNS extension introduces no new 439 security considerations (i.e., A list of known threats to services 440 using DNS) beyond those described in [RFC3833]. For most of those 441 identified threats, the DNS Security Extensions [RFC4033] does 442 provide protection. It is therefore recommended to consider the 443 usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational 444 Practices [RFC6781] when deploying Path Computation Services. 446 In deployments where DNSSEC usage is not feasible, measures should be 447 taken to protect against forged DNS responses and cache poisoning as 448 much as possible. Efforts in this direction are documented in 449 [RFC5452]. 451 Where inputs to the procedure described in this document are fed via 452 DHCP, DHCP vulnerabilities can also cause issues. For instance, the 453 inability to authenticate DHCP discovery results may lead to the Path 454 Computation service results also being incorrect, even if the DNS 455 process was secured. 457 8. Acknowledges 459 The author would like to thank Claire Bi,Ning Kong, Liang Xia, 460 Stephane Bortzmeyer,Yi Yang, Ted Lemon and Adrian Farrel for their 461 review and comments that help improvement to this document. 463 9. References 465 9.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", March 1997. 470 [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of 471 services (DNS SRV)", RFC 2782, February 2000. 473 [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) 474 Domain Search Option", RFC 3397, November 2002. 476 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 477 Part Three: The Domain Name System (DNS) Database", 478 RFC 3403, October 2002. 480 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 481 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 482 December 2003. 484 [RFC4033] Arends, R., "DNS Security Introduction and Requirements", 485 RFC 4033, March 2005. 487 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 488 Element (PCE)-Based Architecture", RFC 4655, August 2006. 490 [RFC4674] Droms, R., "Requirements for Path Computation Element 491 (PCE) Discovery", RFC 4674, December 2003. 493 [RFC4848] Daigle, D., "Domain-Based Application Service Location 494 Using URIs and the Dynamic Delegation Discovery Service 495 (DDDS)", RFC 4848, April 2007. 497 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 498 Section in RFCs", RFC 5226, May 2008. 500 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 501 Communication Protocol (PCEP)", RFC 5440, April 2007. 503 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 504 Operational Practices, Version 2", RFC 6781, 505 December 2012. 507 [RFC6805] King, D. and A. Farrel, "The Application of the Path 508 Computation Element Architecture to the Determination of a 509 Sequence of Domains in MPLS and GMPLS", RFC 6805, 510 November 2012. 512 9.2. Informative References 514 [ALTO] Kiesel, S., "ALTO Server Discovery", 515 ID draft-ietf-alto-server-discovery-08, March 2013. 517 [BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and 518 TE Information using BGP", 519 ID draft-ietf-idr-ls-distribution-03, May 2013. 521 [PCE-QUESTION] 522 Farrel, A., "Unanswered Questions in the Path Computation 523 Element Architecture", 524 ID http://tools.ietf.org/html/draft-ietf-pce-questions-00, 525 July 2013. 527 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 528 Signature Option", RFC 2385, August 1998. 530 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 531 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 533 [RFC3833] Atkins, D., "Threat Analysis of the Domain Name System 534 (DNS)", RFC 3833, August 2004. 536 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 537 Computation Element (PCE) Discovery", RFC 5088, 538 January 2008. 540 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 541 Computation Element (PCE) Discovery", RFC 5089, 542 January 2008. 544 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 545 (ICE): A Protocol for Network Address Translator (NAT) 546 Traversal for Offer/Answer Protocols", RFC 5245, 547 April 2010. 549 [RFC5295] Touch, J., "The TCP Authentication Option", RFC 5295, 550 June 2010. 552 [RFC5382] Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382, 553 October 2008. 555 [RFC5452] Hubert, A., "Measures for Making DNS More Resilient 556 against Forged Answers", RFC 5452, January 2009. 558 Authors' Addresses 560 Qin Wu 561 Huawei 562 101 Software Avenue, Yuhua District 563 Nanjing, Jiangsu 210012 564 China 566 Email: sunseawq@huawei.com 568 Dhruv Dhody 569 Huawei 570 Leela Palace 571 Bangalore, Karnataka 560008 572 INDIA 574 Email: dhruv.dhody@huawei.com 576 Daniel King 577 Old Dog Consulting 578 UK 580 Email: daniel@olddog.co.uk 582 Diego R. Lopez 583 Telefonica I+D 585 Email: diego@tid.es