XMPP Hirotaka Sato Internet-Draft Nobuo Ogashiwa Intended Status: Informational Maebashi Kyoai Gakuen College Expires: September 10, 2010 March 9, 2010 Considerations of software generated message on XMPP draft-sato-xmpp-software-message-01 Abstract In RFC2779 [RFC2779] and RFC2778 [RFC2778], XMPP [RFC3920] client is defined as "PRINCIPALS are the people, groups, and/or software in the "real world" outside the system that use the system as a means of coordination and communication. Considering this description, it does not matter whether the user of end node is human or software. However, current specification of XMPP is expected that there will be a human in front of the client. So, there is no consideration for looping the message between softwares and processing message that human will not be able to react. Recently system and software are replying in return of human. Moreover, by making client act like a human, new network service can be made. There are many of these called "bots" already, but there is a possibility which can aggregate or control remote resources.By clarifying models of usage and problem, this document aims to use XMPP in software-to-software and human-to-software models not only human-to-human model. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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." Sato, et al. Expires September 2, 2010 [Page 1] Internet-Draft XMPP Software Message March 2010 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 September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Models of usage of XMPP . . . . . . . . . . . . . . . . . . . . 3 2.1 Basic Models . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Possible model of MUC . . . . . . . . . . . . . . . . . . . . 4 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 message loop problem . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Overview of the problem . . . . . . . . . . . . . . . . . . 5 3.1.2 Proposed Solutions . . . . . . . . . . . . . . . . . . . . 5 3.2 Receiving / Sending Many Messages from Many Clients . . . . . 5 3.2.1 Overview of the problem . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Sato, et al. Expires September 2, 2010 [Page 2] Internet-Draft XMPP Software Message March 2010 1. Background Extensible Messaging and Presence Protocol has been designed for sending presence and instant messaging. XMPP are expected using in high latency, low bandwidth and possibly intermittent connectivity such as mobile wireless access. According to the definition of RFC 2778, PRINCIPAL are people, groups, and/or software. These days bots and agent softwares are sending message as a transport protocol. For example, some TV boxes uses XMPP between Remote and box. XMPP can be used to as a messaging protocol for machine to machine communication. For this usage, fail-proofed will be a good thing for developer of clients. 2. Models of usage of XMPP 2.1 Basic Models Before start discussing the problem, we would like to define 3 models which will be useful to imagine what is happening in next chapter. In this document, we will discuss following models o Human to Human When both PRINCIPALs are human, communication between them are just as current usage. This is current basic model of jabber instant messaging. o Humans to Software Think of a model one side of principal is a software and the other side is human. o Software to Software Both principal is software. Messages and presence are handled by only software which run at both side. Sato, et al. Expires September 2, 2010 [Page 3] Internet-Draft XMPP Software Message March 2010 2.2 Possible model of MUC Considering MUC, there can be following models, but these will not be covered by this document. Human, Few Software, Many Software Human ---, MUC-case-1, MUC-case-2 Few Software MUC-case-1, MUC-case-3, MUC-case-4 Many Software MUC-case-2, MUC-case-4, MUC-case-4 a) Humans-to-Few Softwares (MUC-case-1) A Human / Humans who participate want to see what is going on between software. Softwares are running out of control and sending many messages. Software will crash itself. b) Humans-to-Many Softwares (MUC-case-2) A Human / Humans who participate want to read what is going on between few software. Softwares are distributed in many locations. Softwares are running out of control and sending many messages. Server will be threaten by messages and some server will not be able to provide service. Human will not be able to read. If the server of principal are various servers will be needed to act along with other servers. c) Few Software-to-Few Software (MUC-case-3) Softwares are distributed in many locations. Softwares are running out of control and sending many messages. Softwares will crash itself. Maybe human will not notice this. d) Many Software-to-Many Software (MUC-case-4) Softwares are running out of control and sending many messages. Server will be threaten by messages and some server will not be able to provide service. Softwares will crash itself. If the server of principal are various servers will be needed servers will be needed to act along with other servers. Maybe human will not notice this. Sato, et al. Expires September 2, 2010 [Page 4] Internet-Draft XMPP Software Message March 2010 3. Problems From above models, we will discuss what will happen and what will be a problem. This document points out what the problem is. Solutions are out of scope. 3.1 Message loop problem One major problem occurs when too many messages are sent in short time. This problem when software sends human a message and the software has a bug which sends continuously, most likely the client software of human will crash. 3.1.1 Overview of the problem When both principals are software, there is always a risk that messages will be sent too many messages (like looping or bug or etc.) One example is when software echoes messages of sender, it will reply continuously. This will leads heavy traffic and possibly sender will not handle this. In Human-Human model, it will not be a big issue because PRINCIPAL can just shutdown the client program, but in other cases it is not easy to do so. In some cases, this problem can be solved by more care of programmers but the problem remains. By this mean, there should be a mechanism which does not allow or detect looping problem. 3.1.2 Proposed Solutions There are several solutions which can deal with above problem. a) Avoidance / Detection There is a possibility which can avoid looping by extending XMPP. One example solution is that settling server will not allow message which is looping. 3.2 Receiving / Sending Many Messages from Many Clients 3.2.1 Overview of the problem In some cases, softwares send and receive messages which human will not be able to read. However when massive number of PRINCIPAL is connecting the XMPP server, it is like a DoS attack. Furthermore, when one server receives too many messages it will be like a distributed denial of service (DDoS) even if the messages themselves are small. In this situation, there is a possibility that resources (CPU, Memory, bandwidth and so on) of server and specific PRINCIPAL will not be able to continue connection. Sato, et al. Expires September 2, 2010 [Page 5] Internet-Draft XMPP Software Message March 2010 4. Security Considerations This document has no requirement for a change to the security models within associated protocols. 5. IANA Considerations TBD 6. References 6.1. Normative References [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and Instant Messaging", RFC2778, February 2000 [RFC2779] M. Day, S. Aggarwal, G. Mohr, J. Vincent., "Instant Messaging / Presence Protocol Requirements", RFC2779, February 2000 [RFC3920] P. Saint-Andre, Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", October 2004 6.2. Informative References Authors' Addresses Hirotaka Sato Maebashi Kyoai Gakuen College 1154-4 Koyahara-machi Maebashi City, Gunma Pref JAPAN 3792192 EMail: satohi07@c.kyoai.ac.jp URI: http://www.kyoai.ac.jp/ Nobuo Ogashiwa Maebashi Kyoai Gakuen College 1154-4 Koyahara-machi Maebashi City, Gunma Pref JAPAN 3792192 EMail: ogashiwa@c.kyoai.ac.jp URI: http://www.kyoai.ac.jp/ Sato, et al. Expires September 2, 2010 [Page 6]