Network Working Group O. Lendl Internet-Draft enum.at Expires: December 25, 2006 June 23, 2006 The Domain Policy DDDS Application draft-lendl-domain-policy-ddds-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This documents proposes the use of the DNS to publish a domain's policy regarding incoming communication. The algorithm used is defined as a new application of the Dynamic Delegation Discovery System (DDDS). Such policy announcements can be used to facilitate selective SIP peering. Lendl Expires December 25, 2006 [Page 1] Internet-Draft Domain Policy DDDS June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DDDS Specification . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Application Unique String . . . . . . . . . . . . . . . . 5 3.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 5 3.3 Expected Output . . . . . . . . . . . . . . . . . . . . . 5 3.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . 5 3.4.1 Services Parameter . . . . . . . . . . . . . . . . . . 5 3.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 DNS considerations . . . . . . . . . . . . . . . . . . . . 7 4. Registration mechanism for policy-types . . . . . . . . . . . 7 4.1 Functionality Requirement . . . . . . . . . . . . . . . . 7 4.2 Naming requirement . . . . . . . . . . . . . . . . . . . . 8 4.3 Publication Requirements . . . . . . . . . . . . . . . . . 8 4.4 Registration Template . . . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Lendl Expires December 25, 2006 [Page 2] Internet-Draft Domain Policy DDDS June 2006 1. Introduction 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 [7]. The DNS [5] is widely used to map a domain name to the lower layer parameters needed to connect to the service offered by this domain. At a basic level, an A record maps a domain name to an IP address. MX and SRV [8] records offer application specific mappings and define sets of alternative routes and their associated priorities. NAPTR records as used in RFC 3263 [4] provide even more abstraction: They announce over which transport protocol a Session Initiation Protocol (SIP [9]) server prefers to be contacted. This document defines another abstraction: Even if the service is announced by MX or SRV records and suitable A (or AAAA) records, access controls may apply. Not all URIs are reachable to anybody on the public Internet. Access restrictions can be implemented on various layers (IP, TLS, Application) and due to various reasons (technical, security, commercial, ...). Somebody wanting to use the service announced by MX or SRV records has usually no means to find out whether his connection will be accepted other than by trying to connect. Such trial and error behavior is good enough for most applications, but in some cases it is vital that the service can announce to prospective clients the conditions under which a connection attempt is likely to succeed. This is mainly relevant for applications with the following properties: o Real-time services: Any delay in establishing the connection is visible (and annoying) to the user. Waiting for a timeout is no problem for an email transmission or a background file transfer. This is an issue for interactive applications like e.g. web or VoIP services. o Alternatives exist: If there are multiple technical ways to fulfill the customer's request then a fail-over from one method to another is possible. The sooner the sender knows that the first method he tries will fail, the earlier he can switch to the alternative. The prime example for such an application is VoIP peering: Users are very sensitive to delays in the call-setup time, thus the originating network should not waste time on fruitless tries to reach the destination network via a direct SIP call. Currently the public Lendl Expires December 25, 2006 [Page 3] Internet-Draft Domain Policy DDDS June 2006 switched telephone network (PSTN) acts as a backup interconnection network over which VoIP networks based on E.164 telephone number can interconnect. This document thus defines a protocol with which a domain can announce its policies regarding incoming communications for a specific protocol. 2. Policy Rules The Domain Policy DDDS Application is built upon the concept of atomic policy rules. Complex policies are defined as a boolean combination of individual rules. This document does not define the semantics of any individual rule, this will be done by companion documents. Individual policy rules in the Domain Policy framework are expressed as Uniform Resource Identifiers (URI, RFC 2396 [1]). URIs can be used both as compact identifiers for standards (using e.g. "urn:ietf:rfc:XXXXX", "http://sippeering.example.com/release1") as well as URLs pointing to more elaborate policy statements. Using URIs as identifiers is a common technique in the XML world. See for example XML namespaces [12] or XML DSIG [13] (1.3). The fact that these URIs are often URLs may be a bit confusing at first. Clients are not supposed to fetch and interpret the document to which these URLs refer to. These URLs are just convenient as unique and descriptive identifiers. Simple protocol parameters (e.g. a list of X.509 CAs) can be included into the policy rule URI (e.g. in the query part) itself. If the simple boolean logic and the limited space in the DNS answers are insufficient for an application then a type of policy rule URIs can be defined which links to policy statements written in a fully featured policy description language like SAML [14] or XACML [15]. To link individual policy rules into one complex policy the disjunctive normal form of boolean logic is used. In simple words: The policy is written as a set of valid (according to the policy) alternatives. These alternatives may themselves consist of individual rules which must all be fulfilled to yield a positive result. 3. DDDS Specification This section contains the formal definition of the Domain Policy DDDS application according to RFC 3401 [2]. Lendl Expires December 25, 2006 [Page 4] Internet-Draft Domain Policy DDDS June 2006 RFC 3401 describes DDDS as follows: The Dynamic Delegation Discovery System is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. The Domain Policy DDDS Application maps a domain name and a protocol name to an ordered boolean expression of atomic policy rules. It does not define how individual rules should be interpreted (except that unknown rules must be regarded as not fulfilled). It defines how these rules are retrieved and how they are combined and processed. As a domain's policy may be different for the various protocols (e.g. SMTP vs. SIP), the name of the protocol is another input into the DDDS application. 3.1 Application Unique String The Application Unique String is the URI which describes the service the originating network wants to access. Examples: "sip:user@example.com", "mailto:sales@example.org" 3.2 First Well Known Rule The First Well Known Rule extracts the domain part of the URI. This key thus has the form of a fully qualified domain name. 3.3 Expected Output The Expected Output of this algorithm is a set of URIs which describe the conditions the sender can fulfill. 3.4 Valid Databases This DDDS application uses the DNS as the database as defined in RFC 3403 [3]. The rewriting rules are stored in NAPTR DNS resource records. As the key is already in the form of a FQDN, no transformations are necessary. 3.4.1 Services Parameter The "services" field in the NAPTR record is used to Lendl Expires December 25, 2006 [Page 5] Internet-Draft Domain Policy DDDS June 2006 o identify this NAPTR as part of the Domain Policy DDDS application, o define to which protocol this policy applies to, and o identify which type of policy is contained in this record. This document does not define actual policy types, that is left to companion documents. The formal specification for the service field is as follows: service-field = "D2P+" protocol *1policy protocol = 1*32(ALPHA / DIGIT) policy = ":" policy-type policy-type = 1*32(ALPHA / DIGIT) In other words, the service-type starts with "D2P+" (which marks this as part of the Domain Policy DDDS) followed by the name of the protocol to which this policy applies to (e.g. "sip", "xmpp", "smtp", ...). Optionally the policy-type (which follows after a colon) indicates what kind of policy rule is contained in the regexp field. All matching operations on the service-field MUST be done in a case- insensitive way. The Domain Policy DDDS Application client MUST ignore all records where the protocol in the service-field does not match the protocol for which the policy is sought. 3.4.2 Flags The "flags" field in the NAPTR record signals when the DDDS algorithm has finished. An empty (non-existent) flag means that this rule is non-terminal and the client MUST use the key resulting from this rule as the input into a new DDDS loop. Such non-terminal NAPTRs MUST NOT contain a policy-type element in the service-field. A flag containing "U" signals that the algorithm has found a valid policy record for this domain. This rule MUST be considered in conjunction with all other rule which share the same protocol (from the service-field), the same flag and the same order field. If the client can determine that he is able to fulfill all the requirements in this set of atomic rules then the DDDS algorithm terminates and the result is this set of rules. If the policy-type of a rule is not known to the client it MUST consider this rule as not fulfill-able. No other values for the flag field are defined as of now and clients MUST ignore all records not containing either "U" or and empty flag Lendl Expires December 25, 2006 [Page 6] Internet-Draft Domain Policy DDDS June 2006 field. The treatment of the "order" and "preference" fields as defined here deviates slightly from RFC 3403. The reason is that this DDDS application does not return a single URI as found in a single NAPTR record but a set of URIs which are generated by grouping NAPTR records based on their "order" field. The "preference" field is not evaluated. 3.5 DNS considerations The NAPTR records containing the policy announcements for a domain can be quite large for DNS responses, especially if elaborate rules are used or if this mechanism is used for more than one protocol. To accommodate these larger DNS responses the DNS servers and the clients MUST utilize EDNS0 [6] to minimise fall-backs to TCP queries. This requirement is the equivalent of [11]. Storing policy rules directly in the DNS is very efficient as long as the rule-set is small. One must take care not to overload this database. If more elaborate rules are needed it is recommended to use the DNS only to refer to a policy statement stored elsewhere. 4. Registration mechanism for policy-types The service-field of the NAPTR records used in this document contain three fields: o The constant string "D2P". o The protocol name. Protocol names are to be taken from the IANA registry at http://www.iana.org/assignments/port-numbers. No new registry functions are needed for this field. o The policy-type. This field indicates the interpretation rules for the URI contained in the NAPTR record. An IANA registration procedure is thus needed for this field. New entries in the IANA policy-type registry need to specify not only the name of the new policy-type, but also need to include the allowed URI schemes, a functional specification on how to interpret the URI, security considerations, intended usage, and any other information needed for to evaluate policy rules of this type. In order to be a registered policy-type, the entire specification, including the template, requires approval by the IESG and publication of the policy-type registration specification as an RFC. 4.1 Functionality Requirement A registered policy-type acts as selector within the policy Lendl Expires December 25, 2006 [Page 7] Internet-Draft Domain Policy DDDS June 2006 evaluation engine of the client. The specification in the registration MUST be sufficient such that the client can determine whether he can fulfill the policy requirements encoded in the URI. Specifically, a registered policy-type MUST specify the URI scheme(s) that may be used, and, when needed, other information which will have to be transferred into the policy evaluation process itself. 4.2 Naming requirement Registered policy-types must by unique and conform to the ABNF specified in Section Section 3.4.1, and MUST NOT start with the facet "X-" which is reserved for experimental, private use. 4.3 Publication Requirements Proposals for policy-type registrations MUST be published as one of the following documents; RFC on the Standards Track, Experimental RFC, or as a BCP. IANA will retain copies of all policy-type registration proposals and "publish" them as part of the policy-type Registration tree itself. 4.4 Registration Template Policy Type: URI Scheme(s): Functional Specification: Security considerations: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author: Any other information that the author deems interesting: 5. Examples In order to give meaningful examples, we need to define a few types of rules. The definitions here are purely meant to illustrate the possibilities. They MUST NOT be considered as valid examples of real entries. Lendl Expires December 25, 2006 [Page 8] Internet-Draft Domain Policy DDDS June 2006 o The policy-type "fed" shall indicate that the URI denotes a federation of service providers. All members of a federation know how to talk to each other. o The policy-type "std" shall indicate that the URI indicates a standard the sender has to fulfill. o A record with policy-type "saml" shall contain an URL of a SAML document which contains further policy information. NAPTR records in zone-file format can exceed the line-length restrictions of the I-D document format. In these cases a backlash at the end of a line will indicate that the following line should be read as part of preceding line. o In this example "customer.example.org" is a customer domain for which the service-provider "example.com" hosts the SIP server. Thus the policy for incoming SIP calls for customer.example.org is in effect the one from example.com. $ORIGIN customer.example.org. ; order pref flags service regexp replacement IN NAPTR 10 50 "" "D2P+SIP" "" example.com. Please note that there is no policy-type in this record. The protocol name is needed though, as e.g. this customer could have his email hosted at a different provider and thus refer to a different domain with a "D2P+SMTP" NAPTR. o In the second example the SIP services at "example.com" is only reachable via a private interconnection arrangement maintained by a federation called "http://sipxconnect.example.org/". $ORIGIN example.com. IN NAPTR 10 50 ( ; order priority "U" "D2P+SIP:fed" ; flags service "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl ) o In the next example the "example.com" also allows incoming connections as long they use SIP over TLS. Calls via the federation are preferred. Lendl Expires December 25, 2006 [Page 9] Internet-Draft Domain Policy DDDS June 2006 $ORIGIN example.com. IN NAPTR 10 50 ( ; order priority "U" "D2P+SIP:fed" ; flags service "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl ) IN NAPTR 20 10 ( ; order priority "U" "D2P+SIP:std" ; flags service "!^.*$!urn:ietf:rfc:2246!" . ; regexp repl ) o If the carrier example.com only accepts SIP calls (in addition to PSTN interconnect) if the PSTN emulation is good, he might publish a policy like this: $ORIGIN example.com. ; order pref flags service regexp replacement IN NAPTR 10 10 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3578!" . IN NAPTR 10 11 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3666!" . IN NAPTR 10 12 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3960!" . o A restrictive SIP service might only accept calls from peers from two federations, while subjecting calls from the public Internet to a complex policy. The policy records could look like this: $ORIGIN example.com IN NAPTR 10 10 ( ; order priority "U" "D2P+SIP:fed" ; flags service "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl ) IN NAPTR 20 10 ( ; order priority "U" "D2P+SIP:fed" ; flags service "!^.*$!http://sip.federation.com/!" . ; regexp repl ) IN NAPTR 30 10 ( ; order priority "U" "D2P+SIP:saml" ; flags service "!^.*$!http://www.example.com/sip-policy.saml!" . ) 6. Security Considerations The publishing of the access policy via the DNS RR described in this draft will reduce the amount of unwanted communication attempts, as all well-meaning clients will follow them, but these records cannot substitute measures to actually enforce the published policy. In the case of SIP Peering, the NAPTRs proposed here publish Lendl Expires December 25, 2006 [Page 10] Internet-Draft Domain Policy DDDS June 2006 information which is not public if service providers just rely on private interconnection agreements. These records are similar to the public routing registries for BGP4 as maintained by the RIRs. They are just records indicating who peers with whom but do not hold details on how the interconnection is achieved. The published technical requirements for incoming calls could be used by malicious callers to find possible attack vectors. 7. IANA Considerations This document defines an IANA registry for the policy-type field. See Section 4. 8. Acknowledgements The author would like to thank Richard Shockey, Michael Haberler, Alexander Mayrhofer, Richard Stastny, and John Todd for their contributions. 9. References 9.1 Normative References [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. 9.2 Informative References [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Lendl Expires December 25, 2006 [Page 11] Internet-Draft Domain Policy DDDS June 2006 [8] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [10] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [11] Conroy, L. and J. Reid, "ENUM Requirement for EDNS0 Support", draft-conroy-enum-edns0-01 (work in progress), October 2005. [12] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999. [13] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", W3C REC REC-xmldsig-core-20020212, February 2002. [14] Maler, E. and J. Hughes, "Security Assertion Markup Language (SAML) V2.0 Technical Overview", July 2005. [15] Godik, S. and T. Moses, "OASIS eXtensible Access Control Markup Language (XACML)", OASIS Committee Working Draft xacml-schema- policy, July 2002, . Author's Address Otmar Lendl enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria Phone: +43 1 5056416 33 Email: otmar.lendl@enum.at URI: http://www.enum.at/ Lendl Expires December 25, 2006 [Page 12] Internet-Draft Domain Policy DDDS June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lendl Expires December 25, 2006 [Page 13]