Subject: [ftpext] Discouraging use of TCP "urgent data"

From: Alexey Melnikov <[email-masked]>
Date: Tue, 21 Sep 2010 14:46:25 +0100

This is somewhat related to FTP: there is currently a document in IESG 
review talking about deprecation (or strong discouragement) of use of 
TCP urgent data:

 <https://datatracker.ietf.org/doc/draft-ietf-tcpm-urgent-data/>

I would like to ask people to review this and tell me how this affect FTP.

Thanks,
Alexey

---

From: "William F. Maton" <[email-masked]>
Date: Tue, 21 Sep 2010 12:57:31 -0400 (EDT)

On Tue, 21 Sep 2010, Alexey Melnikov wrote:

> This is somewhat related to FTP: there is currently a document in IESG review 
> talking about deprecation (or strong discouragement) of use of TCP urgent 
> data:
>

Just taking a quick peek, looks like it isn't relevant to RFC 4217 at 
least, but as section 14 points out, 'FTP uses the Telnet Interrupt 
Process and Data Mark commands in conjunction with Urgent data to preface 
two commands: ABOR (Abort Transfer) and STAT (Status request).'

If 'urgent data' isn't recommended for new apps, then FTP is ...... ?

wfms

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 10:32:28 -0300

Hi, William,

> Process and Data Mark commands in conjunction with Urgent data to
> preface two commands: ABOR (Abort Transfer) and STAT (Status request).'
> 

FTP can get away with its use of urgent data because it's a legacy app
;-) . However, it should set SO_OOBINLINE (or the like) such that the
urgent data is delivered inline.

Please note that Cisco Pix (and probably others) clear the URG bit by
default.... so be prepared for the urgent indications to be unreliable...

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "William F. Maton" <[email-masked]>
Date: Wed, 22 Sep 2010 13:29:05 -0400 (EDT)

> urgent data is delivered inline.

Ouch, the jab hurt. ;-)  Fortunately for one implementation I can attest 
to (wu-ftpd) there's code in there that uses SO_OOBINLINE if the OS 
supports it.  Fortunately you did take the time to put info about that 
flag's support into Appendix A.

> default.... so be prepared for the urgent indications to be unreliable...

So just to think out loud, I'm wondering now if the FTP client should no 
longer depend on ABOR actually working....

wfms

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 22 Sep 2010 19:41:33 +0200 (CEST)

> longer depend on ABOR actually working....

Why? Surely most commands already work fine without URG so why does ABOR 
depend so hard on it?

-- 

  / daniel.haxx.se

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 15:27:16 -0300

Hi, Daniel,

>> So just to think out loud, I'm wondering now if the FTP client should
>> no longer depend on ABOR actually working....
> 

To avoid head-of-line blocking. If the user has e.g. already sent a
number of commands to the FTP server, and then issues an ABOR, you don't
really want the server to process all the commands that are already in
the pipeline, but want it to "jump" to your ABOR. -- and that's what the
TCP urgent mechanism is leveraged for.

Thanks,

---

From: "William F. Maton" <[email-masked]>
Date: Wed, 22 Sep 2010 16:46:34 -0400 (EDT)

> Why? Surely most commands already work fine without URG so why does ABOR 

That's indeed the question I'm asking.  And more importantly, does my 
question influence the FTP spec in any way?  I'm not 100% intimate with 
the FTP spec (and all the implementations) so I don't really know 
conclusively, but I want to find out.

wfms

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 22 Sep 2010 22:55:20 +0200 (CEST)

On Wed, 22 Sep 2010, Fernando Gont wrote:

> To avoid head-of-line blocking. If the user has e.g. already sent a number 
> of commands to the FTP server, and then issues an ABOR, you don't really 
> want the server to process all the commands that are already in the 
> pipeline, but want it to "jump" to your ABOR. -- and that's what the TCP 
> urgent mechanism is leveraged for.

So FTP client implementations actually "pipeline" commands like that without 
waiting for the responses? Isn't that pretty silly in case the first command 
gets an error back?

(I know my implementations never do...)

-- 

  / daniel.haxx.se

---

From: "William F. Maton" <[email-masked]>
Date: Thu, 23 Sep 2010 19:23:36 -0400 (EDT)

> default.... so be prepared for the urgent indications to be unreliable...

Hola Fernando

 	I poked around a bit and shook some trees.  It seems as of PIX OS 
7.0 as well as the ASA 7.0, Cisco allows the URG bit to be controlled so 
it is not cleared - of course as you point out the default is to clear it. 
So perhaps consigning to the dust bin completely may not be as urgent to 
do yet. ;-)

wfms

---

From: Fernando Gont <[email-masked]>
Date: Sat, 25 Sep 2010 09:49:42 -0300

On 23/09/2010 08:23 p.m., William F. Maton wrote:

> it is not cleared - of course as you point out the default is to clear
> it. So perhaps consigning to the dust bin completely may not be as
> urgent to do yet. ;-)

I really doubt that any admin will override this default behavior.... :-)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 25 Sep 2010 10:01:00 -0300

Hi,

>> number of commands to the FTP server, and then issues an ABOR, you
>> don't really want the server to process all the commands that are
>> already in the pipeline, but want it to "jump" to your ABOR. -- and
>> that's what the TCP urgent mechanism is leveraged for.
> 
> So FTP client implementations actually "pipeline" commands like that
> without waiting for the responses? Isn't that pretty silly in case the
> first command gets an error back?

IIRC, they are allowed to do so. In some cases, it might make sense
(e.g. a large transfer between two remote sites)

Other protocols allow for the same sort of pipelining. e.g., I do recall
the POP3 specification explicitly mentioning this...

Thanks!

Kind regards,