From e60fd2b83dff93b30e001a3a290f3266e69ad581 Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Tue, 22 Nov 2022 19:59:08 +0100 Subject: [PATCH] ProtoXEP editorial help by MattJ My earliest drafts were on 2021-08-20. Have mosly working implementation that interops with itself. --- inbox/pathmtu.xml | 193 ---------------------------------------------- inbox/xep-sla.xml | 126 ++++++++++++++++++++++++++++++ 2 files changed, 126 insertions(+), 193 deletions(-) delete mode 100644 inbox/pathmtu.xml create mode 100644 inbox/xep-sla.xml diff --git a/inbox/pathmtu.xml b/inbox/pathmtu.xml deleted file mode 100644 index 152f03e0..00000000 --- a/inbox/pathmtu.xml +++ /dev/null @@ -1,193 +0,0 @@ - - -%ents; -]> - -
-Stanza size limit discovery -This documents describes a mechanism for communicating stanza size limits across streams in order to help avoid reaching those limits. -&LEGALNOTICE; -xxxx -ProtoXEP -Standards Track -Standards - - - -NOT_YET_ASSIGNED - -Kim -Alvefur -zash@zash.se -zash@zash.se - - -0.0.1 -2021-08-20 -ka - -

Early draft

- - - -nil -2021-08-25 -ka - -

more work

- - - -nil -2021-08-28 -ka - -

more words

- - -
- - -

This documents describes a mechanism for communicating the stanza size -limit that is in effect on a particular stream, in order to allow the -other party to avoid reaching those limits.

- - - -

When stanza size limits have been deployed, very often this leads to -problems with large stanzas causing connection outages, most often -vCards and Avatar stanzas.

- -

If stanza size limit violations are met with stream errors then this may -lead to temporary connection outage, which may a few seconds to recover -from.

- -

Especially vCard and Avatar stanzas may be very large and sometimes -exceed the stanza size limit imposed.

- - - -
    -
  • Enable discovery of the stanza size limit in use on a stream.
    • -
- - - -
    -
  • bi-directional?
    • -
  • disco too?
    • -
  • some sort of path mtu discovery method?
    • -
  • error condition?
    • -
  • rewrite large iq-result to error?
    • -
- - - -

OPTIONAL.

- - - -
    -
  • An XMPP client could attempt to apply more compression if it sees -that an avatar it is about to upload would be too large.
    • -
  • A PubSub server could limit the number of items in an <items/> -query to ensure it can be delivered.
    • -
- - - -

If after serialization to XML a stanza is too large, like, don’t send -it. Synthesize an error condition, most likely a (modify, -policy-violation), and pretend the remote entity replied with this.

- - - -

Something about margins, due to variations in XML serialization, added -attributes (e.g. the from attribute stamped by servers) or elements -(delay tags)

- -

Because the stanza size limit is known ahead of time, entities can check -this against stanzas they are about to send and take appropriate action, -such as preemptively pretending that the stanza was rejected by the -receiving entity.

- -

A client could for example try to apply more compression to an avatar or -ask the user to select a smaller picture.

- - - -

OPTIONAL.

- -

Not relevant?

- - - -

OPTIONAL.

- -

Not relevant?

- - - -

The responding entity advertises the stanza size limit it enforces -by including it as an integer in a stream feature element -stanza-size-limit in the namespace urn:xmpp:tmp:TBD. An example of -stream features prior to authentication follows:

- - - - SCRAM-SHA-1 - PLAIN - - 10000 -]]> - -

Entities may wish to have hire limits after authentication and would -advertise it the same way after the stream restart:

- - - - - - 262144 -]]> - - - -

REQUIRED.

- -

Very large stanzas may incur memory and processing costs on the -receiving entity. Advertising the actual limits could inform an attacker -of how large a stanza to construct in order to maximize e.g. DoS -effectiveness. Best combined with network level rate limits on raw -bytes.

- -

Also see https://xmpp.org/rfcs/rfc6120.html#rfc.section.13.12

- -

TBD Recommendations for limits?

- - - -

None.

- - - -

Need the stream feature registered.

- - - -

RECOMMENDED.

- -

Design? I just typed words and code into my computer!

- - - -

REQUIRED for protocol specifications.

- - - - - diff --git a/inbox/xep-sla.xml b/inbox/xep-sla.xml new file mode 100644 index 00000000..f31a2981 --- /dev/null +++ b/inbox/xep-sla.xml @@ -0,0 +1,126 @@ + + +%ents; +]> + + +
+ Stream Limits Advertisement + This specification defines a way for an XMPP entity to announce the limits it will enforce for data received on a stream. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + sla + + Kim + Alvefur + zash@zash.se + zash@zash.se + + &mwild; + + 0.0.1 + 2022-10-20 + ka, mw +

First draft.

 + +
+ +

This documents describes a mechanism for communicating limits, such as stanza size limits that is in effect on a particular stream, in order to allow the sending party to avoid reaching those limits.

+ +

Where stanza size limits have been deployed, very often this leads to problems with large stanzas causing connection outages, most often &xep0084; and &xep0053; result stanzas, which can be very large due to embedded images.

+

If stanza size limit violations are met with stream errors then this may lead to temporary connection outage, which may a few seconds to recover from.

+ + + +
    +
  • Enable discovery of the stanza size limit in use on a stream.
    • +
  • Support for bi-directional streams.
    • +
+

These requirements will enable XMPP clients and servers to adapt data they generate, such that it will fit within the limits required by the recipient, or reject overly large stanzas early, rather than following a trial-and-error approach.

+ + + +

For any XMPP stream, there is an "initiating entity" (a client or server) and a "responding entity" that they are connecting to. The responding entity advertises its limits in the <stream:features/> element that it sends at the start of the stream.

+

The limits are enclosed in a <limits/> element qualified by the 'urn:xmpp:stream-limits:0' namespace. This element SHOULD contain the following child elements:

+
+ +
<max-bytes/>
+
Contains an integer representing the maximum size of any first-level stream elements (including stanzas), in bytes. Guidance on acceptable limits is provided in &rfc6120; section 13.12.
+ + +
<idle-seconds/>
+
Contains an integer representing the number of seconds without any traffic from the iniating entity after which the server may consider the stream idle, and either perform liveness checks (using e.g. &xep0198; or &xep0199;) or terminate the stream. Guidance on handling idle connections is provided in &rfc6120; section 4.6.
+ +
+ + + SCRAM-SHA-1 + PLAIN + + + 10000 + 1800 + + + ]]> + + +

Servers using &xep0288; to establish a bidirectional stream with another server do not get an opportunity to send <stream:features/> to the responding entity. For a server to advertise the limits about what it is willing to accept on such a stream, the <limits/> element can be included in the <bidi/> element.

+ + + 10000 + 1800 + + + ]]> + + + +

If, after serialization, a stanza exceeds the limits that have been advertised on a stream, it SHOULD NOT be sent on that stream. Instead, a server SHOULD return an error to the sender. Such an error SHOULD contain the <policy-violation/> error condition, and SHOULD NOT contain a 'by' attribute (as the policy being violated is not the current entity's). A <text/> may also be included, explaining the limit that would be exceeded.

+

It is acceptable for the limits on a stream to change whenever new stream features are announced - such as before and after authentication of the connecting entity.

+ + +

OPTIONAL.

+ + +

OPTIONAL.

+ + +

OPTIONAL.

+ + +

REQUIRED.

+

Very large stanzas may incur memory and processing costs on the receiving entity. Advertising the actual limits could inform an attacker of how large a stanza to construct in order to maximize e.g. DoS effectiveness. Best combined with network level rate limits on raw bytes.

+ + +

None.

+ + +

This specification defines the following namespace:

+
    +
  • urn:xmpp:stream-limits:0
    • +
+

Also, the following stream feature:

+
    +
  • <limits xmlns='urn:xmpp:stream-limits:0'/>
    • +
+ + +

The ability for a client to announce limits on what it will receive on a client-to-server stream is deliberately not provided by this specification. This vastly simplifies discovery of the maximum limits between any two JIDs, and it avoids situations where the server is unable to deliver incoming stanzas to some or all of an account's connected clients. Clients will already be protected from denial-of-service through excessive stanza sizes due to the server's own limits.

+ + +

TBD.

+ +