diff --git a/xep-0268.xml b/xep-0268.xml index 0d68e6a2..71787f79 100644 --- a/xep-0268.xml +++ b/xep-0268.xml @@ -41,6 +41,12 @@ &stpeter; &mwild; + + 0.5 + 2012-05-16 + psa +

Simplified the processing model to send reports only in IQ-sets (not in IQ-results); filled out the sections on inquiries, requests, and responses; corrected the schema and examples.

+
0.4 2012-04-17 @@ -90,87 +96,221 @@ -

This document defines several interactions (similar to those in &rfc6045;) between XMPP server deployments with respect to incident handling. These interactions are transported using the XMPP &IQ; stanza as described below.

+

This document defines several interactions (similar to those in RID, see &rfc6045;) between XMPP server deployments with respect to incident handling. These interactions are transported using the XMPP &IQ; stanza as described below, where each element (qualified by the 'urn:xmpp:incident:2' namespace) is used as a wrapper for IODEF data.

    -
  1. The <report/> element (contained in an &IQ; stanza of type "set" or, in response to an <inquiry/> element, of type "result") describes the nature of an incident and also flags the 'status' of the incident as "new", "updated", or "resolved"; it is sent from one server to another for informative purposes (sometimes in reply to the <inquiry/> element) but without requesting assistance (for which see the <request/> element).

  2. -
  3. The <inquiry/> element (contained in an &IQ; stanza of type "get") asks for information about an incident; it is expected that the reply will contain a <report/> element.

  4. -
  5. The <request/> element (contained in an &IQ; stanza of type "get") asks for assistance in resolving an incident.

  6. -
  7. The <response/> element (contained in an &IQ; stanza of type "result") provides assistance in resolving an incident.

  8. +
  9. The <report/> element (contained in an &IQ; stanza of type "set") describes the nature of an incident and also flags the 'status' of the incident as "new", "updated", or "resolved"; it is sent from one server to another for informative purposes but without requesting assistance (for which see the <request/> element). This element is similar to a RID message type of "Report".

  10. +
  11. The <inquiry/> element (contained in an &IQ; stanza of type "get") asks for information about an incident; it is expected that the reply will contain a <report/> element. This element is similar to a RID message type of "IncidentQuery".

  12. +
  13. The <request/> element (contained in an &IQ; stanza of type "get") asks for assistance in resolving an incident, e.g., by requesting that the server take some action. This element is similar to a RID message type of "Investigation" or "TraceRequest".

  14. +
  15. The <response/> element (contained in an &IQ; stanza of type "set") provides assistance in resolving an incident. This element is similar to a RID message type of "Result".

-

An incident report consists of an XMPP &IQ; stanza of type "set" or "result" containing an IODEF document. An example is shown below.

- - - 4BF5D2CE-7C90-4860-BEF2-43A7D777D5FF - 2009-04-13T19:05:20Z - 2009-04-13T19:27:22Z - 2009-04-13T19:31:07Z - lots of MUC spammers from abuse.lit! - - - stpeter@jabber.org - - - - - stpeter@jabber.org - - - - - operators@muc.xmpp.org - - - - 133BCE2E-E669-4ECE-B0F8-766B9E65630D - - - - - - - - -
abuser@abuse.lit
- 123 -
- -
luser27@abuse.lit
- 47 -
-
- - -
jdev@conference.jabber.org
-
jabber@conference.jabber.org
- -
-
-
- - muc - presence - long-messages -
+

When one server wants to send information about an incident, it sends a incident report to another server. The report consists of an XMPP &IQ; stanza of type "set" containing a <report/> element that in turn contains an IODEF document. An example is shown below.

+ + + + 4BF5D2CE-7C90-4860-BEF2-43A7D777D5FF + 2009-04-13T19:05:20Z + 2009-04-13T19:27:22Z + 2009-04-13T19:31:07Z + lots of MUC spammers from clueless.lit! + + + stpeter@jabber.org + + + + + stpeter@jabber.org + + + + + operators@muc.xmpp.org + + + + 133BCE2E-E669-4ECE-B0F8-766B9E65630D + + + + + + + + +
abuser@clueless.lit
+ 123 +
+ +
luser27@clueless.lit
+ 47 +
+
+ + +
jdev@conference.jabber.org
+
jabber@conference.jabber.org
+ +
+
+
+
+
+
]]>
-

If the report is contained in an &IQ; stanza of type "set" and the recipient of the report is able to process it, it MUST return an &IQ; stanza of type "result". Error handling will be defined in a future version of this specification.

+

If the recipient is able to process the report, it MUST return an &IQ; stanza of type "result"; if not, it MUST return an &IQ; stanza of type "error" (error handling will be defined in a future version of this specification).

-

To follow.

+

When one server wants to find out more information about an incident, it sends an inquiry to another server (not necessarily the server where the incident occurred).

+ + + + 4BF5D2CE-7C90-4860-BEF2-43A7D777D5FF + + + + ]]> +

If the recipient is able to process the inquiry, it MUST return an &IQ; stanza of type "result" and then send a report about the incident using an &IQ; stanza of type "set" as defined above; if not, it MUST return an &IQ; stanza of type "error" (error handling will be defined in a future version of this specification).

-

To follow.

+

When one server wants to ask for assistance in resolving an incident, it sends a request to another server (not necessarily the server where the incident occurred).

+

Here, the server where the attack occurred requests that the server where the attack originated will disable the offending accounts (via the "block-host" value for the 'action' attribute of the IODEF <Expectation/> element).

+ + + + 4BF5D2CE-7C90-4860-BEF2-43A7D777D5FF + 2009-04-13T19:05:20Z + 2009-04-13T19:27:22Z + 2009-04-13T19:31:07Z + lots of MUC spammers from clueless.lit! + + + stpeter@jabber.org + + + + + stpeter@jabber.org + + + + + operators@muc.xmpp.org + + + + 133BCE2E-E669-4ECE-B0F8-766B9E65630D + + + + + + + + +
abuser@clueless.lit
+ 123 +
+ +
luser27@clueless.lit
+ 47 +
+
+ + +
jdev@conference.jabber.org
+
jabber@conference.jabber.org
+ +
+
+
+ +
+
+
+ + ]]>
+

If the recipient is able to process the report, it MUST return an &IQ; stanza of type "result"; if not, it MUST return an &IQ; stanza of type "error" (error handling will be defined in a future version of this specification).

-

To follow.

+

When one server provides assistance in resolving an incident, it sends a response to another server (not necessarily the server where the incident occurred).

+

Here, the server where the attack originated informs the server where the attack occurred that it has disabled the offending accounts (via the IODEF <HistoryItem/> element).

+ + + + 4BF5D2CE-7C90-4860-BEF2-43A7D777D5FF + 2009-04-13T19:05:20Z + 2009-04-13T19:27:22Z + 2009-04-13T19:31:07Z + lots of MUC spammers from clueless.lit! + + + stpeter@jabber.org + + + + + stpeter@jabber.org + + + + + operators@muc.xmpp.org + + + + 133BCE2E-E669-4ECE-B0F8-766B9E65630D + + + + + + + + +
abuser@clueless.lit
+ 123 +
+ +
luser27@clueless.lit
+ 47 +
+
+ + +
jdev@conference.jabber.org
+
jabber@conference.jabber.org
+ +
+
+
+ +
+ + + 2009-04-13T19:47:11Z + Account disabled + + +
+
+ + ]]>
+

If the recipient is able to process the report, it MUST return an &IQ; stanza of type "result"; if not, it MUST return an &IQ; stanza of type "error" (error handling will be defined in a future version of this specification).

@@ -217,8 +357,21 @@ xmlns='urn:xmpp:incident:2' elementFormDefault='qualified'> + + + + + + + + + + + + + ]]>