%ents; ]>
Problem Reporting This specification defines methods for reporting of network problems between 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.1 2009-04-13 psa

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.

The basic approach is two-fold:

  1. 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.
  2. When a server encounters problems (e.g., suspicious account registrations), it SHOULD send a problem report to the servers on its "roster".

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.

]]>

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.

A problem report consists of an XMPP &MESSAGE; stanza containing a <problem/> child element. The following is an example.

stpeter@jabber.org 2009-04-13T19:27:22Z cc7b247b-18b4-4301-b6d0-e9e4016d802f 192.0.2.0 abuser@spam.lit loser@spam.lit operators@conference.jabber.org 2 2009-04-13T19:05:20Z lots of MUC spammers from abuse.lit! muc ]]>

The defined child elements are as follows:

Element Name Description
<contact/> The JID of a person to contact directly.
<end/> The time when the problem ended. Send empty element if still happening. Must conform to &xep0082;
<incident/> An incident number. MUST be a UUID as described in &rfc4122;.
<ip/> The IP address where the problem originates.
<jids/> Each <jid/> child contains the JabberID of an entity that is causing trouble.
<room/> A chatroom where the problem can be discussed.
<severity/> The seriousness of the problem, from 5 (least serious) to 1 (most serious).
<start/> The time when the problem started. Send empty element if unknown.
<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.
<type/> 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

To follow.

To follow.

To follow.

To follow.