Re: [Stox] Comments on draft-ietf-stox-im-11

[Peter Saint-Andre - &yet <[e-mail]>]

On 2/12/15 8:30 PM, Ben Campbell wrote:
>
>
>
>> On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet <[e-mail]> wrote:
>>
>>> On 2/12/15 7:58 PM, Ben Campbell wrote:
>>>
>>>> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet
>>>> <[e-mail]> wrote:
>>>>
>>>>> On 2/11/15 8:07 PM, Ben Campbell wrote:
>>>>>
>>>>> (While I'm still standing in it--what happens in stox-chat if
>>>>> the MSRP side sends a message larger than the largest allowed?
>>>>> Apologies if the draft talks about that--I don't have it in front
>>>>> of me.)
>>>>
>>>> That's messy. :/
>>>>
>>>> Ideally we'd be talking about unchunked MSRP messages.
>>>
>>> Yes, or a message reassembled from chunks by the gateway.
>>
>> Ah, true. That might give us a way out.
>>
>>>> In RFC 3921/6121 we don't have the concept of chunking afor regular
>>>> chat messages, and the only chunking method we have in XMPP is not
>>>> used for chat messages but for file transfer (XEP-0047). For chat
>>>> purposes, a typical XMPP client won't have the necessary
>>>> application logic to handle chunked messages ...
>>>
>>> Right, that would be the gateway's problem. I had assumed that the
>>> since the gateway is for all practical purposes the MSRP endpoint, it
>>> would reassemble any chunks before sending toward the XMPP side.
>>
>> Right.
>>
>>>> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a
>>>> message.
>>>
>>> Hmm, you've lost me here.
>>
>> That's because I was thinking out loud. :-)
>>
>>> Do you mean the gateway can't assume it's
>>> okay to chunk towards the XMPP client (which makes sense) or towards
>>> the MSRP client?
>>
>> Towards the XMPP client. But as you say that's not necessary.
>>
>>>> However, I don't see a way in RFC 4975 for an entity such as a
>>>> gateway to advertise that it doesn't support chunking.
>>>
>>> There's not a way, because the assumption has always been that any
>>> MSRP endpoint can at least receive chunked messages.
>>>
>>>> Although in theory the max-size a-line could help, that applies to
>>>> full messages before chunking. I also don't see a way in RFC 4975
>>>> to reject a particular MSRP SEND because it's too big.
>>>
>>> You can sort of do this with 413. But I think it's the whole message
>>> size that is important here, not the size of a particular SEND
>>> request.
>>
>> Yes.
>>
>> Let me propose some text. Stay tuned...
>
> This seems like the right track, although it's worth considering how much buffering a gateway might be willing to do, and think about memory depletion attacks. This is mentioned in 4975, so it may already be covered well enough.

True.

Proposed text for a new section in stox-chat...

###

8.  Message Size

    Unlike page-mode messaging [RFC3428] (which specifies that the size
    of a MESSAGE request is not allowed to exceed 1300 bytes), session-
    mode messaging [RFC4975] can be used to send larger messages.  MSRP
    includes a chunking mechanism such that larger messages can be broken
    up into multiple MSRP SEND requests.  Because the MSRP gateway at an
    XMPP service acts as an MSRP endpoint, it is responsible for
    receiving chunked messages and reconstructing them into a single
    message for delivery toward the XMPP recipient.  (Naturally,
    implementations need to be careful about accepting very large
    messages; see Section 14.5 of [RFC4975].)

    Although there is no hard limit on the size of an XMPP stanza, in
    practice most XMPP services (at least on the public Internet) are
    configured with a maximum stanza size in order to help prevent denial
    of service attacks.  As specified in Section 13.12 of [RFC6120], this
    maximum is not allowed to be less than 10,000 bytes.

    The administrators of an XMPP service need to ensure the associated
    MSRP gateway is configured with the same or smaller maximum MSRP
    message size as the maximum XMPP stanza size; this enables the
    gateway to return an appropriate value for the SDP "max-size"
    attribute and to properly handle messages larger than the configured
    limits.

    If an MSRP-to-XMPP gateway implementation receives an MSRP message
    that exceeds its configured limit as just described, it MUST return
    an MSRP 413 error (e.g., in response to the first SEND request whose
    Byte-Range header field indicates a byte total exceeding the limit).

###