Subject: [xmpp] Fwd: I-D Action:draft-sato-xmpp-software-message-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Mar 2010 09:53:32 -0700

Just saw this come across the wire...

-------- Original Message --------
Subject: I-D Action:draft-sato-xmpp-software-message-00.txt
Date: Mon,  1 Mar 2010 08:45:01 -0800 (PST)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Considerations of software generated message on XMPP
	Author(s)       : H. Sato, N. Ogashiwa
	Filename        : draft-sato-xmpp-software-message-00.txt
	Pages           : 6
	Date            : 2010-03-01

In RFC2779 [RFC2779] and RFC2778 [RFC2778], XMPP [RFC3920] client
is defined as "PRINCIPALS are the people, groups, and/or software
in the "real world" outside the system that use the system as a
means of coordination and communication.  Considering this
description, it does not matter whether the user of end node is
human or software. However, current specification of XMPP is
expected that there will be a human in front of the client. So,
there is no consideration for looping the message between softwares
and processing message that human will not be able to react.
Recently system and software are replying in return of
human. Moreover, by making client act like a human, new network
service can be made.  There are many of these called "bots"
already, but there is a possibility which can aggregate or control
remote resources.By clarifying models of usage and problem, this
document aims to use XMPP in software-to-software and
human-to-software models not only human-to-human model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sato-xmpp-software-message-00.txt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Mar 2010 13:39:19 -0700

On 3/1/10 9:53 AM, Peter Saint-Andre wrote:
> expected that there will be a human in front of the client.

I'm curious to know why the authors of draft-sato-xmpp-software-message
(now in version -01) claim that the "current specification of XMPP is
expected that there will be a human in front of the client". XMPP is
used for all sorts of applications in which there is no human in front
of the client.

It is true that automated processes can send a large number of messages
to a recipient. We have already seen this used in the wild for DoS
attacks. The solution is to use something like privacy lists (now
defined in XEP-0016 but originally in RFC 3921) or "simple
communications blocking" (XEP-0191).

Peter

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 09 Mar 2010 22:14:03 +0100

> Just saw this come across the wire...

The "message loop problem" should not happen in XMPP (3920bis 9.3.1):
"An entity that receives an error stanza MUST NOT respond to the stanza
  with a further error stanza; this helps to prevent looping."

I expect this to work better than the workaround IRC has in RFC 1459
(4.4.2).

---

From: Hirotaka Sato <[email-masked]>
Date: Wed, 10 Mar 2010 20:10:22 +0900

> used for all sorts of applications in which there is no human in front

We assumes that tens of thousands of software agent of machines are
sending presence and messages and its acknowledgements. Also we are
planning to make a system which enables users to control machines by
messages via XMPP.
For example, in Many Software-to-Many Software in multi user
chat(defined in 2.2-d in our draft), there is a possibility that some
specific server can be overloaded. One thing we can do with this is
that by sending back pressure to senders, we can prevent more message
would be sent. However in current XMPP specification, PRINCIPALs have
to be intelligent enough to make a flexible control. When XMPP is
widely used as machine-to-machine or human-to-machine connection,
flexible and dynamic adjust system which will work with not smart
PRINCIPAL will be vital.

> communications blocking" (XEP-0191).
"Simple communications blocking"(XEP-0191) is a good solution for DoS
attack. However we think it is important to have a mechanism which
deals with valid messages. What we discussed in our draft is not
attacks but valid messages which are sent too many. From this aspect
we think it is good to have loop detection or loop avoidance or back
pressure in XMPP protocol.

> Peter
Hirotaka Sato
Kyoai Gakuen College

---

From: Hirotaka Sato <[email-masked]>
Date: Wed, 10 Mar 2010 20:13:08 +0900

> I expect this to work better than the workaround IRC has in RFC 1459

We want to control valid messages not error messages. We thought it
would most likely happen machine-to-machine model. And that was the
reason why we submitted our draft.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Mar 2010 06:11:12 -0700

> reason why we submitted our draft.

It sounds to me as if you want to work on some kind of XMPP extension,
not changes to the core of XMPP (3920bis + 3921bis), so you will
probably end up doing this work at the XMPP Standards Foundation.
However I will take another look at your draft to see.

Peter

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

---

From: Hirotaka Sato <[email-masked]>
Date: Wed, 10 Mar 2010 23:28:45 +0900

> However I will take another look at your draft to see.

We thought of XMPP Extension at first, but if machine-to-machine is regular, we though we should submit to IETF. 

Hirotaka

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Mar 2010 08:09:09 -0700

On 3/10/10 7:28 AM, Hirotaka Sato wrote:
>>>> The "message loop problem" should not happen in XMPP (3920bis
>>>> 9.3.1): "An entity that receives an error stanza MUST NOT
>>>> respond to the stanza with a further error stanza; this helps
>>>> to prevent looping."
>>>> 
>>>> I expect this to work better than the workaround IRC has in RFC
>>>> 1459 (4.4.2).
>>> 
>>> We want to control valid messages not error messages. We thought
>>> it would most likely happen machine-to-machine model. And that
>>> was the reason why we submitted our draft.
>> 
>> It sounds to me as if you want to work on some kind of XMPP
>> extension, not changes to the core of XMPP (3920bis + 3921bis), so
>> you will probably end up doing this work at the XMPP Standards
>> Foundation. However I will take another look at your draft to see.
> 
> We thought of XMPP Extension at first, but if machine-to-machine is
> regular, we though we should submit to IETF.

That's the thing: what are you proposing?

The draft you've submitted seems to be outlining two problems that don't
really exist, in part by assuming that XMPP is human-centric based on
the references in RFC 3920 to RFC 2778 and RFC 2779. But XMPP was not
designed to meet the requirements in those RFCs and predates them.

The first problem you mention is:

3.1 Message loop problem

  One major problem occurs when too many messages are sent in short
  time.  This problem when software sends human a message and the
  software has a bug which sends continuously, most likely the client
  software of human will crash.

Are you seeing this problem in your deployment? If so, I suggest that
you find or develop software that is not so buggy.

The second problem you describe is:

3.2 Receiving / Sending Many Messages from Many Clients

  In some cases, softwares send and receive messages which human
  will not be able to read. However when massive number of PRINCIPAL
  is connecting the XMPP server, it is like a DoS attack.
  Furthermore, when one server receives too many messages it will be
  like a distributed denial of service (DDoS) even if the messages
  themselves are small. In this situation, there is a possibility that
  resources (CPU, Memory, bandwidth and so on) of server and
  specific PRINCIPAL will not be  able to continue connection.

These are known issues -- see XEP-0205 and Section 14.14 of
draft-ietf-xmpp-3920bis-05 for discussion. Typically XMPP servers have
built-in rate limiting (sometimes called "karma") to handle this
problem. If the server implementation you are using in your deployment
does not have rate limiting, I suggest that you use a better server.

Peter

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

---

From: Hirotaka Sato <[email-masked]>
Date: Fri, 12 Mar 2010 00:44:57 +0900

> does not have rate limiting, I suggest that you use a better server.
What we are concerned with that by making an option, we can reduce
messages on flow which we do not need.
I understand that there are many ways to prevent DoS Attacks but current
structure which defined in Section 4.7 and 4.8 of XEP-0205 will reduce not
only spam message but important messages. We want to filter them and get
what we need. The way which defined in Section 4.7 Bandwidth Limits and 4.8
Stanza Limits of XEP-0205 would work simple and effective but it also
exclude message we want.

Hirotaka

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 09:21:29 -0700

> Stanza Limits of XEP-0205 would work simple and effective but it also

Do you want your server to filter inbound messages at the server side?
Is so, then the SIFT extension might provide what you need:

http://xmpp.org/extensions/xep-0273.html

Peter

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

---

From: [email-masked]
Date: Fri, 12 Mar 2010 02:33:09 +0900

Dear Peter,

I'm a co-auther of the draft.
Please find inline comments.

At Thu, 11 Mar 2010 09:21:29 -0700,
Peter Saint-Andre wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; UTF-8 (quoted-printable)>]

Thank you for giving a useful piece of information to us.
But we don't need static filter functions.

We think that technologies just like a path vector, hop count, TTL decrement in 
a routing protocols will be useful to prevent XMPP message loop in 
machine-to-machine situations because those technologies doesn't require
explicit configurations depending on clients or message types.
Therefore, those technologies can be easily applied to MUC with ten thousand clients or
ten thousand independent machine-to-machine communication.

> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> [1.2 S/MIME Cryptographic Signature <application/pkcs7-signature (base64)>]
> 
> [2  <text/plain; us-ascii (7bit)>]

Regards,

Nobuo Ogashiwa

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 11:27:44 -0700

> ten thousand independent machine-to-machine communication.

OK. I look forward to seeing your proposal to solve the problem that you
perceive, despite the fact that I don't perceive the same problem and
despite the fact that I don't think it is in scope for the XMPP WG given
our current charter:

http://tools.ietf.org/wg/xmpp/charters

Peter

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