%ents; ]>
Incident Reporting This specification defines methods for incident reporting among XMPP server deployments. &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards Council XMPP Core NOT_YET_ASSIGNED operators Artur Hefczyc artur.hefczyc@gmail.com artur.hefczyc@tigase.org Florian Jensen admin@flosoft.biz admin@im.flosoft.biz Mickaël Rémond mickael.remond@process-one.net mremond@process-one.net &stpeter; Matthew Wild mwild1@gmail.com mwild1@jaim.at 0.0.3 2009-04-30 psa

Per Council feedback, moved server rosters to a separate specification.

 0.0.2 2009-04-27 psa/fj

Refactored XML format; added elements for sub-categories, locations, related incidents, solutions, and suggestions.

 0.0.1 2009-04-13 ah/fj/psa/mr/mw

First draft.

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;.)

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".

stpeter@jabber.org operators@conference.jabber.org muc presence long-messages jdev@conference.jabber.org jabber@conference.jabber.org 133BCE2E-E669-4ECE-B0F8-766B9E65630D 2 192.0.2.1 abuser@abuse.lit loser@abuse.lit lots of MUC spammers from abuse.lit! ]]>

The defined children of the <description/> element are as follows:

Element Name Description
<discuss/> 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/>).
<info/> 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.
<locs/> 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.
<rels/> The IDs of one or more incidents to which this incident might be related, each contained in a separate <rel/> element.
<severity/> The seriousness of the problem, from 5 (least serious) to 1 (most serious).
<source/> The IP address(es) and JabberID(s) where the incident originated.
<text/> 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.
<time/> 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;

If the reporting entity determines a solution to the problem, it MAY send out a revised incident report containing a <solution/> element.

... banned the offenders ]]>

Further definition of the <solution/> element will be provided in a future version of this specification.

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.

here is how we solved the problem... ]]>

Further definition of the <suggestion/> element will be provided in a future version of this specification.

To follow.

To follow.

To follow.

To follow.