Subject: [xmpp] DNA/S2S Part 3: Connection management

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jul 2011 17:47:39 -0400

One challenge for server-to-server connections is how to manage what how a connection between two servers is used, in particular, which domains' stanzas can be carried on the connection.  When a domain is delegated to a server in a different domain, it may also be desirable to modify the RFC 6120 connection process so that the initiating server connects to the server's domain instead of the target domain.  (For more detail, see draft-ietf-xmpp-dna-01.)

The current document specifies that an initiating server connects to the remote server's domain, rather than to the "target domain" that it's actually trying to reach.  The initiating server then uses the XMPP dialback mechanism to request permission to send stanzas for the target domain. 

On the other hand, if you look closely at the specification for XMPP bidirectional server-to-server connection (XEP-0288), you can see that there's some overlap.  While the main purpose of XEP-0288 is to enable a connection for "a.com->b.com" to also carry stanzas for "b.com->a.com", in principle, the usage of dialback in XEP-0288 could also be used to request permission to send stanzas for completely unrelated domain pairs -- a general connection muxing function.

Supposing a general mechanism is developed for binding domain pairs to connections, it seems like having the initial connection go to the server itself (as in the current DNA document) might simplify the overall s2s process, especially in delegation cases.

So one could imagine a general "XMPP server-to-server connections" document that re-defines the RFC6120 server-to-server connection process in a way that cleanly separates the connection from the domain pair whose stanzas it carries.  This document would define a "connection management" extension that would facilitate the binding of domain pairs to a connection, plus any other changes to the s2s connection process (e.g., connecting to the server first).

For the sake of discussion, I've created a skeleton of what such a draft might look like, supposing it integrated dialback and/or bidi:
<http://geopriv.dreamhosters.com/xmpp-s2s/draft-barnes-xmpp-s2s-00.html>

QUESTION: Should this group develop a more general update to how server-to-server connections are managed?  Should this document subsume part or all of the current draft of XEP-288?

---

From: Philipp Hancke <[email-masked]>
Date: Sat, 16 Jul 2011 09:59:01 +0200

> On the other hand, if you look closely at the specification for XMPP bidirectional server-to-server connection (XEP-0288), you can see that there's some overlap.  While the main purpose of XEP-0288…

I think the "general connection muxing function" already exists, it was 
called "piggybacking" in RFC 3920 and is described in the "Multiplexing" 
section of XEP-0220 (version 0.5 at least).

bidi (0288) has an interesting impact on the rules for multiplexing 
target domains as defined in 220 - it looks as if it simplifies things. 
There are some notes about that in my working copy already, I'll poke my 
co-author again for review + approval.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Jul 2011 10:43:45 +0100

On Sat Jul 16 08:59:01 2011, Philipp Hancke wrote:
> Richard L. Barnes wrote:
>> On the other hand, if you look closely at the specification for  
>> XMPP bidirectional server-to-server connection (XEP-0288), you can  
>> see that there's some overlap.  While the main purpose of XEP-0288  
>> is to enable a connection for "a.com->b.com" to also carry stanzas  
>> for "b.com->a.com", in principle, the usage of dialback in  
>> XEP-0288 could also be used to request permission to send stanzas  
>> for completely unrelated domain pairs -- a general connection  
>> muxing function.
> 
> I think the "general connection muxing function" already exists, it  
> was called "piggybacking" in RFC 3920 and is described in the  
> "Multiplexing" section of XEP-0220 (version 0.5 at least).
> 
> target domains as defined in 220 - it looks as if it simplifies  
> things. There are some notes about that in my working copy already,  
> I'll poke my co-author again for review + approval.

Right - XEP-0288 intentionally simplifies the XEP-0220 muxing, and in  
XMPP, muxing *itself* is a solved problem - the issue is purely  
limited to authentication.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 18 Jul 2011 10:09:52 -0400

Dave, Philipp,

Thanks for this feedback.  I had been trying to work through all the XSF prior art, and apparently didn't dig back far enough :)

Given the existing mechanisms for muxing, would it make sense to pare the DNA document back to just the following?

1. For the PKIX case: Recommend using XmppAddr, possibly amending this paragraph of RFC 6120:
"
o  Support for the XmppAddr identifier type (specified under 
   Section 13.7.1.4) is encouraged in XMPP client and server software
   implementations for the sake of backward-compatibility, but is no
   longer encouraged in certificates issued by certification
   authorities or requested by XMPP service providers.
"

2. Define an update to XEP-0220 that defines how DNSSEC interacts with the <db:verify/> transaction.  

--Richard

On Jul 18, 2011, at 5:43 AM, Dave Cridland wrote:

>> I think the "general connection muxing function" already exists, it was called "piggybacking" in RFC 3920 and is described in the "Multiplexing" section of XEP-0220 (version 0.5 at least).
>> bidi (0288) has an interesting impact on the rules for multiplexing target domains as defined in 220 - it looks as if it simplifies things. There are some notes about that in my working copy already, I'll poke my co-author again for review + approval.
> 
> Right - XEP-0288 intentionally simplifies the XEP-0220 muxing, and in XMPP, muxing *itself* is a solved problem - the issue is purely limited to authentication.
> 
> Dave.
> --

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Jul 2011 17:17:46 +0100

On Mon Jul 18 15:09:52 2011, Richard L. Barnes wrote:
> Given the existing mechanisms for muxing, would it make sense to  
> pare the DNA document back to just the following?
> 
There's also sRVName SANs, beginning _xmpp, which have the same  
properties (roughly), at least for S2S sessions.

But the real problem is that you don't want one certificate with (in  
GTalk's case) several thousand SANs in, so what we need is multiple  
certificates. I can conceive of solutions at the TLS layer, but  
nothing that's likely to be deployable within the next year or more.

So in the case whereby a server cannot use DNSSEC to verify a domain,  
and the SAN is not present in the TLS certificate of the peer, then  
it needs to get some nonces of itself and the peer, and exchange  
signatures.

I'd like to get this as part of dialback - I'd really like to  
essentially deprecate SASL EXTERNAL, because having multiple ways to  
achieve the same end-goal is irritating - so I suppose we're looking  
at an extended dialback along the lines of:

<db:result ...>
  <mechanism  
xmlns='urn:ietf:protocols:xml:namespaces:xmpp:ole:biscuit:barrel:dialback:extended' 
type='pkix'>
    <.../>
  </mechanism>
</db:result>

The syntax for which is triggered off a stream feature.

> with the <db:verify/> transaction.

My impression is we essentially know what to do here, and being a  
"dialback without dialback" case, there's no syntactic changes needed.

Dave.

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 18 Jul 2011 18:20:40 +0200

> Thanks for this feedback.  I had been trying to work through all the XSF prior art, and apparently didn't dig back far enough :)

heh, the most important stuff is really well hidden in a chatroom log:
http://logs.jabber.org/[email-masked]/2009-04-14.html#15:00:34

> 2. Define an update to XEP-0220 that defines how DNSSEC interacts with the<db:verify/>  transaction.

Let's see if I understood DNA...

Upon receiving a
<db:result from=sender.tld .../>
the receiving server does a SRV lookup for sender.tld (or 
_xmpp-server._tcp.sender.tld?).
This lookup returns xmpp1.originating.tld.
Now, since the originating server uses a trusted certificate for 
xmpp1.originating.tld, the receiving server skips the dial-back and 
immediately answers with <db:result type=valid/>

If that is correct, I think it is much easier to describe DNA as another 
dialback-without-dialback technique as described by Dave either in the 
chat log above or at http://blog.dave.cridland.net/?p=116