xeps/inbox/problem-reporting.xml

<?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 &lt;problem/&gt; 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>&lt;contact/&gt;</td>
      <td>The JID of a person to contact directly.</td>
    </tr>
    <tr>
      <td>&lt;end/&gt;</td>
      <td>The time when the problem ended. Send empty element if still happening. Must conform to &xep0082;</td>
    </tr>
    <tr>
      <td>&lt;incident/&gt;</td>
      <td>An incident number. MUST be a UUID as described in &rfc4122;.</td>
    </tr>
    <tr>
      <td>&lt;ip/&gt;</td>
      <td>The IP address where the problem originates.</td>
    </tr>
    <tr>
      <td>&lt;jids/&gt;</td>
      <td>Each &lt;jid/&gt; child contains the JabberID of an entity that is causing trouble.</td>
    </tr>
    <tr>
      <td>&lt;room/&gt;</td>
      <td>A chatroom where the problem can be discussed.</td>
    </tr>
    <tr>
      <td>&lt;severity/&gt;</td>
      <td>The seriousness of the problem, from 5 (least serious) to 1 (most serious).</td>
    </tr>
    <tr>
      <td>&lt;start/&gt;</td>
      <td>The time when the problem started. Send empty element if unknown.</td>
    </tr>
    <tr>
      <td>&lt;text/&gt;</td>
      <td>A natural-language description of the event. This element SHOULD possess an 'xml:lang' attribute. Multiple &lt;text/&gt; elements MAY be included, each with a different 'xml:lang' value.</td>
    </tr>
    <tr>
      <td>&lt;type/&gt;</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>