[Standards] LAST CALL: XEP-0220 (Server Dialback)

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 21 19:37:33 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/16/13 2:16 PM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on 
> XEP-0220 (Server Dialback).

Off-list, Philipp Hancke and I have had a few co-author discussions
about a few sections of this spec. Since we don't want to make changes
in private, here's a summary of what we've discussed.

1. 2.1.1 Initiating Server Generates Outbound Request for
Authorization by Receiving Server

OLD

Naturally, the Initiating Server can also enable or negotiate other
stream features at this point, such as Stream Compression [9] and Stream
Management [10].

NEW

Naturally, the Initiating Server can also enable or negotiate other
stream features at this point.

Rationale: as discussed on the list, the recommended order of stream
feature negotiation is really a matter for XEP-0170 (which needs to be
updated).

2. Section 2.2.1 Receiving Server Handles Inbound Authorization
Request from Initiating Server

OLD

This key MUST be verified before the Initiating Server is authorized
to send stanzas from the Sender Domain ("capulet.lit") to the Target
Domain ("montague.lit"). Note that the verification process might fail
prematurely, for example, if the Receiving Server's policy states that
connections from the Initiating Server or the Sender Domain are not
allowed.

NEW

Before the Receiving Server allows the Initiating Server to send
stanzas from the Sender Domain (here "capulet.example") to the Target
Domain (here "montague.example"), it MUST verify the identity of the
Initiating Server. Depending on how the server dialback protocol is
used, this can be done by verifying the dialback key or by using some
out-of-band method as in the POSH [11] prooftype for DNA [12]. Note
that the verification process might fail prematurely, for example, if
the Receiving Server's policy states that connections from the
Initiating Server or the Sender Domain are not allowed.

Rationale: because we're talking about re-using the dialback protocol
(but not necessarily dialback keys) for domain name assertions in
general (see draft-ietf-xmpp-dna), we can't say you must check the
dialback key since verification can be based on, say, POSH.

3. 2.2.1 Receiving Server Handles Inbound Authorization Request from
Initiating Server

OLD

After the validity of the key has been established (for example, by
the Authoritative Server), the domain pair is to be considered as
verified and the Receiving Server MUST accept stanzas from the
Initiating Server for the verified domain pair.

In addition, the Receiving Server SHALL notify the Initiating Server
of the result. This is done by creating a <db:result/> element which
MUST possess a 'from' attribute whose value is the Target Domain, MUST
possess a 'to' attribute whose value is the Sender Domain, and MUST
possess a 'type' attribute whose value is either "valid" or "invalid"
(or "error", as shown above).

NEW

After the validity of the key has been established (for example, by
the Authoritative Server), the Receiving Server can safely accept
stanzas from the Initiating Server for the verified domain pair.

In addition, the Receiving Server SHALL notify the Initiating Server
of the result and thus signal its willingness to accept stanzas from
the Initiating Server for the verified domain pair. This is done by
creating a <db:result/> element which MUST possess a 'from' attribute
whose value is the Target Domain, MUST possess a 'to' attribute whose
value is the Sender Domain, and MUST possess a 'type' attribute whose
value is either "valid" or "invalid" (or "error", as shown above).

Rationale: it's not correct to say that the Receiving Server "MUST"
accept stanzas.

4. Section 2.6 Multiplexing

OLD

A single XML stream between Initiating Server and Receiving Server can
be used to multiplex stanzas for more than one domain pair. We call this
usage "multiplexing" (historically it has also been known as
"piggybacking"). One common motivation for multiplexing is virtual
hosting, under which many domains are hosted on the same server. Another
common motivation for such reuse is the existence of additional services
associated with the Sender Domain but hosted at "subdomains" thereof.
For example, both the "montague.lit" and the "capulet.lit" XMPP servers
might host Multi-User Chat [16] services at "chat.montague.lit" and
"rooms.capulet.lit" respectively. Without multiplexing, many
server-to-server connections would be necessary to exchange stanzas
between those domains. With more domains, the number of connections
might exceed the maximum number of connections allowed from a single IP
address as explained in Best Practices to Discourage Denial of Service
Attacks [17]. Multiplexing reduces the number of connections to two.

Note: Because dialback operates on domain pairs, a total of eight
dialback negotiations is necessary for a bidirectional exchange of
stanzas between two sending domains and two target domains.

NEW

A single XML stream between Initiating Server and Receiving Server can
be used to multiplex stanzas for more than one domain pair. We call this
usage "multiplexing" (historically it has also been known as
"piggybacking").

One common motivation for multiplexing is virtual hosting, under which
many domains are hosted on the same server. This problem is described
more fully in the Domain Name Associations specification,
draft-ietf-xmpp-dna).

Another common motivation for such reuse is the existence of additional
services associated with the Sender Domain but hosted at "subdomains"
thereof. For example, both the "montague.example" and the
"capulet.example" XMPP servers might host Multi-User Chat [16] services
at "chat.montague.example" and "rooms.capulet.example" respectively.
Because dialback operates on domain pairs, a total of eight dialback
negotiations would be necessary for a bidirectional exchange of stanzas
between two sending domains and two target domains.

If multiplexing is not used, the number of server-to-server connections
needed to exchange stanzas between virtual hosting providers or
multi-service XMPP servers can increase signficantly. Indeed, when the
number of hosted domains becomes especially large, the number of
connections might exceed the maximum number of connections allowed from
a single IP address as explained in Best Practices to Discourage Denial
of Service Attacks [17].

If multiplexing is used, the number of connections can be limited to
only two (or, at the operator's discretion, more than two for
operational reasons).

Rationale: A general cleanup to prevent confusion.

Comments are welcome.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSFRb9AAoJEOoGpJErxa2pVKMP/2SS/bGQ/9wteRSHEAUXpOKJ
h/Vb7CqsxtjaCK7Hizem+z/ac/P9+/VBEOdz8PB4pGUGM7H3MngNIaNWZdp4as/k
DksP0yWnCQagXtajRHPwexPe2pIorvy0vtOOdjQ7uv234EgsutDY8PudILz+exHb
DR7kazLXQ0QMewONoep5WtrwFFmKRtvzU21g/ZPqxBcI26muOFibT30tM2EBLCQz
uyeLXnesvGsWo6SSYqSDFw3n+fZYKCggOwrOj72qwZFEExXK7gWQMs3mzHfGVziq
FYj0yrVTzKJztcGFmCYsO8GnHH4rHqVouBeOEvebPk0uCVdjdqtB3iq2DjpCrBOZ
iMT/dZg1bJqmCzN+rqT1NjermBWTgoA6jyRG7PrkimkFEA9BZEDWZuCawN4UmTqT
DCVHlCa5NzC0DPQeBdAU6HmD8WYBZ+psKFjq6eJrC8qallCLPjLb7JtT0vxBoGU1
FFxBFtaLb7bMFVhEIvKYe8rQQqEy2drLS2WB8oTg+PelOubdEzFNZuKATAR2Hv+2
j0r9Cs7Y10A8qKGWXdsDx84omT8JpaMmZgd6kuDUG+sDJU/4xk0BJkH8tjcFxi4b
JzdKHJzLUDfITi8guwPR1uwaI1J475rlTukGo0/UtcbDI6d+0a5YgvPUAFp2kcvQ
fy837GvsgIKlLfdTOW+k
=GQUA
-----END PGP SIGNATURE-----



More information about the Standards mailing list