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

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Feb 2015 17:27:08 -0600

(No hats)

Hi,

(I apologize that these comments are late in the process. Please feel free to defer them to last call.)

This version mostly looks good, but there are a few minor issues:

-- Message Size

It might be worth a discussion on message size limits (e.g. the SIP MESSAGE method limits the size to 1300 octets except under some pretty narrow circumstances.)

-- Example 3:

This example reverses the From and To in the SIP response (similar to the same issue for stox-chat.)

--section 4, text right above table 1:

The text references stox-chat for additional mappings. But stox-chat references this draft for the same reasons. I realize it's not really a circular reference, but I think it might confuse the reader.

-- Security considerations

I'm a little uncomfortable non-normatively saying we "prefer" the use of RFC3862. My strictly individual opinion is that we should make a normative recommendation, or merely point out the possibility of using 3862. (I realize we do this a lot with the "ought to" construct, but it seems like things like end-to-end crypto could benefit from a less vague approach.)

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 11 Feb 2015 19:16:03 -0700

On 2/9/15 4:27 PM, Ben Campbell wrote:
> It might be worth a discussion on message size limits (e.g. the SIP
> MESSAGE method limits the size to 1300 octets except under some
> pretty narrow circumstances.)

Thank you for pointing this out. I had glossed over it in my reading of 
RFC 3428. I think it deserves a section of its own in the -im document.

> the same issue for stox-chat.)

Will fix.

> The text references stox-chat for additional mappings. But stox-chat
> references this draft for the same reasons. I realize it's not really
> a circular reference, but I think it might confuse the reader.

Hmm. I think it would be best to put them all in the -im document.

> I'm a little uncomfortable non-normatively saying we "prefer" the use
> of RFC3862. My strictly individual opinion is that we should make a
> normative recommendation, or merely point out the possibility of
> using 3862. (I realize we do this a lot with the "ought to"
> construct, but it seems like things like end-to-end crypto could
> benefit from a less vague approach.)

I would prefer to point out the possibility of using RFC 3862. Given 
that no one, to my knowledge, has implemented RFC 3923 in an XMPP 
client, I'd be uncomfortable making that a normative recommendation.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 11 Feb 2015 19:47:29 -0700

> RFC 3428. I think it deserves a section of its own in the -im document.

I propose the following text:

    [RFC3428] specifies that (outside of a media session) the size of a
    MESSAGE request is not allowed to exceed 1300 bytes.  Although in
    practice XMPP instant messages do not often exceed that size, neither
    [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP
    stanzas.  However, XMPP server deployments usually do limit the size
    of stanzas in order to help prevent denial of service attacks, and
    [RFC6120] states that if a server sets a maximum stanza size then the
    limit is not allowed to be less than 10,000 bytes.  Because of this
    mismatch, an XMPP-to-SIP gateway MUST return a <policy-violation/>
    stanza error if an XMPP user attempts to send an XMPP message stanza
    that would result in a SIP MESSAGE greater than 1300 bytes.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Feb 2015 21:07:18 -0600

> On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 

That just stepped in a bit of discomfort on my part, in that I'm not sure how a gateway that happened to support both stox-im and stox-chat decides which to invoke. I'm mostly willing to ignore that particular elephant, but would it be reasonable for an implementation to decide that larger messages would get promoted to MSRP (assuming support at the other end)? If so, the MUST return a <policy-violation/> seems to forbid it.

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 12 Feb 2015 15:28:04 -0700

On 2/11/15 8:07 PM, Ben Campbell wrote:
>>>> (I apologize that these comments are late in the process.
>>>> Please feel free to defer them to last call.)
>>>>
>>>> It might be worth a discussion on message size limits (e.g. the
>>>> SIP MESSAGE method limits the size to 1300 octets except under
>>>> some pretty narrow circumstances.)
>>>
>>> Thank you for pointing this out. I had glossed over it in my
>>> reading of RFC 3428. I think it deserves a section of its own in
>>> the -im document.
>>
>> [RFC3428] specifies that (outside of a media session) the size of
>> a MESSAGE request is not allowed to exceed 1300 bytes.  Although
>> in practice XMPP instant messages do not often exceed that size,
>> neither [RFC6120] nor [RFC6121] sets an upper limit on the size of
>> XMPP stanzas.  However, XMPP server deployments usually do limit
>> the size of stanzas in order to help prevent denial of service
>> attacks, and [RFC6120] states that if a server sets a maximum
>> stanza size then the limit is not allowed to be less than 10,000
>> bytes.  Because of this mismatch, an XMPP-to-SIP gateway MUST
>> return a <policy-violation/> stanza error if an XMPP user attempts
>> to send an XMPP message stanza that would result in a SIP MESSAGE
>> greater than 1300 bytes.
>>
>
> That just stepped in a bit of discomfort on my part, in that I'm not
> sure how a gateway that happened to support both stox-im and
> stox-chat decides which to invoke. I'm mostly willing to ignore that
> particular elephant, but would it be reasonable for an implementation
> to decide that larger messages would get promoted to MSRP (assuming
> support at the other end)? If so, the MUST return a
> <policy-violation/> seems to forbid it.

We've been treating -im (page mode) and -chat (session mode) as entirely 
separate things. However, you're right that "upgrading" from page mode 
(SIP MESSAGE) to session mode (MSRP) might make sense in some 
situations. Without hearing in detail from those who've implemented such 
systems, I would be hesitant to specify guidelines for when such an 
upgrade makes sense. Thus I'd be most comfortable with a SHOULD here and 
leaving the upgrade logic up to implementations.

> (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. In RFC 3921/6121 
we don't have the concept of chunking for 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 
and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a 
message. 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. 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.

Sigh.

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 12 Feb 2015 16:00:35 -0700

> leaving the upgrade logic up to implementations.

Proposed text:

###

6.  Message Size

    [RFC3428] specifies that (outside of a media session) the size of a
    MESSAGE request is not allowed to exceed 1300 bytes.  Although in
    practice XMPP instant messages do not often exceed that size, neither
    [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP
    stanzas.  However, XMPP server deployments usually do limit the size
    of stanzas in order to help prevent denial of service attacks, and
    [RFC6120] states that if a server sets a maximum stanza size then the
    limit is not allowed to be less than 10,000 bytes.  Because of this
    mismatch, an XMPP-to-SIP gateway SHOULD return a <policy-violation/>
    stanza error if an XMPP user attempts to send an XMPP message stanza
    that would result in a SIP MESSAGE greater than 1300 bytes.  Although
    such a gateway might decide to "upgrade" from page mode to session
    mode using the Message Session Relay Protocol (MSRP) and thus
    treating the instant message as part of a chat session as described
    in [I-D.ietf-stox-chat], such behavior is application-specific and
    this document provides no guidelines for how to complete such an
    upgrade.

###

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2015 20:58:45 -0600

> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 
> We've been treating -im (page mode) and -chat (session mode) as entirely separate things. However, you're right that "upgrading" from page mode (SIP MESSAGE) to session mode (MSRP) might make sense in some situations. Without hearing in detail from those who've implemented such systems, I would be hesitant to specify guidelines for when such an upgrade makes sense. Thus I'd be most comfortable with a SHOULD here and leaving the upgrade logic up to implementations.

A SHOULD works for me. Would it make sense to mention the possibility of upgrading, even if the procedures are not specified?

> Ideally we'd be talking about unchunked MSRP messages.

Yes, or a message reassembled from chunks by the gateway.

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

> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a message.

Hmm, you've lost me here. 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?

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2015 21:00:00 -0600

> On Feb 12, 2015, at 5:00 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 

WFM

Thanks!

Ben.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 12 Feb 2015 20:17:30 -0700

On 2/12/15 7:58 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. :/
>>

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.

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

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2015 21:30:39 -0600

> On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 

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.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 12 Feb 2015 20:57:26 -0700

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

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

###

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 13 Feb 2015 09:21:20 -0700

On 2/12/15 8:57 PM, Peter Saint-Andre - &yet wrote:
>> 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.
>

Ben, let me know if that text looks OK. It seems that we'll want to add 
a pointer from the -groupchat document to this section, too, eh?

I think this is the last open issue from your reviews, so once you say 
it's OK I'll submit revised I-Ds for -im, -chat, and -groupchat.

Thanks!

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Ben Campbell <[email-masked]>
Date: Fri, 13 Feb 2015 21:51:38 -0700

On Feb 13, 2015, at 9:21 AM, Peter Saint-Andre - &yet <[email-masked]> wrote:

> Ben, let me know if that text looks OK. It seems that we'll want to add a pointer from the -groupchat document to this section, too, eh?

Yes, and probably. 

> 
> I think this is the last open issue from your reviews, so once you say it's OK I'll submit revised I-Ds for -im, -chat, and -groupchat.

Agreed.