"last call" on SIMPLE-XMPP interworking I-D

On Wed Jul 19 16:54:32 2006, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > I suspect that the simplest method is to recommend
restricting 
> access to
> > the XMPP side of the XMPP/SIMPLE gateway to a
single XMPP domain, 
> and
> > recommending that sensible limits should be put on
the number of 
> users
> > allowed to connect to a server from the same
address.
> > > This, I think, forces such an attack to be
done by the attacker 
> finding
> > a bunch of zombie machines creating the users on
the XMPP domain 
> (if
> > possible), and performing the subscription. The
thing is, why on 
> earth
> > would you bother when you could just flood the SIP
presence server
> > directly with your zombie army?
> 
> Because, according to Adam, the mismatch between SIP
presence
> subscriptions (short-lived) and XMPP presence
subscriptions 
> (long-lived)
> means that the attacker can save some bytes by
attacking from the 
> XMPP
> side of the wormhole rather than from the SIP side,
thus presumably
> making the attack less expensive in terms of bandwidth
and 
> processor.

Yes.

Now re-read the paragraphs I've quoted of my own again,
this time 
together as opposed to in isolation.

A traditional "Jabber transport" would allow
gatewaying through it 
from any Jid. If instead the XMPP/SIMPLE transport only
allows 
gatewaying through it from its local XMPP domain, then in
order to 
mount the attack, the attacker has to obtain several
thousand 
accounts on that server.

Now, this ought to be very easily detectable - a sudden
surge of 
thousands of account creations is bound to raise some
eyebrows, and 
if the accounts aren't created via JEP-0077, but via an
"email the 
password" style mechanism, this is going to be
considerably harder to 
manage. It'd be virtually impossible to do this anyway on a
single 
machine - you'd need perhaps one machine for every five
accounts 
within your control to hope not to be noticed or hit some
limits. 
That's logistically quite a tall order, no matter how many
zombies 
there are these days.

Also, it means that in order to create the XMPP sessions,
register 
the user, and so on, it's going to cost the attacker
considerably 
more before the amplification attack starts to kick in - and
since 
you require such a huge zombie army to mount the attack
anyway, you 
might as well attack directly.

But, if you can write yourself a few servers, instead of
clients, to 
do this work, you need far fewer zombie machines, and much
less 
resource, since you can more or less setup a dummy s2s and
start 
spewing presence stanzas about. That's why I'm proposing
that a large 
part of the solution - without crippling XMPP in the process
- ought 
to involve prevention of this method.

Of course, you could combine both Adam's proposal and this
- only 
remote clients get the spurious <iq> hacks.

Dave.
-- 
Dave Cridland - mailto:davecridland.net - xmpp:dwdjabber.org
  -
acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple

"last call" on SIMPLE-XMPP interworking I-D

Thread: "last call" on SIMPLE-XMPP interworking I-D