Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt

From: David Borman <[email-masked]>
Date: Fri, 5 Feb 2010 13:38:14 -0600

Note: As recent discussions on this list have indicated, we need members of this mailing list to be involved.  Please take the time to read through this document and send a message to the mailing list either supporting publishing this document, or commenting on why it is not ready to be published.  This particular document is quite short and easy to understand.  -David Borman, TCPM co-chair.
----------------------------

This is to announce the start of the WG Last Call for:

Title           : On the implementation of the TCP urgent mechanism
Author(s)       : F. Gont and A. Yourtchenko
Filename        : draft-ietf-tcpm-urgent-data-02.txt
Pages           : 13
Date            : November 26, 2009
Intended Status : Proposed Standard

http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-02.txt

It is our understanding that all the feedback has been incorporated into this latest version and that there are no known outstanding issues with this document.

Please send feedback to the list.

The WGLC will end on Friday, February 19, 2010.

---

From: Michael Welzl <[email-masked]>
Date: Mon, 8 Feb 2010 11:32:53 +0100

Read it, and liked it.

Just a few nits:

It seems a bit pointless to repeat the same text in the introduction  
and in section 2.1 - in
the first paragraph of the introduction, the part that starts with:  
"permits a point in the data
stream to be designated .... " and ends with: "the TCP must tell user  
to go into "normal mode" "
(which, by the way, misses a "the" before "user".)

I think that this part could safely be removed from the introduction  
and just kept in section 2.1,
and the reference at the end of the first paragraph should then be  
moved there too.

Section 3.4:
"As a result of the publication of Network Intrusion Detection (NIDs)  
evasion techniques based on
TCP urgent indications [phrack], some middle-boxes clear the urgent  
indications by clearing the
URG flag and setting the Urgent Pointer to zero."

=> are you 100% sure that this is the result of the publication of  
these techniques?
Otherwise I'd rather state this with "perhaps".

a bit further down:
"Examples of such middle-boxes are Cisco PIX firewall [Cisco-PIX]."

should be "An example of such a middle-box is the ..."

next sentence:
"This should discourage applications to depend"
=>
"This should discourage applications from depending"
(I think - I'm not a native speaker myself)
Cheers,
Michael

On Feb 5, 2010, at 8:38 PM, David Borman wrote:

> Note: As recent discussions on this list have indicated, we need  
> members of this mailing list to be involved.  Please take the time  
> to read through this document and send a message to the mailing list  
> either supporting publishing this document, or commenting on why it  
> is not ready to be published.  This particular document is quite  
> short and easy to understand.  -David Borman, TCPM co-chair.
> It is our understanding that all the feedback has been incorporated  
> into this latest version and that there are no known outstanding  
> issues with this document.
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 10 Feb 2010 12:42:49 -0600

I concur with Michael's suggested edits, plus here are some
more comments.  Overall, I think it's in good shape and just
about ready to publish.  A minor update should be all that's
needed, but I do want to make sure that one of the
recommendations is worded correctly (see final comment below).

Editorial:

- section 1, paragraph 3:
  "IT accommodates" -> "it accommodates" ?

- section 1, paragraph 3:
  "using urgent the urgent" -> "using the urgent"

- section 1, paragraph 4:
  "how current TCP implementations" ->
  "how some current TCP implementations"

- section 3.2, paragraph 1:
  "never reflected into" -> "never was reflected in"

Semi-Technical:

- section 2.3 - on the allowed length of urgent data, should this
  mention that obviously there is a limitation due to the length
  of a sequence number field?  You can't send a terabyte of urgent
  data.

- section 6:
  I think it's not worded correctly when we say that applications
  using the sockets API MUST set SO_OOBINLINE.  What we really
  want to say is more like:

  "Even though applications SHOULD NOT employ the urgent mechanism,
   applications that require the use of urgent data MUST set
   SO_OOBINLINE."

  Right?  Apps that don't use urgent data shouldn't have to be
  bothered by the fact that it's broken.

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>David Borman
>Sent: Friday, February 05, 2010 2:38 PM
>To: [email-masked] WG
>Cc: [email-masked]; [email-masked]; Fernando Gont
>Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt
>
>Note: As recent discussions on this list have indicated, we need members
>of this mailing list to be involved.  Please take the time to read
>through this document and send a message to the mailing list either
>supporting publishing this document, or commenting on why it is not
>ready to be published.  This particular document is quite short and easy
>to understand.  -David Borman, TCPM co-chair.
>It is our understanding that all the feedback has been incorporated into
>this latest version and that there are no known outstanding issues with
>this document.
>

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 10 Feb 2010 13:37:52 -0800

I had reviewed this document in the earlier versions, just a read again
caught this and I am seeking clarification :

=============
5.  Advice to new applications employing TCP

   As a result of the issues discussed in Section 3.4, new applications
   SHOULD NOT employ the TCP urgent mechanism.  However, TCP
   implementations MUST still include support for the urgent mechanism
   such that existing applications can still use it.
================

Why should we be even making this assertion : "new applications SHOULD
NOT" employ urgent mechanism due to what is said in sec 3.4. The
end-to-end semantics may get broken/altered due to many reasons and not
just due to the middlebox fiddling with the URG flag/ptr. I guess my
point is that why this document take pains in recommending something as
a result of a middlebox behaviour. The best I have seen so far in
documents with similar situation is to just mention that middlebox
behaviour and leave it, do not make any recos based on the middlebox
behaviour. 

Makes sense?

-Anantha

PS:- I think this document is ready for LC and the above comment should
not be construed in any way as to obstructing the document to its
advancement to LC status.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Sent: Wednesday, February 10, 2010 10:43 AM
> To: David Borman; Fernando Gont; Andrew Yourtchenko (ayourtch)
> Cc: [email-masked]
> Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt
> 
> >members of this mailing list to be involved.  Please take 
> the time to 
> >read through this document and send a message to the mailing list 
> >either supporting publishing this document, or commenting on 
> why it is 
> >not ready to be published.  This particular document is 
> quite short and 
> >easy to understand.  -David Borman, TCPM co-chair.
> >into this latest version and that there are no known 
> outstanding issues 
> >with this document.
> >

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 11 Feb 2010 00:37:56 +0100 (CET)

Hi Anantha,

> caught this and I am seeking clarification :

We should correct the "3.4" to "3" - i.e. not just middleboxes, but any 
stack that receives the TCP segment with URG flag, will not reliably know 
how exactly to treat it out of three possible interpretations - so any 
application that utilises this mechanism will be inherently very fragile. 
(An example is ABOR with FTP, which does not work correctly most of the 
time).

thanks,
andrew

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2010 00:44:37 -0300

Hi,

Thanks so much for your feedback! Comments inline....

> It seems a bit pointless to repeat the same text in the introduction and
> in section 2.1 - in
> stream to be designated .... " and ends with: "the TCP must tell user to
> go into "normal mode" "
> I think that this part could safely be removed from the introduction and
> just kept in section 2.1,
> and the reference at the end of the first paragraph should then be moved
> there too.

Should I move/collapse the first two paragraphs of Section 1
(Intorduction) to/into Section 2.1?

> => are you 100% sure that this is the result of the publication of these
> techniques? Otherwise I'd rather state this with "perhaps".

Yes. The source was an inside man. ;-) (FWIW, *me*, I thought it was a
result of the infamous windows OOB nuke, but it seems it wasn't the case).

> should be "An example of such a middle-box is the ..."

Will fix this.

> (I think - I'm not a native speaker myself)

On second read (from me, a non-native English speaker), your text sounds
better.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2010 00:53:47 -0300

Hello, Wes,

Thanks so much for your feedback. COmments in-line....

>   "IT accommodates" -> "it accommodates" ?

Fixed.

>   "using urgent the urgent" -> "using the urgent"

Thanks :-)

>   "how some current TCP implementations"

"how some popular TCP implementations"? (i.e., yes, they are not
"all"... but we assessed Linux, BSD's, Cisco, MS...)

>   "never reflected into" -> "never was reflected in"

Fixed.

>   of a sequence number field?  You can't send a terabyte of urgent

Well, you cannot send a terabyte of normal data, either. :-)

I see your point, though... Here we just mentioned what was there in RFC
1122...

I think the spirit of the text in RFC 1122 is that the mechanism (flag +
pointer) should not limit the amount of urgent data that you can send...
(although, as dicussed on the list some time ago, the concept of "urgent
data" is flawed. It's more of a "mark of an interesting point in the
data stream")

>   bothered by the fact that it's broken.

I fully agree. Thanks for catching this one!

Thanks,

---

From: David Borman <[email-masked]>
Date: Fri, 12 Feb 2010 13:23:35 -0600

Fernando and Wes,

> Thanks so much for your feedback. COmments in-line....
...
> data" is flawed. It's more of a "mark of an interesting point in the

Ah, you can do both over a TCP connection: send a terabyte of normal data, and send a terabyte of urgent data.  The urgent date is all the data before the urgent pointer.  So, just as TCP cycles through the sequence space to send a terabyte of normal data, so too it would cycle through to send everything in urgent mode.  Since there is only one urgent pointer that gets updated with each new packet, as long as the urgent pointer points beyond the end of the data in any given packet, the TCP connection will remain in urgent mode until it gets to the end of the terabyte of data. :-)  This is the technique documented in RFC 2675 "IPv6 Jumbograms", section 5.2.

So, there is no limit on how much data you can send while in urgent mode, from either the application or TCP point of view.

			-David Borman

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Fri, 12 Feb 2010 14:20:42 -0600

>From: David Borman [mailto:[email-masked]]
>Sent: Friday, February 12, 2010 2:24 PM
>To: Fernando Gont
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; [email-masked];
>[email-masked]
>So, there is no limit on how much data you can send while in urgent
>mode, from either the application or TCP point of view.
>

Agreed; I think we can disregard my WGLC comment on this; I hadn't
considered the ability to move the pointer as the sequence space is
cycled through.

--
Wes Eddy
MTI Systems

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2010 18:31:38 -0300

David,

>> I think the spirit of the text in RFC 1122 is that the mechanism
>> (flag + pointer) should not limit the amount of urgent data that
>> you can send... (although, as dicussed on the list some time ago,
>> the concept of "urgent data" is flawed. It's more of a "mark of an
>> interesting point in the data stream")
> 
> Ah, you can do both over a TCP connection: send a terabyte of normal
> data, and send a terabyte of urgent data.  The urgent date is all the
> data before the urgent pointer.  So, just as TCP cycles through the
> sequence space to send a terabyte of normal data, so too it would
> cycle through to send everything in urgent mode.  Since there is only
> one urgent pointer that gets updated with each new packet, as long as
> the urgent pointer points beyond the end of the data in any given
> packet, the TCP connection will remain in urgent mode until it gets
> to the end of the terabyte of data. :-)  This is the technique
> documented in RFC 2675 "IPv6 Jumbograms", section 5.2.
> 

I was referring to the fact that there's a limit on the amount of data
you can send as a result of the size of the Sequence Number field, the
TCP window, etc. (i.e., you cannot simply send "any amount of data"
without taking care of the sequence numbers wrapping before you get the
relevant acks, etc.). I thought *this* was what Wesley was referring to,
rather than that of whether it was possible or not to move the UP.

Anyway, issue solved, it seems. :-)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2010 18:34:02 -0300

Hello, Anantha,

Thanks so much for your feedback. Comments inline....

> behaviour and leave it, do not make any recos based on the middlebox

The recommendation is based on everything: both the different possible
semantics of the UP, and the fact that it's not reliable anymore (due to
middle-boxes).

Should we clarify this?

Thanks!

Kind regards,