Subject: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D

From: Avshalom Houri <[email-masked]>
Date: Fri, 7 Jul 2006 12:29:49 +0300

Adam,

The attach that your are describing is inherent to the way
that subscriptions are handled in XMPP and in SIP.
In XMPP the subscriptions are long lived while in SIP there are
(in a lot of cases redundant) resubscriptions.

The same attack that your are describing can happen also between
two XMPP servers where the attacker deploys an XMPP server and subscribes
to users on another XMPP server.

Even in SIP, the need of having resubsscribes in SIP does not make a real
difference to the attacker since as long as there is a living TCP
connection there is no problem in sending those refreshes.
The TCP connection itself will have to send keep alives every two hours
is there is no other traffic.

I do not believe that there are mechanisms other then identity and
secure provisioning that will prevent these kinds of attacks.

--Avshalom
       Everything will become a commodity except for human attention (Udi 
Shapiro)

----- Forwarded by Avshalom Houri/Haifa/IBM on 07/07/2006 12:12 -----

Adam Roach <[email-masked]> 
07/07/2006 03:47

To

cc
[email-masked]
Subject
Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D

Peter Saint-Andre wrote:
> I think that the gateway is responsible for maintaining the live
> subscription only if the request has been approved by the SIP user, not
> if the XMPP user has only sent a subscribe without receiving approval.

I suspect you don't quite understand the way subscribers learn about
presence authorization in SIP. Generally, if I subscribe to you and I'm
not yet explicitly authorized (but also not explicitly barred), the
subscription needs to hang around in a "pending" state until the
authorization question is answered (or the subscriber gives up). If the
subscription isn't maintained, there's no way for the gateway to ever
know that permission has been granted.

>>    To be clear about the danger here, I'll outline a potential attack.
>>    I learn that example.net is running an XMPP/SIP gateway to serve
>>    their SIP users. I learn the identity of _one_ SIP user in their
>>    domain. Then, I open up a TCP connection to their gateway, and
>>    introduce myself as a jabber server. I pretend that I have four
>>    thousand users who are interested in the presence state of the one
>>    SIP user I know about in their domain. To do so, I send out four
>>    thousand <presence> requests, each from a unique user; I pace these
>>    out with about a one second gap between each. Now I'm done. I spent
>>    a little over an hour sending XMPP subscription requests; in
>>    response, I have increased the load on the victim SIP server by a
>>    little more than one TPS from now until the heat death of the
>>    universe. If I do it again, I double that additional load. And, of
>>    course, if I blasted the requests out as fast as possible for a day
>>    or two, the devastation would be complete.
>> 
>
> I agree that this attack is bad. But it's not clear to me how this
> attack is different from a similar attack waged by one SIP presence
> server against another SIP presence server. For example, I learn that
> example.net is running a SIP presence server and I learn the identity of
> one SIP user in that domain ([email-masked]). I set up a rogue
> SIP presence server at evil.example.com and I pretend that I have four
> thousand users who are interested in the availability of the hapless
> user. I send a SIP SUBSCRIBE refresh once a minute for each of my four
> thousand fake users. Thereby, I have seriously increased the load on the
> victim SIP presence server at example.net. Unless I'm missing something,
> this seems to be a problem with rogue servers, not with the protocol
> mapping (except for the caveats above about unapproved subscriptions and
> offline users).
> 

The difference is that the rogue SIP server -- the attacker -- needs to
continue to generate traffic in the scenario you describe. For every
SUBSCRIBE that the attacker wants to hit example.net, the attacker must
send one message.

For example, if I'm attacking a SIP server using SIP, the best I can
generally do (modulo some known attacks that we're working to fix) is
send 3600 messages and cause the victim server to process 3600 messages.
This represents no amplification.

In the attack I describe above, an attacker can send 3600 messages, and
cause the victim server (and their gateway) to process 3600 messages
*every* *hour* until the sun expands to engulf the earth's orbit. This
represents nearly infinite amplification.

The difference isn't that subtle. In one case, each message sent by the
attacker causes the victim network to handle one message. In the other,
each message sent by the attacker causes the victim network to handle
approximately 4.4 x 10^13 messages.

/a

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 Jul 2006 11:09:18 -0500

> (in a lot of cases redundant) resubscriptions.

I understand the difficulty, which is why the solution to the problem is 
non-obvious to me. However, I think it would be dangerous and 
irresponsible of the IETF to publish as an RFC a document that describes 
behavior that is effectively a pre-canned zombie attack.

I was hoping that someone with a better knowledge of XMPP than I would 
be able to hop in and say something like, "Oh, yeah, you're right. We 
can solve this by making the subscribing system do a commensurate amount 
of work. The gateway does this by sending a <foo/> stanza to the 
subscriber every time it is about to send a SIP SUBSCRIBE refresh on 
that subscriber's behalf. RFC WXYZ requires the {client,server} to 
respond to the <foo/> stanza with a <bar/> response. As long as the 
gateway requires a <foo/>/<bar/> exchange with the subscribing XMPP 
{client,server} for each SIP SUBSCRIBE refresh, then we're requiring any 
potential attacker to do the work on the same order of magnitude as the 
gateway, which thwarts the amplification attack you describe."

There might be a solution along these lines, and there may not be. There 
may be other approaches that would work. Engineering these solutions 
will require more XMPP knowledge than I possess.

> is there is no other traffic.

Let me bound the time-frame that I am talking about a little bit more. 
Let's consider a single day. Assume the presence subscriptions are 
refreshed every hour. Further, assume the attacker is sending messages 
out at a leisurely 2.7 messages per second -- or 10,000 an hour.

+----------+      +----------+     +--------------+
|   XMPP   |______|  Victim  |     |    Victim    |
| Attacker |   A  | XMPP/SIP |-----| SIP Presence |
+----------+      | Gateway  |  B  |    Server    |
                  +----------+     +--------------+

In the first hour of the attack, the XMPP attacker sends 10,000 presence 
requests across link A. The source of these requests are imaginary users 
1 through 10,000. As a reaction, the gateway sends 10,000 presence 
requests across link B.

So far, so good. The first hour looks just like it would if the gateway 
were a SIP proxy.

At the beginning of the second hour, the gateway sends a refresh to the 
presence server on behalf of imaginary user #1, since his hour is up. At 
the same time, the attacker has sent a subscription request from 
imaginary user #10,001, so the XMPP/SIP gateway sends a subscribe for 
that user as well. About a third of a second later, a the gateway will 
send a similar set of subscribes for imaginary users #2 (refresh) and 
#10,002 (new subscription).

At the end of the second hour, the attacker has sent a total of 20,000 
messages (10,000 the first hour, 10,000 the second hour). The gateway 
has sent a total of 30,000 (10,000 the first hour, and 20,000 the second 
hour).

In the third hour, the attacker sends 10,000 messages for imaginary 
users 20,000 through 29,999. The gateway sends 10,000  corresponding 
messages, plus 20,000 refreshes for imaginary users #1 through #19,999.

By the 24th hour, the attacker has sent a total of 240,000 messages. In 
reaction, he has caused a total of 3,000,000 SUBSCRIBE messages to flow 
between the victim gateway and the victim server. That's better than a 
12:1 amplification. Not bad at all.

Keep in mind: if the attacker decided to stop at this point, the victim 
system would continue to process 5.7 million messages a day because of 
the attack.

Now, let's consider slightly longer time frames.

If the attacker decided to go on with the attack, then at the end of the 
second day, the attacker would have sent 480,000 messages in total, 
while causing the victim system to process 11.7 million messages total 
(24:1 amplification).

By day 3, the numbers are 720,000 and 26.2 million, respectively (36:1 
amplification).

By the end of a week, the attacker will have sent 1.4 million messages, 
while managing to induce the victim system to process 104.4 million 
(74:1 amplification). And again, even if the attack stops at this point, 
the victim system would continue to process 34.5 million messages a day 
without any further effort from the attacker ever again.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Jul 2006 21:31:08 -0600

> gateway, which thwarts the amplification attack you describe."

But XMPP doesn't require that level of work (subscriptions are
long-lived), so it doesn't have protocol semantics for what you describe.

> will require more XMPP knowledge than I possess.

Engineering those solutions would require extensions to XMPP, which
would be optional since they're not part of the core spec, at which
point the potential attacker could simply ignore them. One could attempt
to say that any entity that registers with a gateway must support the
extensions (i.e., a gateway MUST require support for these extensions on
the part of a registering client), but there would be ways around that,
too (e.g., lie when you register).

> out at a leisurely 2.7 messages per second -- or 10,000 an hour.

That's all very nice, but it doesn't solve the problem.

What do you see as the nature of the attack? Is this a denial of service
attack that is made easier via amplification? Or is amplification its
own type of attack?

As far as I can see right now, there are two ways to solve this problem
using existing protocol semantics:

1. Honor the long-lived subscriptions from XMPP but instruct gateway
deployments that they must treat multiple subscriptions from the same IP
or domain with caution, set configurable limits to the number of
subscriptions they will accept, etc.

2. Honor the short-lived subscriptions from SIP and send unsubscribes to
the XMPP entities whenever the subscription is about to time out, thus
forcing the XMPP entity to resubscribe.

Option #2 would force the behavior you are hoping for, since it would
put an equal burden on the XMPP entities as on the SIP presence server,
thus preventing the amplification effect.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Jul 2006 14:14:12 -0400

> long-lived), so it doesn't have protocol semantics for what you describe.

Okay, let's try this again.

I was hoping that someone who knows more about XMPP than I -- say, one of the XMPP RFC authors -- would be sufficiently familiar with the XMPP protocol to hop in with something like: "Oh, yeah, you're right. We can solve this by making the subscribing system do a commensurate amount of work. The gateway does this by sending an <iq type='get'/> stanza to the subscriber's XMPP server every time it is about to send a SIP SUBSCRIBE refresh on that subscriber's behalf. RFC 3920, section 9.2.3, bullet #3, requires (at a MUST strength) the server to respond to the <iq type='get'/> stanza with an <iq type='result'/> or <iq type='error'> stanza. As long as the gateway requires an <iq/> exchange with the subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then we're requiring any potential attacker to do the work on the same order of magnitude as the gateway, which thwarts the amplification attack you describe."

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Jul 2006 12:59:13 -0600

Adam Roach wrote:
> I was hoping that someone who knows more about XMPP than I -- say, one
> of the XMPP RFC authors -- would be sufficiently familiar with the XMPP
> protocol to hop in with something like: "Oh, yeah, you're right. We can
> solve this by making the subscribing system do a commensurate amount of
> work. The gateway does this by sending an <iq type='get'/> stanza to the
> subscriber's XMPP server every time it is about to send a SIP SUBSCRIBE
> refresh on that subscriber's behalf. RFC 3920, section 9.2.3, bullet #3,
> requires (at a MUST strength) the server to respond to the <iq
> type='get'/> stanza with an <iq type='result'/> or <iq type='error'>
> stanza. As long as the gateway requires an <iq/> exchange with the
> subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then
> we're requiring any potential attacker to do the work on the same order
> of magnitude as the gateway, which thwarts the amplification attack you
> describe."

I'm saying that XMPP does have what you want, but in order to enforce
that, on the XMPP end of the wormhole the gateway would need to mimic
short-lived SIP subscription semantics rather than long-lived XMPP
subscription semantics.

Peter

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Jul 2006 15:26:34 -0400

> short-lived SIP subscription semantics rather than long-lived XMPP

Okay; let's do that, then.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Jul 2006 13:47:00 -0600

> Okay; let's do that, then.

Would you prefer it to be a (1) a MUST or (2) a SHOULD with a proviso in
 all caps saying that if you decide to be nice to XMPP clients at the
deployment level then you open up a possible amplification attack (see
the security considerations) and be aware that SIP presence servers
might not refuse to talk with you blah blah blah?

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Jul 2006 14:21:14 -0600

Adam Roach wrote:
> I would be surprised if (2) has any chance of passing IESG muster.
> 
> Personally, I'm uncomfortable with (2), and see (1) as the only
> responsible path forward.

You're probably right, I'll update the draft accordingly in the next
version. Just wanted to be sure that we were in agreement about the
requirements language.

Peter

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Jul 2006 16:07:51 -0400

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 17 Jul 2006 21:22:32 -0600

> Okay; let's do that, then.

Does the following proposed text address the concern?

***

Note: The XMPP-SIMPLE gateway MUST honor the short-lived subscription
semantics of SIP presence subscriptions rather than the long-lived
subscription semantics of XMPP presence subscriptions by passing along
all subscription renewals (i.e., subsequent SUBSCRIBE requests) from the
SIP user to the XMPP user in the form of XMPP presence stanzas of type
"unsubscribe", thus forcing the XMPP user to resubscribe to the presence
of the SIP user; this helps to avoid possible amplification attacks
caused by the mismatch between long-lived XMPP subscriptions and
short-lived SIP subscriptions.

***

Thanks.

Peter

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 19 Jul 2006 08:58:56 -0600

> short-lived SIP subscriptions.

Whoa.  Really?  I can't imagine any of my users being willing to  
deploy such a system.  We can't change the existing clients to handle  
these transparently, so this means their contacts on the other end of  
a SIMPLE gateway are going to be continuously disappearing.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Jul 2006 16:40:27 +0100

On Wed Jul 19 15:58:56 2006, Joe Hildebrand wrote:
> deploy such a system.  We can't change the existing clients to 
> handle  these transparently, so this means their contacts on the 
> other end of  a SIMPLE gateway are going to be continuously 
> disappearing.

I agree - if this is really what's needed, XMPP/SIMPLE gatewaying is 
not going to happen, or else this requirement will be dropped.

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?

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: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 09:54:32 -0600

Dave Cridland wrote:
> I agree - if this is really what's needed, XMPP/SIMPLE gatewaying is not
> going to happen, or else this requirement will be dropped.
> 
> 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.

Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 10:59:43 -0500

Peter Saint-Andre wrote:
> (3) Come up with another solution to the amplification attack scenario
> that Adam brought up.
>   

What about the <iq/> ping-pong that I suggested? I freely admit that I 
don't know enough about XMPP to predict what problems it may cause, but 
a casual read of the related RFCs leads me to believe that it is a 
pain-free solution to the problem with no user impacts.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 11:01:06 -0500

Mridul Muralidharan wrote:
>
> Just to get it clarified , this amplification attack (or similar 
> behavior) is something that exists currently in the SIP/SIMPLE world , 
> irrespective of this XMPP gateway , right ?

No. The problem arises because of the gateway, and does not exist in its 
absence.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 09:59:23 -0600

Mridul Muralidharan wrote:

> If yes , then is this the right document to solve it in ? If no ,
> disregard this mail please.

Yes, the denial of service attack exists in the SIP/SIMPLE world. Adam's
point is that, because SIP subscriptions are short-lived whereas XMPP
subscriptions are long-lived, there is an amplification factor here,
thus making it easier to launch the denial of service attack from the
XMPP side than from the SIP side.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 10:04:26 -0600

> pain-free solution to the problem with no user impacts.

The problem is that the payload of the <iq/> elements will presumably be
qualified by a namespace that is yet to be defined (extensibility rocks)
and therefore the attacker can simply feign ignorance and reply with a
service unavailable error ("sorry, I don't understand that namespace").

Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 11:04:27 -0500

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 11:04:50 -0500

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 10:06:57 -0600

> No. The problem arises because of the gateway, and does not exist in its

IMHO it's eminently possible to launch a denial of service attack on a
SIP presence server without involving any gateways, but it is arguably
easier (using less bandwidth and processor) through a gateway.

Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 11:09:33 -0500

> service unavailable error ("sorry, I don't understand that namespace").

Perfect! That would be absolutely sufficient to thwart the attack.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 10:14:25 -0600

> Perfect! That would be absolutely sufficient to thwart the attack.

Well, OK then. :-)

BTW, in XMPP semantics, an entity MUST reply to the IQ request (with
success or an error). Of course if the entity is an attacker then it
could violate the semantics of the XMPP <iq/> stanza, but there's not
much we can do about that (though I suppose in that case the gateway
could refuse to communicate with the attacker).

Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 11:21:12 -0500

> could refuse to communicate with the attacker).

That's the entire point: if the attacker fails to respond to the <iq/> 
stanza (i.e. isn't willing to do a commensurate amount of work), then 
the gateway fails to refresh the subscription. That's what I meant by, 
"As long as the gateway requires an <iq/> ***EXCHANGE*** with the 
subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then 
we're requiring any potential attacker to do the work on the same order 
of magnitude as the gateway, which thwarts the amplification attack..."

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 10:28:45 -0600

> of magnitude as the gateway, which thwarts the amplification attack..."

OK, I will write up some revised text sometime soon that incorporates
this approach.

Thanks!

Peter

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 19 Jul 2006 11:04:36 -0600

And you thereby made it so that existing clients cannot use the  
gateway.  That doesn't sound too good to me, either.

Would it be good enough to suggest that a gateway SHOULD send an  
existing, highly-implemented iq protocol, like a disco#info? (See  
http://www.jabber.org/jeps/jep-0030.html)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 09:22:25 -0600

Joe Hildebrand wrote:
> Whoa.  Really?  I can't imagine any of my users being willing to deploy
> such a system.  We can't change the existing clients to handle these
> transparently, so this means their contacts on the other end of a SIMPLE
> gateway are going to be continuously disappearing.

That's true, from the XMPP side of things this results in client
behavior that will seem very broken.

You have three alternatives:

(1) Accept the foregoing text and implement a non-conforming service.

(2) Make a better argument than I did for saying that a gateway SHOULD
honor short-lived subscriptions semantics on the XMPP side but MAY honor
long-lived subscription semantics in certain circumstances.

:-)

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 13:06:30 -0600

Mridul Muralidharan wrote:
> Hi Peter,
>  So the gateway will drop session's which do not respond within
> reasonable time/reply with iq error ?
> Is this going to be something that will be sent to the user or to the
> hosting xmpp server ?
> 
> If it is going to be sent to the user , then we are not going to get
> much traction with this approach - most clients will drop it.

Do most clients currently drop disco#info requests? RFC 3920 says you
must at least respond with an error if you don't implement something
(and disco#info is very widely implemented).

> Even a server is not going to help much ... you will need a new breed of
> SIP-SIMPLE/XMPP gateway aware servers before the gateway can 'talk' to
> them.
> If the intention is that the gateway wants to 'behave' as yet another
> XMPP server then none of the existing XMPP server will interop with it
> until they implement this required extension.
> 
> Just a thought - instead of a iq extension , why not get the gateway to
> probe for the presence status of the xmpp user ?

Sure, that's another possibility -- it puts the onus on the server, not
the client. My sense from Adam's original description of the attack was
that he thought it would be launched from a rogue server, but if the
attack were launched from zombie clients the server would take the hit
here and it's up to the server admins to deal with their zombie users
appropriately.

/me ponders

Peter

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Jul 2006 20:11:20 +0100

On Wed Jul 19 16:54:32 2006, Peter Saint-Andre wrote:
> finding

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.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Jul 2006 20:11:23 +0100

On Wed Jul 19 18:50:14 2006, Mridul Muralidharan wrote:
> Is this going to be something that will be sent to the user or to 
> the hosting xmpp server ?
> 
> If it is going to be sent to the user , then we are not going to 
> get much traction with this approach - most clients will drop it.

Well, quite possibly, yes. They'd be breaking XMPP, but they might 
drop it, and I know some clients do.

> Even a server is not going to help much ... you will need a new 
> breed of SIP-SIMPLE/XMPP gateway aware servers before the gateway 
> can 'talk' to them.

No, you need compliant XMPP clients. Nothing special needs to be done 
for this solution.

Dave.

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 14:48:25 -0500

Dave Cridland wrote:
> mount the attack, the attacker has to obtain several thousand accounts 
> on that server.

As far as I can tell, this solves the problem; however, I think it 
breaks the solution for most deployments as well. I foresee these 
gateways being deployed primarily by enterprises who are using one 
system (SIMPLE or XMPP) so that their users can communicate with 
enterprises using the other. Limiting interworking to local users makes 
such use impossible.

> remote clients get the spurious <iq> hacks.

This sounds like a reasonable balance. I think you could extend it 
further and assert that the <iq/> exchanges are required *except* for 
servers on a "known good" list provisioned by the gateway administrator.

/a

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Jul 2006 21:05:17 +0100

On Wed Jul 19 21:05:16 2006, Mridul Muralidharan wrote:
> Hi Dave,
> 
> By drop I was including both cases - ignoring the packet or sending 
> back an iq error.
> In both cases , the required functionality is breaking I guess ?
> 
> 
Adam's proposal treats an iq error as a satisfactory response.

Dave

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Jul 2006 21:10:58 +0100

On Wed Jul 19 20:48:25 2006, Adam Roach wrote:
> enterprises using the other. Limiting interworking to local users 
> makes such use impossible.
> 
> 
Ah... I'm just limiting XMPP usage to local XMPP users. Any SIMPLE 
user can use the gateway.

So for enterprises using XMPP "natively", they would need to run an 
XMPP/SIMPLE gateway (or be on the known good list of another, to 
borrow your suggestion below, but I think in practise they'll want 
their own).

SIMPLE enterprises don't have to run a gateway, although they may 
wish to if they want to ensure they have access to one.

> further and assert that the <iq/> exchanges are required *except* 
> for servers on a "known good" list provisioned by the gateway 
> administrator.

Yes, true.

Dave.

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Jul 2006 15:26:46 -0500

Dave Cridland wrote:
> SIMPLE enterprises don't have to run a gateway, although they may wish 
> to if they want to ensure they have access to one.

While this is a valid deployment model, it is not the one supported by 
the name resolution procedures currently in Peter's draft.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2006 13:06:30 -0600

/me ponders

Peter