xeps/inbox/incident-reporting.xml

207 lines
7.9 KiB
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>Incident Reporting</title>
<abstract>This specification defines methods for incident reporting among 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.3</version>
<date>2009-04-30</date>
<initials>psa</initials>
<remark><p>Per Council feedback, moved server rosters to a separate specification.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2009-04-27</date>
<initials>psa/fj</initials>
<remark><p>Refactored XML format; added elements for sub-categories, locations, related incidents, solutions, and suggestions.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2009-04-13</date>
<initials>ah/fj/psa/mr/mw</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. In particular, it defines a format for sharing incident reports among XMPP server deployments. (For some related considerations, see &rfc2350;, &rfc3067;, and &rfc5070;.)</p>
</section1>
<section1 topic='Incident Reports' anchor='reports'>
<p>An incident report consists of an XMPP &MESSAGE; stanza containing an &lt;incident/&gt; child element that includes an 'id' attribute whose value is a UUID as described in &rfc4122;. An example is shown below. A server deployment SHOULD send incident reports only to peer servers that it trusts, for example peers that are in its "server roster".</p>
<example caption="An incident report"><![CDATA[
<message from='jabber.org' to='im.flosoft.biz'>
<incident xmlns='urn:xmpp:incident:0'
id='BA51A035-7710-4558-9BBF-34838A4C5B24'>
<description>
<discuss>
<admin>stpeter@jabber.org</admin>
<muc>operators@conference.jabber.org</muc>
</discuss>
<info>
<category>muc</category>
<type>presence</type>
<type>long-messages</type>
</info>
<locs>
<loc>jdev@conference.jabber.org</loc>
<loc>jabber@conference.jabber.org</loc>
</locs>
<rels>
<rel>133BCE2E-E669-4ECE-B0F8-766B9E65630D</rel>
</rels>
<severity>2</severity>
<source>
<ips>
<ip>192.0.2.1</ip>
</ips>
<jids>
<jid>abuser@abuse.lit</jid>
<jid>loser@abuse.lit</jid>
</jids>
</source>
<text xml:lang='en'>lots of MUC spammers from abuse.lit!</text>
<time>
<begin>2009-04-13T19:05:20Z</begin>
<end>2009-04-13T19:27:22Z</end>
<report>2009-04-13T19:31:07Z</report>
</time>
</description>
</incident>
</message>
]]></example>
<p>The defined children of the &lt;description/&gt; element are as follows:</p>
<table caption='&lt;description/&gt; children'>
<tr>
<th>Element Name</th>
<th>Description</th>
</tr>
<tr>
<td>&lt;discuss/&gt;</td>
<td>This element contains the JID of the server admin who generated the incident report (&lt;admin/&gt;), as well as a &xep0045; room where the incident can be discussed (&lt;muc/&gt;).</td>
</tr>
<tr>
<td>&lt;info/&gt;</td>
<td>Structured information about the incident. The defined values of the &lt;category/&gt; and &lt;type/&gt; elements shall be provided via a registry. It is envisioned that the &lt;category/&gt; values shall be "muc" for &xep0045; incidents, "pubsub" for &xep0060; incidents, "reg" for account registration (&xep0077;) incidents, and "stanzas" for general XMPP traffic incidents.</td>
</tr>
<tr>
<td>&lt;locs/&gt;</td>
<td>The place or places on the XMPP network where the incident has occurred (such as a multi-user chat room, a publish-subscribe service, or a general XMPP server), each contained in a separate &lt;loc/&gt; element.</td>
</tr>
<tr>
<td>&lt;rels/&gt;</td>
<td>The IDs of one or more incidents to which this incident might be related, each contained in a separate &lt;rel/&gt; element.</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;source/&gt;</td>
<td>The IP address(es) and JabberID(s) where the incident originated.</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;time/&gt;</td>
<td>The time when the incident began and ended (include an empty &lt;end/&gt; element if the incident is still happening) and, optionally, was reported. The dates MUST conform to the DateTime profile specified in &xep0082;</td>
</tr>
</table>
</section1>
<section1 topic='Incident Solutions' anchor='solutions'>
<p>If the reporting entity determines a solution to the problem, it MAY send out a revised incident report containing a &lt;solution/&gt; element.</p>
<example caption="An incident solution"><![CDATA[
<message from='jabber.org' to='im.flosoft.biz'>
<incident xmlns='urn:xmpp:incident:0'
id='BA51A035-7710-4558-9BBF-34838A4C5B24'>
<description>
...
</description>
<solution>
<text xml:lang='en'>banned the offenders</text>
</solution>
</incident>
</message>
]]></example>
<p>Further definition of the &lt;solution/&gt; element will be provided in a future version of this specification.</p>
</section1>
<section1 topic='Incident Suggestions' anchor='suggestions'>
<p>If an entity that receives an incident report has a suggested solution to the problem, it MAY send an incident message containing a &lt;suggestion/&gt; element.</p>
<example caption="An incident solution"><![CDATA[
<message from='im.flosoft.biz' to='jabber.org'>
<incident xmlns='urn:xmpp:incident:0'
id='BA51A035-7710-4558-9BBF-34838A4C5B24'>
<suggestion>
<text xml:lang='en'>here is how we solved the problem...</text>
</suggestion>
</incident>
</message>
]]></example>
<p>Further definition of the &lt;suggestion/&gt; element will be provided in a future version of this specification.</p>
</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>