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

Peter Saint-Andre - &yet <peter@andyet.net> Fri, 13 February 2015 16:21 UTC

Return-Path: <peter@andyet.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9558D1A8740 for <stox@ietfa.amsl.com>; Fri, 13 Feb 2015 08:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ_6RQCkENH5 for <stox@ietfa.amsl.com>; Fri, 13 Feb 2015 08:21:42 -0800 (PST)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8258D1A8777 for <stox@ietf.org>; Fri, 13 Feb 2015 08:21:22 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id l13so11503106iga.5 for <stox@ietf.org>; Fri, 13 Feb 2015 08:21:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f+AhX5mgB0CIuHdH729NkveJheISN0OhhlCe7l18BBc=; b=VhkHjF+DylP4qwmtjEwJBZ/Jc/QXI0f6giqj7uSlko4pgCjOZkXNtn2WTDiS+QSw0O 3BqcN8CNcttx9uoOvhgN6Bv87UDg0k8PGNT3PQRTJW7fu9G8l6YbUWsNHiifM6DXOrQ9 +4uuBLKepRQ32uRk1TqayO8X2BNS4d1x5FgwKajuP3GH1IPHNeyNsTDLPRDBhft+Za9Y Jvtf8a8dEBL1lM7gHp1BiiNWQbcN0AEGXipguV7s5xoU3PdkANu5kd8vM5jT4fDH5MJm kBe1H4/uz+F4a4hqSAzJpVdNi6cF6DhfPJef+FHspsFFKwX9ZsHObhwg+QXBpxVib0Kq vrkg==
X-Gm-Message-State: ALoCoQnPXFGmf2goSIE4GFisnZDDCmgs3t11kbotnzoPoHLod1zHOTMvGYQi0DhxFJvap4Nov1BZ
X-Received: by 10.50.32.71 with SMTP id g7mr4786380igi.4.1423844481829; Fri, 13 Feb 2015 08:21:21 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n4sm3470444igr.15.2015.02.13.08.21.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 08:21:21 -0800 (PST)
Message-ID: <54DE2480.7060501@andyet.net>
Date: Fri, 13 Feb 2015 09:21:20 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <E77F1000-DD04-44E7-9636-348DA463E6E8@nostrum.com> <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <DEC2CB7F-6A39-4E1D-8B6D-82252399F891@nostrum.com> <54DD28F4.7070200@andyet.net> <AD925407-4003-479D-92AF-B60A5EC6594F@nostrum.com> <54DD6CCA.2020605@andyet.net> <5228A173-7B2F-49BA-AA38-F63B70B8DD39@nostrum.com> <54DD7626.40704@andyet.net>
In-Reply-To: <54DD7626.40704@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/Iij6-zslk18eRHsQM9SA36L0caE>
Cc: "stox@ietf.org" <stox@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "draft-ietf-stox-im.all@tools.ietf.org" <draft-ietf-stox-im.all@tools.ietf.org>
Subject: Re: [Stox] Comments on draft-ietf-stox-im-11
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2015 16:21:45 -0000

On 2/12/15 8:57 PM, Peter Saint-Andre - &yet wrote:
> On 2/12/15 8:30 PM, Ben Campbell wrote:
>>
>>
>>
>>> On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet
>>> <peter@andyet.net> wrote:
>>>
>>>> On 2/12/15 7:58 PM, Ben Campbell wrote:
>>>>
>>>>> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet
>>>>> <peter@andyet.net> 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).
>
> ###

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/