Proxy functionality in XMPP?

Hi all,I am kind of new to XMPP and from what I know so far it looks like there is no proxy
like functionality in XMPP. In XMPP there is only server-to-server communication
that does not involve any proxies. A use-case is an XMPP server wishing to forward
certain XMPP packets to the JID foo at bar.com has to send it to the server associated
with the domain bar.com .

Any thoughts, comments?

San

Sanjay Pujare wrote:

> I am kind of new to XMPP and from what I know so far it looks like there is no proxy
> like functionality in XMPP. In XMPP there is only server-to-server communication
> that does not involve any proxies. A use-case is an XMPP server wishing to forward
> certain XMPP packets to the JID foo at bar.com has to send it to the server associated
> with the domain bar.com .This is true, and it's part of the XMPP architecture. While it would be 
possible to add proxies or intermediate routers to the architecture, 
we've never seen a need to do so. Is there a particular use case you 
have in mind? In practice, the network seems to work just fine without 
proxies. Although you could argue that it is a bit more difficult to 
deploy an XMPP server (e.g., it is best to set up proper SRV records), I 
don't see that it's that much harder than (say) an email server (where 
you need proper MX records) or especially an email server with support 
for things like SPF.

And yes this means we can't easily do forwarding -- we've talked about 
that for years but have never figured out a way to do it that didn't 
open some security holes (or at least holes that didn't seem worth 
opening for the relatively small gain of forwarding). If you think the 
lack of forwarding in XMPP is a problem, speak up and perhaps we'll work 
on the problem again (I can share links to preliminary work we did, 
which was never officially published).

Peter

--- Peter Saint-Andre  wrote:

> Sanjay Pujare wrote:
> 
> ...
> This is true, and it's part of the XMPP architecture. While it would be 
> possible to add proxies or intermediate routers to the architecture, 
> we've never seen a need to do so. Is there a particular use case you 
> have in mind?Proxies or intermediate routers are very useful for the simple reason that they
facilitate routing that can be controlled dynamically. Also imagine cases where XMPP
is not the only protocol for IM and presence. SIP/SIMPLE is also there (in fact that
is the reason for this inter-operability newsgroup!). By forcing inter-domain XMPP
communication to happen only between their respective XMPP servers we are precluding
possibilities of various proxy services doing translations and such stuff. Look at a
SIP-XMPP gateway: on the SIP side it can behave like a SIP proxy performing routing
functions but on the XMPP side it will be constrained by XMPP's server-to-server
restrictions. So each XMPP server will need a dedicated gateway whereas with SIP,
multiple SIP servers can use a common proxy.> In practice, the network seems to work just fine without 
> proxies. Although you could argue that it is a bit more difficult to 
> deploy an XMPP server (e.g., it is best to set up proper SRV records), I 
> don't see that it's that much harder than (say) an email server (where 
> you need proper MX records) or especially an email server with support 
> for things like SPF.Email/SMTP is a much older protocol and may not be a good example to emulate. Things
like MX records, SPF were later additions that don't make the original protocol
perfect. Things that came later like HTTP and SIP support proxies (more so for SIP
than HTTP). I don't see any reason why XMPP can't use them.> 
> And yes this means we can't easily do forwarding -- we've talked about 
> that for years but have never figured out a way to do it that didn't 
> open some security holes (or at least holes that didn't seem worth 
> opening for the relatively small gain of forwarding).Security can be addressed thru TLS where communication between trusted domains is
easy. For SMTP/Email like open communication we may have to think of something else,
but that is really a different point from the need to have proxies.> If you think the 
> lack of forwarding in XMPP is a problem, speak up and perhaps we'll work 
> on the problem again (I can share links to preliminary work we did, 
> which was never officially published).Like I said above, XMPP should have at least the proxy feature that SIP has. That
will make it "competitive" and will go a long way towards SIP-XMPP interoperability.> 
> Peter
> 
>

to, 2008-09-11 kello 11:28 -0700, ext Sanjay Pujare kirjoitti:
> Proxies or intermediate routers are very useful for the simple reason that they
> facilitate routing that can be controlled dynamically. Also imagine cases where XMPP
> is not the only protocol for IM and presence. SIP/SIMPLE is also there (in fact that
> is the reason for this inter-operability newsgroup!). By forcing inter-domain XMPP
> communication to happen only between their respective XMPP servers we are precluding
> possibilities of various proxy services doing translations and such stuff.Actually, I consider this a feature not a bug. A major reason for
complexity in SIP is exactly because the SIP architecture allows for
0...n proxy chains between user agents that can then do various proxy
"services". 

In reality, most of these services are related to either NAT traversal
or correcting bad interop and are performed not by proxies but by
Session Border Controllers (SBCs), which are black boxes.

The implicit architecture is the same as with XMPP: clients talk to
servers (using SIP outbound), and servers talk to other domains (over
mutually authenticated TLS).

Cheers,
Aki

--- Aki Niemi  wrote:

>... 
> Actually, I consider this a feature not a bug. A major reason for
> complexity in SIP is exactly because the SIP architecture allows for
> 0...n proxy chains between user agents that can then do various proxy
> "services". 
> 
> In reality, most of these services are related to either NAT traversal
> or correcting bad interop and are performed not by proxies but by
> Session Border Controllers (SBCs), which are black boxes.I didn't understand why this is relavant to the issue of proxies being important.> 
> The implicit architecture is the same as with XMPP: clients talk to
> servers (using SIP outbound), and servers talk to other domains (over
> mutually authenticated TLS).In SIP, interdomain communication can go thru intermediate proxies whereas XMPP just
does not support it. XMPP forces domain servers to talk to each other directly.> 
> Cheers,
> Aki
>       
> -- 
> Aki Niemi
> Maemo Software, Nokia Devices R&D
> 
>

Sanjay Pujare wrote:
> --- Aki Niemi  wrote:
> 
>> ... 
>> Actually, I consider this a feature not a bug. A major reason for
>> complexity in SIP is exactly because the SIP architecture allows for
>> 0...n proxy chains between user agents that can then do various proxy
>> "services". 
>>
>> In reality, most of these services are related to either NAT traversal
>> or correcting bad interop and are performed not by proxies but by
>> Session Border Controllers (SBCs), which are black boxes.
> 
> I didn't understand why this is relavant to the issue of proxies being important.You haven't explained why proxies are important, other than to say "SIP 
has proxies".>> The implicit architecture is the same as with XMPP: clients talk to
>> servers (using SIP outbound), and servers talk to other domains (over
>> mutually authenticated TLS).
> 
> In SIP, interdomain communication can go thru intermediate proxies whereas XMPP just
> does not support it. XMPP forces domain servers to talk to each other directly.Yes, and that has beneficial security properties -- among them, it's 
easier to check the identity of a peer server (either via server 
dialback or SASL authentication) and it's easier to ensure channel 
encryption between trust domains.

Peter

Okay I will try to describe a use-case to make my point: imagine there are N XMPP
domains and they all would like to communicate with each other. That would require
N*(N-1) trust relationships to be established based on server-to-server
communication.

On the other hand if there is a trusted single proxy there is a need to establish
only N trusted relationships (from the N domains to the single proxy).

In the above case the N XMPP domains could be combination of independent Internet
domains and some Intranet domains (where a proxy will be more useful).--- Peter Saint-Andre  wrote:

> > ...
> > I didn't understand why this is relavant to the issue of proxies being
> important.
> 
> You haven't explained why proxies are important, other than to say "SIP 
> has proxies".
> 
> ....
> Yes, and that has beneficial security properties -- among them, it's 
> easier to check the identity of a peer server (either via server 
> dialback or SASL authentication) and it's easier to ensure channel 
> encryption between trust domains.
> 
> Peter
> 
>

Sanjay Pujare wrote:
> Okay I will try to describe a use-case to make my point: imagine there are N XMPP
> domains and they all would like to communicate with each other. That would require
> N*(N-1) trust relationships to be established based on server-to-server
> communication.We've been doing that since 1999 over the open Internet with very few 
problems. Running code is good.

What kind of trust relationships do you envision? Something more than 
DNS checking (server dialback) or X.509 certs (SASL auth)?

Please note that XMPP does not have a peering model, as you might be 
famliar with from the telco world. We have more of a dynamic federation 
model, like email.> On the other hand if there is a trusted single proxy there is a need to establish
> only N trusted relationships (from the N domains to the single proxy).In practice, not everyone is going to trust your "trusted single proxy".

Now, I can imagine that certain industry groups might want a single 
source of trust -- say, all the financial companies might trust Reuters 
or whatever -- but the model there might still involve separate XMPP 
servers with a trusted CA that issues certs for all those servers. No 
need for a communications proxy.> In the above case the N XMPP domains could be combination of independent Internet
> domains and some Intranet domains (where a proxy will be more useful).As to deploying an XMPP server on an intranet but connecting it to the 
broader network, I think that's a deployment issue (e.g., do you put it 
in the DMZ etc.), not a protocol issue.

Peter

--- Peter Saint-Andre  wrote:

> ...
> We've been doing that since 1999 over the open Internet with very few 
> problems. Running code is good.
> 
> What kind of trust relationships do you envision? Something more than 
> DNS checking (server dialback) or X.509 certs (SASL auth)?I am thinking of X.509 certs. Server dialback only protects again domain spoofing
and does not give me encrypted channel.> 
> Please note that XMPP does not have a peering model, as you might be 
> famliar with from the telco world. We have more of a dynamic federation 
> model, like email.I guess this is a matter of opinion, but dynamic federation like email is not the
best model to emulate.> 
> ...
> In practice, not everyone is going to trust your "trusted single proxy".
> 
> Now, I can imagine that certain industry groups might want a single 
> source of trust -- say, all the financial companies might trust Reuters 
> or whatever -- but the model there might still involve separate XMPP 
> servers with a trusted CA that issues certs for all those servers. No 
> need for a communications proxy.
> 
> ...
> As to deploying an XMPP server on an intranet but connecting it to the 
> broader network, I think that's a deployment issue (e.g., do you put it 
> in the DMZ etc.), not a protocol issue.So having something in the protocol that makes deployment easier or gives us
different architectural options is not a good idea?

In any case as I was saying earlier, in the mixed XMPP-SIP (SIMPLE) world, it
becomes easier to support interoperability if XMPP also had proxies. In the absence
of that each SIP domain needs an XMPP gateway (or each XMPP domain needs a SIP gateway?)

Sanjay Pujare wrote:
> --- Peter Saint-Andre  wrote:
> 
>> ...
>> We've been doing that since 1999 over the open Internet with very few 
>> problems. Running code is good.
>>
>> What kind of trust relationships do you envision? Something more than 
>> DNS checking (server dialback) or X.509 certs (SASL auth)?
> 
> I am thinking of X.509 certs. Server dialback only protects again domain spoofing
> and does not give me encrypted channel.Sure, we know that. Which is why RFC 3920 provides support for TLS+SASL, 
and why we have been busy handing out free certificates to XMPP domains 
at the xmpp.net service. Naturally, any other CA can issue certs, too.>> Please note that XMPP does not have a peering model, as you might be 
>> famliar with from the telco world. We have more of a dynamic federation 
>> model, like email.
> 
> I guess this is a matter of opinion, but dynamic federation like email is not the
> best model to emulate.Would you care to justify that assertion? As far as I can see, there is 
a lot more inter-domain communication in the email world and the XMPP 
world (dynamic federation) than there is in the SIP world (formal 
peering). And since the whole point is communication, I'd say that the 
dynamic federation model is "better". As to what the "best" model is, 
I'm not sure yet because I don't know which models you have in mind.

Now, I happen to think that there are more and less secure ways to do 
dynamic federation. Over time we've worked to make XMPP's instantiation 
of that model more secure, and we know that we still have a ways to go 
(e.g., ubiquitous use of TLS+SASL would be good). But we're getting there.>> In practice, not everyone is going to trust your "trusted single proxy".
>>
>> Now, I can imagine that certain industry groups might want a single 
>> source of trust -- say, all the financial companies might trust Reuters 
>> or whatever -- but the model there might still involve separate XMPP 
>> servers with a trusted CA that issues certs for all those servers. No 
>> need for a communications proxy.
>>
>> ...
>> As to deploying an XMPP server on an intranet but connecting it to the 
>> broader network, I think that's a deployment issue (e.g., do you put it 
>> in the DMZ etc.), not a protocol issue.
> 
> So having something in the protocol that makes deployment easier or gives us
> different architectural options is not a good idea?Not if those architectural options introduce unnecessary complexity, new 
security holes, and other problems.

And by the way, nothing in the protocol itself forbids you from 
deploying proxies. For example, you could design a wrapper protocol on 
top of the XMPP core for encapsulating traffic bound for another domain, 
thus making it possible to have multiple hops between servers. However, 
so far no one has seen the need for such an extension. Feel free to work 
with others to develop it if you have a community that's interested in 
such functionality.> In any case as I was saying earlier, in the mixed XMPP-SIP (SIMPLE) world, it
> becomes easier to support interoperability if XMPP also had proxies. In the absence
> of that each SIP domain needs an XMPP gateway (or each XMPP domain needs a SIP gateway?)Personally, I don't see that as a problem. If you want a particular 
service, you deploy the necessary software. Others may disagree.

Peter

Sanjay Pujare wrote:

> I am thinking of X.509 certs. Server dialback only protects again 
> domain spoofingAnd what X.509 certs protects from? From people who don't want to buy 
expensive cert files in "really trusted" CAs (DigiCert, VeriSign, etc)? 
Let's be franky, in X.509 federation "trust" means "buy".>I guess this is a matter of opinion, but dynamic federation like email is not the
>best model to emulate.
>  
>Email has dynamic federation?

16 sep 2008 kl. 23.10 skrev Sanjay Pujare:

> In any case as I was saying earlier, in the mixed XMPP-SIP (SIMPLE)  
> world, it
> becomes easier to support interoperability if XMPP also had proxies.  
> In the absence
> of that each SIP domain needs an XMPP gateway (or each XMPP domain  
> needs a SIP gateway?)
>I think this is a very broad statement. Where do you see the benefit  
from having XMPP proxys in that model?

SIP is also using a federation approach for inter-domain exchange,  
we're not using a central Internet proxy
that relays all calls between domains. That is a telco setup, that is  
not really in the protocol architecture. In fact,
I believe it's against the Internet architecture as specified in the  
IETF RFCs...

Having said that, I believe that there are situations where an XMPP  
proxy is needed, mostly because of
firewall policies or business models that wants the design you  
describe. I have read hints that both Jabberd2
and ejabberd can be configured in a way that you have one central node  
for outbound connections,
S2S, and multiple "inside" nodes with client connections. There might  
be more implementations (or less if I'm wrong).

As much as SBCs (session border controllers) are hated in the SIP  
engineering community, "XMPP proxys"  are
not much mentioned here.
Regardless, I think it would be beneficial to write up a BCP about  
this and invent some terminology, ("XMPP proxy",
"S2S relay", "Outbound XMPP router" ?) since it's very  unclear in the  
specs and in the implementations how you
can implement this feature. I do believe the XMPP community will get  
more and more questions about it.

XMPP routing is not very clear in the application documentation or  
implementations either. A proxy
scenario suggests that I can implement a "default route". In most  
implementations this implies looking
up SRV records and setting up a connection directly. If my worldwide  
enterprise wants to "proxy" these
through a central location, I would like to be able to configure my  
ejabberd/OpenFIre/jabberdx/whatever
server to route all outbound messages through a central trusted server.

I see this as something that will be needed, but I don't agree that it  
is required for SIP/XMPP interoperability.

Just some thoughts from a small cottage outside Stockholm, Sweden.

Regards,
/Olle

Hi Olle,> ...
> Having said that, I believe that there are situations where an XMPP  
> proxy is needed, mostly because of
> firewall policies or business models that wants the design you  
> describe. I have read hints that both Jabberd2
> and ejabberd can be configured in a way that you have one central node  
> for outbound connections,
> S2S, and multiple "inside" nodes with client connections. There might  
> be more implementations (or less if I'm wrong).
> 
> As much as SBCs (session border controllers) are hated in the SIP  
> engineering community, "XMPP proxys"  are
> not much mentioned here.
> Regardless, I think it would be beneficial to write up a BCP about  
> this and invent some terminology, ("XMPP proxy",
> "S2S relay", "Outbound XMPP router" ?) since it's very  unclear in the  
> specs and in the implementations how you
> can implement this feature. I do believe the XMPP community will get  
> more and more questions about it.
> 
> XMPP routing is not very clear in the application documentation or  
> implementations either. A proxy
> scenario suggests that I can implement a "default route". In most  
> implementations this implies looking
> up SRV records and setting up a connection directly. If my worldwide  
> enterprise wants to "proxy" these
> through a central location, I would like to be able to configure my  
> ejabberd/OpenFIre/jabberdx/whatever
> server to route all outbound messages through a central trusted server.
> 
> I see this as something that will be needed, but I don't agree that it  
> is required for SIP/XMPP interoperability.So you agree that proxies or session border controllers (or a relay or a router or
whatever else you want to call it) are useful in the XMPP world. Where they are also
useful for SIP/XMPP interoperability is that the proxy or the SBC can act as a
protocol translator too and then both XMPP and SIP servers can proxy too it
regardless of what the other end is.> 
> Just some thoughts from a small cottage outside Stockholm, Sweden.
> 
> Regards,
> /Olle
>