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

From: Adam Roach <[email-masked]>
Date: Wed, 05 Jul 2006 20:43:37 -0500

I have a few relatively broad comments on the draft.

1. MIME Types

    The document omits a discussion of MIME types. In particular, I
    think you'll find that many (or most) SIMPLE implementations use
    something slightly more sophisticated than text/plain for instant
    messaging (text/html, for example, seems quite popular).

    I'm not familiar with how XMPP handles rich message content,
    although RFC 3921 hints at the ability to embed XHTML message bodies
    in <message/> elements.

    I would suggest that the mapping document would be far more helpful
    if it contained a brief discussion of at least the mapping from
    SIMPLE messages with text/html bodies and XHTML content in XMPP
    messages.

    As far as I know, the only complete answer for other MIME types in
    general is the use of RFC 3923. The document should probably either
    explicitly rule non-text MIME types out of scope or mention RFC 3923
    as a solution for non-text MIME types.

2. Infinite Message Amplification

    If I read section 4.2 correctly: when the gateway receives an XMPP
    <presence/> stanza with type='subscribe', the gateway is responsible
    from that moment until the subscriber sends a <presence/> stanza
    with type='unsubscribe' (which may never happen) for maintaining not
    just the record of the subscription, but an actual live subscription
    -- complete with SUBSCRIBE refreshes -- to the SIP entity.

    Is that right?

    This seems to be a Really Bad Thing, both from a general scalability
    perspective (maintaining live SIP subscriptions for entities that
    are offline) and from a security perspective (one message in,
    infinite messages out makes for a mighty fine traffic amplifier).

    Unfortunately, I don't have any suggestions here, although the bare
    minimum that the draft needs to do is detail these properties more
    prominently -- including some discussion in the Security
    Considerations around the infinite-message amplification properties
    proposed by the document.

    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.

3. Subscription Permission Indication

    The receipt of a 200-class response to a SUBSCRIBE message means
    that the SUBSCRIBE message has been received. It does not mean that
    permission to subscribe to the resource has been granted. The only
    way to know that permission to subscribe to the resource has been
    granted is the receipt of a NOTIFY message with a
    "Subscription-State:" header field of "active".

    Based on the text in section 6.2 of RFC 3921, I believe that XMPP
    uses <presence/> with a type of 'subscribed' to indicate that
    permission has been granted.

    The mapping document suggests mapping the 200-class response to a
    <presence/> stanza of 'subscribed'. This is a semantic mismatch. The
    <presence type='subscribed'/> stanza should be withheld until a
    NOTIFY arrives with a Subscription-State of "active." Similarly, if
    a NOTIFY arrives that contains a Subscription-State of "terminated"
    with a reason code of "rejected" or "noresource", the gateway should
    send a <presence type='unsubscribed'/> stanza. Any other NOTIFYs --
    that is, other Subscription-States and/or other reason codes
    shouldn't trigger a <presence/> stanza at all, since they don't have
    implications about whether subscription permission has been granted.

/a

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> (Cross-posted to the SIMPLE and XMPP lists.)
>
> Because draft-saintandre-xmpp-simple appears to have reached stability,
> it seems appropriate to request an unofficial last call on this document
>  (which has perhaps the longest title in IETF history).
>
> The I-D is available here:
>
> http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-07.txt
>
> http://www.xmpp.org/drafts/draft-saintandre-xmpp-simple-07.html
>
> Please note that this I-D seeks to define only basic presence and
> messaging interoperability between SIMPLE and XMPP systems. Use cases
> such as extended presence, chat and multi-party messaging, and file
> transfer are not covered by this specification, but may be discussed in
> future I-Ds.
>
> Feedback may be sent directly to me, to all three authors, or to either
> or both of the lists.
>
> Thanks!
>
> Peter
>
> - --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.shtml
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEhhC6NF1RSzyt3NURAtjJAJ9LW+cttgPCKwK8ViYP5KEagn5qegCdFtR+
> cx34mhV520JK9Diwvw3wdaY=
> =s8TL
> -----END PGP SIGNATURE-----
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Jul 2006 11:48:05 -0600

Hi Adam, thanks for the feedback. Comments inline.

>    messaging (text/html, for example, seems quite popular).

Yes, I was talking with an implementor recently and realized that the
draft needs to discuss handling of various MIME types. It would be
helpful to know which types are in broad use, since my understanding is
that any MIME type is allowed.

>    although RFC 3921 hints at the ability to embed XHTML message bodies

We've defined an XHTML 1.0 Integration Set for HTML message bodies:

http://www.jabber.org/jeps/jep-0071.html

>    SIMPLE messages with text/html bodies and XHTML content in XMPP

Agreed.

>    as a solution for non-text MIME types.

For now, I think it would be best to specify that implementations MUST
handle text/plain, SHOULD handle text/html (text to follow), and MAY
handle other MIME types (leaving the handling of other types up to the
implementation).

>    -- complete with SUBSCRIBE refreshes -- to the SIP entity.

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.
If the text in the I-D is not clear on that point, I'll fix it.

>    are offline) 

That concern could be addressed by specifying that a gateway must not
maintain the live subscription on the SIP side for XMPP entities that
are offline, which seems appropriate.

>    and from a security perspective (one message in,

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).

>    permission has been granted.

That's right.

>    implications about whether subscription permission has been granted.

Thanks, I'll correct that.

Furthermore, I've received feedback off-list that it would be helpful
for this document to specify a mapping of various error and status
codes, so I'll add that to the next version, as well.

Peter

---

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

> 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.

> mapping (except for the caveats above about unapproved subscriptions and

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 06 Jul 2006 19:47:16 -0500

/a