<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE xep SYSTEM 'xep.dtd' [ <!ENTITY % ents SYSTEM 'xep.ent'> %ents; ]> <?xml-stylesheet type='text/xsl' href='xep.xsl'?> <xep> <header> <title>Problem Reporting</title> <abstract>This specification defines methods for reporting of network problems between XMPP server deployments.</abstract> &LEGALNOTICE; <number>xxxx</number> <status>ProtoXEP</status> <type>Standards Track</type> <sig>Standards</sig> <approver>Council</approver> <dependencies> <spec>XMPP Core</spec> </dependencies> <supersedes/> <supersededby/> <shortname>NOT_YET_ASSIGNED</shortname> <discuss>operators</discuss> <author> <firstname>Artur</firstname> <surname>Hefczyc</surname> <email>artur.hefczyc@gmail.com</email> <jid>artur.hefczyc@tigase.org</jid> </author> <author> <firstname>Florian</firstname> <surname>Jensen</surname> <email>admin@flosoft.biz</email> <jid>admin@im.flosoft.biz</jid> </author> <author> <firstname>Mickaël</firstname> <surname>Rémond</surname> <email>mickael.remond@process-one.net</email> <jid>mremond@process-one.net</jid> </author> &stpeter; <author> <firstname>Matthew</firstname> <surname>Wild</surname> <email>mwild1@gmail.com</email> <jid>mwild1@jaim.at</jid> </author> <revision> <version>0.0.1</version> <date>2009-04-13</date> <initials>psa</initials> <remark><p>First draft.</p></remark> </revision> </header> <section1 topic='Introduction' anchor='intro'> <p>As XMPP technologies have been deployed more widely, the open XMPP network has become a more significant target for attacks. This specification defines ways for XMPP server deployments to share information with each other and therefore handle such attacks in a more real-time fashion.</p> <p>The basic approach is two-fold:</p> <ol start='1'> <li>Each server SHOULD mantain a list of other servers that it trusts for the purpose of problem reporting. We can think of this list as the server-to-server equivalent of a user-oriented XMPP roster.</li> <li>When a server encounters problems (e.g., suspicious account registrations), it SHOULD send a problem report to the servers on its "roster".</li> </ol> </section1> <section1 topic='Server Rosters' anchor='roster'> <p>To establish a trust relationship with a peer, a server shall send a presence subscription request to the peer, just as is done between XMPP users.</p> <example caption="Service sends subscription request to peer"><![CDATA[ <presence from='montague.lit' to='capulet.lit' type='subscribe'/> ]]></example> <p>The XMPP server software running at the peer MUST prompt the server administrators to approve the request. Methods for doing so are out of scope for this specification.</p> </section1> <section1 topic='Problem Reports' anchor='report'> <p>A problem report consists of an XMPP &MESSAGE; stanza containing a <problem/> child element. The following is an example.</p> <example caption="A problem report"><![CDATA[ <message from='jabber.org' to='im.flosoft.biz'> <problem xmlns='urn:xmpp:problem:0' <contact>stpeter@jabber.org</contact> <end>2009-04-13T19:27:22Z</end> <incident>cc7b247b-18b4-4301-b6d0-e9e4016d802f</incident> <ip>192.0.2.0</ip> <jids> <jid>abuser@spam.lit</jid> <jid>loser@spam.lit</jid> </jids> <room>operators@conference.jabber.org</room> <severity>2</severity> <start>2009-04-13T19:05:20Z</start> <text xml:lang='en'>lots of MUC spammers from abuse.lit!</text> <type>muc</type> </message> ]]></example> <p>The defined child elements are as follows:</p> <table caption='Child elements'> <tr> <th>Element Name</th> <th>Description</th> </tr> <tr> <td><contact/></td> <td>The JID of a person to contact directly.</td> </tr> <tr> <td><end/></td> <td>The time when the problem ended. Send empty element if still happening. Must conform to &xep0082;</td> </tr> <tr> <td><incident/></td> <td>An incident number. MUST be a UUID as described in &rfc4122;.</td> </tr> <tr> <td><ip/></td> <td>The IP address where the problem originates.</td> </tr> <tr> <td><jids/></td> <td>Each <jid/> child contains the JabberID of an entity that is causing trouble.</td> </tr> <tr> <td><room/></td> <td>A chatroom where the problem can be discussed.</td> </tr> <tr> <td><severity/></td> <td>The seriousness of the problem, from 5 (least serious) to 1 (most serious).</td> </tr> <tr> <td><start/></td> <td>The time when the problem started. Send empty element if unknown.</td> </tr> <tr> <td><text/></td> <td>A natural-language description of the event. This element SHOULD possess an 'xml:lang' attribute. Multiple <text/> elements MAY be included, each with a different 'xml:lang' value.</td> </tr> <tr> <td><type/></td> <td>The type of problem. Defined values are "muc" for &xep0045; abuse, "pubsub" for &xep0060; abuse, "reg" for account registrations (e.g., via &xep0077;), "spam" for </td> </tr> </table> </section1> <section1 topic='Security Considerations' anchor='security'> <p>To follow.</p> </section1> <section1 topic='IANA Considerations' anchor='iana'> <p>To follow.</p> </section1> <section1 topic='XMPP Registrar Considerations' anchor='registrar'> <p>To follow.</p> </section1> <section1 topic='XML Schema' anchor='schema'> <p>To follow.</p> </section1> </xep>