headers
John W Noerenberg II | 1 Nov 2001 03:25

Re: availability of specifications

Excuse me, I'm just peeking in from outside.

 From all this discussion, it appears none of the drafts have made it 
to Marcus or Jeff for consideration by the IESG.  Do I have that 
right?
--

-- 

john noerenberg
jwn2 <at> qualcomm.com
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Darren Moffat | 1 Nov 2001 18:51
Picon

Re: availability of specifications

>Excuse me, I'm just peeking in from outside.
>
> From all this discussion, it appears none of the drafts have made it 
>to Marcus or Jeff for consideration by the IESG.  Do I have that 
>right?

I'm working on them they will be submitted before the cut of date.

--
Darren J Moffat
Permalink | Reply | 8 comments |
headers
Markus Friedl | 8 Nov 2001 12:25
Picon
Favicon

Re: your mail

hi,

if i understand you correctly your problem is that you and i disagree
about what 'window size' means and what data/length is included in the
'window'

if i send a
	byte      SSH_MSG_CHANNEL_DATA
	uint32    recipient channel
	string    data
packet in OpenSSH, i count only the actual size of the data,
and not the size of the complete packet as sent on the wire.

draft-ietf-secsh-connect-11.txt says:
	"The window size is decremented by the amount of data sent."

i don't think that the additional 1+4+4 bytes (byte,uint32,uint32)
should be included in the window size counter. but i could be wrong.
perhaps the draft is ambiguous about this.

what do other implementations do?

i think that only the size of the actual 'payload' data should be
included in the window size, because you usually send
SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data
(e.g. written the data to a socket).

when forwarding/consuming the data received on a channel, OpenSSH does
no longer know over how many packets this data was originally
distributed. so only the length of the payload, the amount of data
(Continue reading)

Permalink | Reply | 5 comments |
headers
Yavor G Georgiev | 8 Nov 2001 13:34
Picon

Re[2]: your mail

Hello Markus,

Thursday, November 08, 2001, 12:25:19 PM, you wrote:

MF> hi,

MF> if i understand you correctly your problem is that you and i disagree
MF> about what 'window size' means and what data/length is included in the
MF> 'window'

MF> if i send a
MF>         byte      SSH_MSG_CHANNEL_DATA
MF>         uint32    recipient channel
MF>         string    data
MF> packet in OpenSSH, i count only the actual size of the data,
MF> and not the size of the complete packet as sent on the wire.

MF> draft-ietf-secsh-connect-11.txt says:
MF>         "The window size is decremented by the amount of data sent."

MF> i don't think that the additional 1+4+4 bytes (byte,uint32,uint32)
MF> should be included in the window size counter. but i could be wrong.
MF> perhaps the draft is ambiguous about this.

MF> what do other implementations do?

MF> i think that only the size of the actual 'payload' data should be
MF> included in the window size, because you usually send
MF> SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data
MF> (e.g. written the data to a socket).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Tatham | 8 Nov 2001 13:22
Picon
Favicon

Re: your mail

Markus Friedl  <markus <at> openbsd.org> wrote:
> what do other implementations do?
> 
> i think that only the size of the actual 'payload' data should be
> included in the window size, because you usually send
> SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data
> (e.g. written the data to a socket).

Speaking for PuTTY: I agree with you, and in fact it hadn't occurred
to me that there was any other way to do it.
--

-- 
Simon Tatham         What do we want?        ROT13!
<anakin <at> pobox.com>   When do we want it?     ABJ!
Permalink | Reply | 0 comments |
headers
Markus Friedl | 8 Nov 2001 13:48
Picon
Favicon

Re: your mail

On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote:
> Yes you got me right.
> I assume the data to be the last part in the following example packet:
>          byte      SSH_MSG_CHANNEL_DATA
>          uint32    recipient channel
>          string    data
> the one that is type string, which includes 4 more bytes for the
> length.

i think the 4 string-len bytes should _not_ be included, since
it should not matter for the window size whether a payload data
of 10 bytes arrives in one or in 4 messages.

if you include the 4 bytes in the window size then you count
packets.

-m
Permalink | Reply | 2 comments |
headers
Mats Gustafsson | 8 Nov 2001 16:22
X-Face
Picon
Picon

A future for the SSH File Transfer Protocol?


Hi everyone,

The "SSH File Transfer Protocol" draft has expired and I can find
no reference to SFTP in the mailing list archive since August. This 
makes me wonder if there is anyone out there who still sees a future
for SFTP and is working on it.  Should there be a "SSH File Transfer 
Protocol" or is "Securing FTP with TLS" (draft-murray-auth-ftp-ssl-08.txt)
the way forward? 

I'd appreciate greatly if someone on this list that could fill me in on 
past and present discussions on the subject or simply share their opinions!

Best regards,
//Mats

----------------------------------------------------------------
Mats Gustafsson                
Ericsson Radio Systems
----------------------------------------------------------------
Email            : Mats.C.Gustafsson <at> era.ericsson.se
Visiting address : Dataringen 4, Linköping
Postal address   : Box 1248, SE-581 12 Linköping, Sweden
Telephone        : +46 13 28 4715
ECN #            : 868 4715
----------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Simon Tatham | 8 Nov 2001 16:40
Picon
Favicon

Re: A future for the SSH File Transfer Protocol?

Mats Gustafsson  <Mats.C.Gustafsson <at> era.ericsson.se> wrote:
> The "SSH File Transfer Protocol" draft has expired and I can find
> no reference to SFTP in the mailing list archive since August.

As far as I can tell there's very little _at all_ in the mailing
list archive since August ...

> This makes me wonder if there is anyone out there who still sees a
> future for SFTP and is working on it.

I do. I think it's extremely useful to have a file transfer protocol
within the framework of SSH, because most security-conscious people
accessing a remote account will already have set up SSH
authentication credentials.

Moreover, SFTP is a qualitative improvement over SCP, partly because
it's more general and can usefully be used for complex automated
tasks, partly because it's actually vaguely _possible_ to secure a
client against a malicious server (SCP has a wildcard issue that
makes this highly inconvenient), and largely because the range of
clients you can plausibly write is so much greater. PuTTY's SCP
client now uses SFTP as the underlying protocol whenever it can,
falling back to the old unreliable SCP only when it has no choice.

I might be the only one, however; nobody has shown much interest in
answering my clarifying questions or in the extension I proposed (to
allow user details to be looked up, so a client could understand
`~fred' and also so that the uid->username mapping in the
recommended form of the long listing could be done in other contexts
as well).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Altman | 8 Nov 2001 16:51
Favicon

Re: A future for the SSH File Transfer Protocol?

Why should a client ever have to understand a system dependent alias
such as ~fred?

The only entity that should need to know how to map ~fred to what it
points to is the sender of the file.

> 
> I might be the only one, however; nobody has shown much interest in
> answering my clarifying questions or in the extension I proposed (to
> allow user details to be looked up, so a client could understand
> `~fred' and also so that the uid->username mapping in the
> recommended form of the long listing could be done in other contexts
> as well).
> 
> Cheers,
> Simon
> -- 
> Simon Tatham         "What a caterpillar calls the end of the
> <anakin <at> pobox.com>    world, a human calls a butterfly."
> 

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project  <at>  Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 kermit-support <at> kermit-project.org          OpenSSL.  SSH soon to follow.
Permalink | Reply | 5 comments |
headers
Simon Tatham | 8 Nov 2001 17:02
Picon
Favicon

Re: A future for the SSH File Transfer Protocol?

Jeffrey Altman <jaltman <at> columbia.edu> wrote:

> Why should a client ever have to understand a system dependent alias
> such as ~fred?
> 
> The only entity that should need to know how to map ~fred to what it
> points to is the sender of the file.

Ah; you think it would be better for servers to understand `~fred'
at the start of a pathname?

Fair enough, I suppose. But the rest of the ethos of SFTP seems to
be that whatever alias or synonym you use to refer to a directory,
you can always call FXP_REALPATH and get the full canonical name. So
in my command-line SFTP client, I don't want to type `cd ~fred' and
then have `pwd' just tell me `~fred'; I'd rather get the same
behaviour I get at the real shell prompt, where I type `cd ~fred'
and `pwd' tells me `/home/fred'.

I suppose that could be done just by making the server understand
`~fred' at the start of a pathname, and then having the client call
FXP_REALPATH("~fred") if it wanted the canonical form; but that
starts to eat into the available characters in filenames, which is
something SFTP has so far been scrupulous in not doing. So instead,
my proposal was to introduce a protocol extension which allowed the
client side to request the home directory of a particular user.

While I was at it, I also added name<->number mappings for users and
groups, on the grounds that it seems silly that a command-line
client can list the textual usernames of file owners by printing out
(Continue reading)

Permalink | Reply | 4 comments |

Gmane