From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 2 23:08:13 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40581A6FF9 for ; Tue, 2 Sep 2014 23:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 pxXPy_d1lm4X for ; Tue, 2 Sep 2014 23:08:12 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849A21A6FEC for ; Tue, 2 Sep 2014 23:08:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id F1B3714A18E; Wed, 3 Sep 2014 06:08:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4D76514A18D for ; Wed, 3 Sep 2014 06:08:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id FdvrE3DJ2Yrn for ; Wed, 3 Sep 2014 06:08:04 +0000 (UTC) Received: from serpens.de (serpens.de [IPv6:2a00:19e0:3004:219:280:10ff:fe00:1731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E91FB14A183 for ; Wed, 3 Sep 2014 06:08:03 +0000 (UTC) Received: from serpens.de (spz@localhost [127.0.0.1]) by serpens.de (8.14.9/8.13.3) with ESMTP id s8367n2T012529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 3 Sep 2014 08:07:58 +0200 (MEST) Received: (from spz@localhost) by serpens.de (8.14.9/8.12.11) id s8367lEK005379 for ietf-ssh@netbsd.org; Wed, 3 Sep 2014 08:07:48 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6575E14A18E for ; Wed, 3 Sep 2014 05:40:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id sa38Y4RHBjNR for ; Wed, 3 Sep 2014 05:40:52 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7B3BB14A18D for ; Wed, 3 Sep 2014 05:40:52 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id u57so8019089wes.33 for ; Tue, 02 Sep 2014 22:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pFILW9+F9zq6D33QfSf2cjdyEwsTOTsGDuuNHr97Wt4=; b=dUoBV9WOZ5u5pI72QZbnC2AlBw23+DUfGIjU8xmBCV7nBa0cFugZ7YWgjqsEPLrUeD ddzXwEjB3loc/oUizn8S6Dt2CKyz7mrFjZBc9jViLwH+lsOaaRNcc9fFSWIBUlvsiEGL At3+a8fB32lD+jrnw5ffYNWhNAG2pQ9VLzB4mFq9z6l+egkYHr6/OOZNqDdoua8xiW51 DFjpyXM9jtG+ZyX88dIV/LcCigZomQWLxB6Naa5o/4m9/FW4V8cqx1ZEjC57b5xzSAkD KBgcpScgEuNOhxxf1HKFpzXcpjWmvQDKYUQIkxcDWo06eE60hnI0OtJcLgiMtwpT0a5U zDrg== MIME-Version: 1.0 X-Received: by 10.180.14.101 with SMTP id o5mr11591074wic.25.1409722850805; Tue, 02 Sep 2014 22:40:50 -0700 (PDT) Received: by 10.194.165.232 with HTTP; Tue, 2 Sep 2014 22:40:50 -0700 (PDT) Date: Wed, 3 Sep 2014 00:40:50 -0500 Message-ID: Subject: questions about the window size From: Thomas Anderson To: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary=f46d041555fcc10fc4050222ada2 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --f46d041555fcc10fc4050222ada2 Content-Type: text/plain; charset=UTF-8 Section 5.2 of RFC4254 says: The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty. This is the data transfer packet: byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data Since string's are defined by RFC4251 as being "stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string" it's unclear weather or not the uint32 length field contributes to the total or not. Any ideas? It is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. Any insight would be appreciated - thanks! --f46d041555fcc10fc4050222ada2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 5.2 of RFC4254 says:

=C2=A0 =C2=A0The maximum amoun= t of data allowed is determined by the maximum
=C2=A0 =C2= =A0packet size for the channel, and the current window size, whichever
= =C2=A0 =C2=A0is smaller. =C2=A0The window size is decremented by the amount= of data
=C2=A0 =C2= =A0sent. =C2=A0Both parties MAY ignore all extra data sent after the allowe= d
=C2=A0 =C2=A0window is empty.

This is the data transfer packet:

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data

Since string's are defined by RFC4251 as being &quo= t;stored as a uint32 containing its length (number of bytes that follow) an= d zero (=3D empty string) or more bytes that are the value of the string&qu= ot; it's unclear weather or not the uint32 length field contributes to = the total or not. Any ideas?

It is also un= clear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be = decrementing from the window size or not. Any insight would be appreciated = - thanks!
--f46d041555fcc10fc4050222ada2-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 2 23:46:52 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BDF1A702C for ; Tue, 2 Sep 2014 23:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 E5Fmw5iJmnMC for ; Tue, 2 Sep 2014 23:46:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B658E1A86DF for ; Tue, 2 Sep 2014 23:46:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DE18914A193; Wed, 3 Sep 2014 06:46:47 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6B19B14A191 for ; Wed, 3 Sep 2014 06:46:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 4VrzC7esSZ2d for ; Wed, 3 Sep 2014 06:46:42 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2D33D14A190 for ; Wed, 3 Sep 2014 06:46:40 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 872D940020; Wed, 3 Sep 2014 08:46:37 +0200 (CEST) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPS id 649E740002; Wed, 3 Sep 2014 08:46:37 +0200 (CEST) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s836kbit025791; Wed, 3 Sep 2014 08:46:37 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s836ka5a025790; Wed, 3 Sep 2014 08:46:36 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Thomas Anderson Cc: ietf-ssh@netbsd.org Subject: Re: questions about the window size References: Date: Wed, 03 Sep 2014 08:46:36 +0200 In-Reply-To: (Thomas Anderson's message of "Wed, 3 Sep 2014 00:40:50 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Thomas Anderson writes: > Section 5.2 of RFC4254 says: > > The maximum amount of data allowed is determined by the maximum > packet size for the channel, and the current window size, whichever > is smaller. The window size is decremented by the amount of data > sent. Both parties MAY ignore all extra data sent after the allowed > window is empty. > > This is the data transfer packet: > > byte SSH_MSG_CHANNEL_DATA > uint32 recipient channel > string data > > Since string's are defined by RFC4251 as being "stored as a uint32 > containing its length (number of bytes that follow) and zero (= empty > string) or more bytes that are the value of the string" it's unclear > weather or not the uint32 length field contributes to the total or not. Any > ideas? In this context, it should be the amount of channel data, not including the size of the string length field or any other ssh protocol headers. (Unlike the somewhat related global maximum on SSH packet size). > It is also unclear from this RFC whether or not > SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size > or not. DATA and EXTENDED_DATA should be handled in the same way for flow control. So yes, you should decrement the appropriate window size when sending or receiving EXTENDED_DATA. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.