mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
222 lines
8.6 KiB
XML
222 lines
8.6 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>0268</number>
|
||
|
|
<status>Experimental</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.1</version>
|
||
|
|
<date>2009-04-30</date>
|
||
|
|
<initials>psa</initials>
|
||
|
|
<remark><p>Initial published version.</p></remark>
|
||
|
|
</revision>
|
||
|
|
<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 <incident/> 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" as described in &xep0267;.</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 <description/> element are as follows:</p>
|
||
|
|
<table caption='<description/> children'>
|
||
|
|
<tr>
|
||
|
|
<th>Element Name</th>
|
||
|
|
<th>Description</th>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td><discuss/></td>
|
||
|
|
<td>This element contains the JID of the server admin who generated the incident report (<admin/>), as well as a &xep0045; room where the incident can be discussed (<muc/>).</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td><info/></td>
|
||
|
|
<td>Structured information about the incident. The defined values of the <category/> and <type/> elements shall be provided via a registry. It is envisioned that the <category/> 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><locs/></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 <loc/> element.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td><rels/></td>
|
||
|
|
<td>The IDs of one or more incidents to which this incident might be related, each contained in a separate <rel/> element.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td><severity/></td>
|
||
|
|
<td>The seriousness of the problem, from 5 (least serious) to 1 (most serious).</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td><source/></td>
|
||
|
|
<td>The IP address(es) and JabberID(s) where the incident originated.</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><time/></td>
|
||
|
|
<td>The time when the incident began and ended (include an empty <end/> 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 <solution/> 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 <solution/> 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 <suggestion/> 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 <suggestion/> 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>This document requires no interaction with &IANA;.</p>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
<section1 topic='XMPP Registrar Considerations' anchor='reg'>
|
||
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||
|
|
<p>This specification defines the following XML namespace:</p>
|
||
|
|
<ul>
|
||
|
|
<li>urn:xmpp:incident:0</li>
|
||
|
|
</ul>
|
||
|
|
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
|
||
|
|
&NSVER;
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
<section1 topic='XML Schema' anchor='schema'>
|
||
|
|
<p>To follow.</p>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
</xep>
|