1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-10-31 15:35:07 -04:00
xeps/inbox/problem-reporting.xml
2015-06-24 00:39:33 +01:00

154 lines
5.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>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>