Network Working Group A. Newton Internet-Draft L. Daigle Expires: August 23, 2003 VeriSign, Inc. February 22, 2003 Lightweight Internet Registry Information Service draft-newton-iris-lightweight-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 23, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The memo defines a lightweight version of the Internet Registry Information Service (IRIS) layered on UDP. Newton & Daigle Expires August 23, 2003 [Page 1] Internet-Draft draft-newton-iris-lightweight-00 February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use of IRIS-LW . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Server Discovery . . . . . . . . . . . . . . . . . . . . . . 3 2.2 IRIS-LW Packet Formats . . . . . . . . . . . . . . . . . . . 4 2.3 IRIS-LW Transactions . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Client behaviour . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2 Server behaviour . . . . . . . . . . . . . . . . . . . . . . 6 3. IRIS-LW Operations . . . . . . . . . . . . . . . . . . . . . 6 3.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Newton & Daigle Expires August 23, 2003 [Page 2] Internet-Draft draft-newton-iris-lightweight-00 February 2003 1. Introduction The Internet Registry Information Service (IRIS [3]) defines a CRISP [5] compliant administrative information service for Internet registries. However, there exist situations where the particular needs of an Internet registry operator may be met with a lightweight version of IRIS. In order to meet the requirements of CRISP, IRIS uses BEEP [1] over TCP to accomplish such tasks as authentication and encryption. These tasks are almost impossible to conduct over UDP. However, there do exist certain use cases which do not need these features. Based on the needs and policies of an Internet registry, these profiled cases may be conducted over a faster, more lightweight UDP-based protocol. It is not the intent of this memo to suggest an alternative to the full IRIS protocol, but to offer an additional method for serving IRIS data should an Internet registry determine that this method can meet some of their needs. This memo describes a procedure allowing an Internet registry to deploy both versions of IRIS. An Internet registry should determine their ability to use this lightweight version based on the following criteria: 1) no access controls are needed and all access is considered anonymous, 2) no encryption or privacy is needed, and 3) the expected queries produce results with small amounts of data. Specifically, each communication (query or response) is required to fit in a single UDP packet. To accomplish a lightweight administrative access service, this slimmed down use of IRIS uses XML that has undergone GZIP [2] compression. However, the schemas used by this lightweight version are the same as used in the full version of IRIS. For the purposes of describing this profiled use of UDP in comparison with IRIS delivered over BEEP/TCP, this document will refer to IRIS over BEEP/TCP as "IRIS-BEEP", the core schemas and operations of IRIS as "IRIS", and this document's specification of lightweight IRIS over UDP as "IRIS-LW". 2. Use of IRIS-LW 2.1 Server Discovery As defined above, IRIS-LW is intended as a complement to the full IRIS protocol. While there may be cases where IRIS-LW suffices to handle all legitimate queries for a service, the expected use case is to have an IRIS-LW server providing rapid short answers to a subset of queries to a service, with a fallback to a standard IRIS server for full service. Newton & Daigle Expires August 23, 2003 [Page 3] Internet-Draft draft-newton-iris-lightweight-00 February 2003 This can be reflected in SRV records for the service. A client seeking the short answer service will look up the SRV record for _iris-lw._udp in the target domain: _iris-lw._udp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com IN SRV 20 0 10001 secondary.example.com IN SRV 30 0 10001 nuclearfallout.example.com.au A client seeking the full service, or a client that has been redirected by the IRIS-LW server (because the full answer is not available from the IRIS-LW server) will look up the SRV record for _iris._tcp in the target domain: _iris._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 www.example.com IN SRV 20 0 10001 www1.example.com IN SRV 30 0 10001 nuclearfallout.example.com.au These examples are meant to illustrate the expectation that the UDP based servers may be part of a high (transaction) volume server cluster maintained independently of the domain's main WWW, e-mail, or other (TCP) services. 2.2 IRIS-LW Packet Formats The UDP packet format for IRIS-LW is as follows: 0 16 31 +--------------------+--------------------+ | Src Port | Dst Port | +--------------------+--------------------+ | Checksum | Length | +--------------------+--------------------+ | Data: GZIP'ed XML instance | | compliant with IRIS-LW | | schema defined above | | | (...) | | +-----------------------------------------+ Again, each IRIS-LW query and response is contained in a single UDP packet. If no length information is contained in the IRIS-LW query, servers should assume a packet size limitation of 512 bytes. Newton & Daigle Expires August 23, 2003 [Page 4] Internet-Draft draft-newton-iris-lightweight-00 February 2003 2.3 IRIS-LW Transactions 2.3.1 Client behaviour To initiate an IRIS-LW query, a client sends a UDP datagram to the identified IRIS-LW port on the destination server. As outlined above, the UDP packet payload is the byte sequence obtained by applying GZIP to a valid IRIS-LW XML query instance. The client then waits for a reply from the server on the same port from which it sent the query packet. The timeout waiting for a reply is at the discretion of the client. As an example, the client may send the following XML to the server: After GZIP compression, the client sends a UDP payload similar to the following: Newton & Daigle Expires August 23, 2003 [Page 5] Internet-Draft draft-newton-iris-lightweight-00 February 2003 0000:0000 1f 8b 08 08 87 fe 57 3e 00 03 69 72 69 73 6c 77 0000:0010 2d 6c 6f 6f 6b 75 70 2e 78 6d 6c 00 8d 91 31 6f 0000:0020 85 20 14 85 77 7f 05 61 57 c4 2e 0d d1 b7 bc 74 0000:0030 7b ed d0 d7 a1 2b 41 aa e4 21 58 ee 35 ea bf 2f 0000:0040 a2 6d d2 0e 6d 99 b8 27 df e1 70 a0 b6 f3 b3 7e 0000:0050 9f 34 60 46 c8 32 58 07 0d 9d 82 13 46 e3 9b 18 0000:0060 65 90 03 88 28 0b 07 c2 04 03 b9 9d 39 fd 24 c5 0000:0070 02 a6 a1 3d e2 28 18 9b e7 b9 98 ef 0a 1f 3a 56 0000:0080 95 25 67 af 8f 97 ab ea f5 20 73 e3 00 a5 53 3a 0000:0090 f9 c0 08 48 f2 c5 2b 89 c6 bb 3f e3 48 b4 1d fb 0000:00a0 62 81 96 fc 82 f3 04 6e 14 dd 5c 56 bb 0e fb 86 0000:00b0 f2 ea be a4 a7 2c 2a 75 d8 bb fe a3 29 8f 0e b2 0000:00c0 9d 12 5d a0 65 50 fd 55 e3 29 cd 51 b1 de df a6 0000:00d0 f1 c1 a1 c1 f5 d0 08 09 ba 33 80 61 7d 59 47 dd 0000:00e0 d0 36 8e e9 ad f6 a5 13 7b b6 12 62 ae f2 0e a5 0000:00f0 c2 bc 97 ae b5 fa 27 f4 24 87 e8 1f e4 ad e2 94 0000:0100 b0 3d b3 66 df 2e b1 75 61 47 99 d8 ac 66 5f df 0000:0110 78 ca 3e 00 27 87 1e 9e d3 01 00 00 Before compression, the payload is 467 bytes. After compression, the payload is 284 bytes. 2.3.2 Server behaviour Upon receipt of an IRIS-LW query, the server will un-GZIP the UDP packet payload, carry out whatever processing is appropriate, create a valid IRIS-LW XML response instance to the query, and apply GZIP to that instance. If the resulting size is greater than the maximum size provided in the query (or 512 bytes if no maximum size was provided), the server will respond with a GZIP'ed instance of IRIS-LW response XML indicating the response was too large. The response is sent as a UDP datagram to the source address and port of the original query. The server's responsibility for addressing a query ends with the transmission of the UDP response datagram. 3. IRIS-LW Operations The XML in the following sections is descriptive of the formal XML syntax described in Section 4. For each request type, there is one or more response types. The following shows a brief summary: o * Newton & Daigle Expires August 23, 2003 [Page 6] Internet-Draft draft-newton-iris-lightweight-00 February 2003 o * an IRIS response. * containing * containing 3.1 Requests IRIS-LW requests use the formal syntax specified in Section 4. There are two types of IRIS-LW requests: o a profile request o an IRIS request The profile request simply uses the element. An IRIS request is wrapped in an element. This element has an OPTIONAL 'length' attribute containing a positive integer. This attribute indicates the allowable length of the response in bytes. It allows clients that have an understanding of their UDP path to specify how long the response should be. Clients that do not care about UDP fragmentation may set this number arbitrarily high. If this attribute is not present, servers SHOULD assume a length of 512 bytes. The following is an example of an IRIS request with a query in the 'dreg1' registry-type. Newton & Daigle Expires August 23, 2003 [Page 7] Internet-Draft draft-newton-iris-lightweight-00 February 2003 com The Cobbler Shoppe 3.2 Responses The IRIS-LW responses come in two flavors: o a response o a response The response MUST be returned by the server when a client issues a request. The element contains children. Each child element contains an IRIS profile as defined by IRIS-BEEP [4]. The following is an example of a response. Newton & Daigle Expires August 23, 2003 [Page 8] Internet-Draft draft-newton-iris-lightweight-00 February 2003 http://iana.org/beep/transient/crisp/iris1/dreg1 The response MUST be sent by the server to the client in reply to an . It contains one of three types of content: o an IRIS response o an error indicating the IRIS request was for an unsupported profile. o an error indicating the IRIS response was too large to send. An containing an IRIS response simply contains the IRIS response to the appropriate IRIS request. The following is an example of 'dreg1' IRIS response. thecobblershoppe.com Newton & Daigle Expires August 23, 2003 [Page 9] Internet-Draft draft-newton-iris-lightweight-00 February 2003 assignedAndActive When a client makes an IRIS request for a profile that is not supported by the server, the server MUST return an indicating that an error has occured. This is done with the child element. To signal this condition, the element MUST contain the element. Here is an example: http://iana.org/beep/transient/crisp/iris1/dreg1 When a client makes an IRIS request that yields a response too large to fit in the negotiated UDP packet, the server MUST respond with an indicating that a size error has occured. This is done with the child element. To signal this condition, the element MUST contain a element. The content of the element is a positive integer stating the size of the IRIS response. Upon receiving this error, a client has the following options: o Requery over IRIS-BEEP. Newton & Daigle Expires August 23, 2003 [Page 10] Internet-Draft draft-newton-iris-lightweight-00 February 2003 o Requery over IRIS-LW using a larger 'length' indicator. o Signal an error. The following is an example of a length error: 2652 4. Formal XML Syntax The following is the XML Schema used to define IRIS-LW operations. Lightweight (LW) Internet Registry Information Service (IRIS) Schema v1 Newton & Daigle Expires August 23, 2003 [Page 11] Internet-Draft draft-newton-iris-lightweight-00 February 2003 5. IANA Considerations This will eventually include anything necessary to make "iris-lw" a valid protocol token for use with SRV records. 6. Security Considerations IRIS-LW is intended for serving public data; it provides no in-band mechanisms for authentication or encryption. Any application that needs that must provide out of band mechanisms to provide it (e.g., IPSec), or use the full IRIS protocol. References [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC Newton & Daigle Expires August 23, 2003 [Page 12] Internet-Draft draft-newton-iris-lightweight-00 February 2003 3080, March 2001. [2] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L. and G. Randers-Pehrson, "GZIP file format specification version 4.3", RFC 1952, May 1996. [3] Newton, A., "Internet Registry Information Service", draft-ietf-crisp-iris-core-01 (work in progress), November 2002. [4] Newton, A., "Internet Registry Information Service (IRIS) over Blocks Exstensible Exchange Protocol (BEEP)", draft-ietf-crisp-iris-beep-01 (work in progress), November 2002. [5] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-00 (work in progress), August 2002. [6] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [7] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, . [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, . [9] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . Authors' Addresses Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US EMail: anewton@verisignlabs.com; anewton@ecotroph.net Newton & Daigle Expires August 23, 2003 [Page 13] Internet-Draft draft-newton-iris-lightweight-00 February 2003 Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US EMail: leslie@verisignlabs.com; leslie@thinkingcat.com Newton & Daigle Expires August 23, 2003 [Page 14] Internet-Draft draft-newton-iris-lightweight-00 February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Newton & Daigle Expires August 23, 2003 [Page 15] Internet-Draft draft-newton-iris-lightweight-00 February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Newton & Daigle Expires August 23, 2003 [Page 16]