Subject: re: Last Call: <draft-ietf-tcpm-urgent-data-06.txt> (On the implementation of the TCP urgent mechanism) to Proposed Standard

From: Keith Moore <[email-masked]>
Date: Tue, 7 Sep 2010 12:09:26 -0400

Overall, I think this document is fine.   However I think it needs a couple of tweaks.  

The document revises the specifications for sender and receiver handling of TCP urgent data, presumably in order to improve interoperability.  In particular, sections 5 and 6 of this document impose RFC 2119 requirements (SHOULD NOT / MUST) on applications. 

However, 

No requirements are imposed on TCP implementations.  This document claims to "update"  RFCs 793, 1011, and 1122.  TWhat the document should be doing, primarily, is specifying (new) correct behavior.  It's fine to describe how the new behavior varies from that described in previous RFCs, and also how the new behavior varies from that observed in popular TCP implementations.  But these should be non-normative, descriptive sections of the document.  The primary job of a standards-track specification is to specify the behavior.

This document also does not place any constraints on intermediaries, even though the document itself acknowledges that intermediaries interfere with operation of the TCP urgent facility.   

I also note that section 6 imposes a MUST requirement on applications that depends on a non-standard TCP sockets API feature (SO_OOBINLINE)

Recommendations:

1. Label the descriptive sections of this document as non-normative, or otherwise make clear the distinction between the informative/descriptive portions of the document and the prescriptive portions of the document.
2. Add a normative section describing new requirements on TCP implementations, even if the new requirements are very similar to what popular implementations already do.
3. Consider defining (perhaps in a informative appendix) a uniform mechanism for socket-based applications to use to put OOB data inline.
4. Reword section 6 so that it's not specific to the socket API or particular implementations.
5. Add a informative section discussing the pros/cons of IP-level intermediaries altering the URG bit.
6. Add a normative section which states that IP-level intermediaries SHOULD NOT alter the URG bit.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Tue, 07 Sep 2010 20:29:37 -0300

Hi, Keith,

Thanks so much for your feedback! Please find my comments inline...

> The document revises the specifications for sender and receiver handling
> of TCP urgent data, presumably in order to improve interoperability.  

Actually, it resolves a disconnect between the specifications and
virtually all implementations of the urgent mechanism.

> In
> particular, sections 5 and 6 of this document impose RFC 2119
> requirements (SHOULD NOT / MUST) on applications. 
> 
> However, 
> 
>     * No requirements are imposed on TCP implementations.  

The "requirement" on TCP implementations is in Section 4 (page 7).
However, it doesn't use RFC 2119 language as the text that it is
updating (RFC 793, RFC 1122) doesn't use RFC-2119, either.

>       This document
>       claims to "update"  RFCs 793, 1011, and 1122.  TWhat the document
>       should be doing, primarily, is specifying (new) correct behavior.
>        It's fine to describe how the new behavior varies from that
>       described in previous RFCs, and also how the new behavior varies
>       from that observed in popular TCP implementations.  But these
>       should be non-normative, descriptive sections of the document.
>        The primary job of a standards-track specification is to specify
>       the behavior.

Please see above.

>     * This document also does not place any constraints on
>       intermediaries, even though the document itself acknowledges that
>       intermediaries interfere with operation of the TCP urgent facility. 

No TCP specs that I know of accommodate packet scrubbers or firewalls
that simply decide to clear a bit, etc (except for NATs, which are a
completely different issue). When they do (e.g., ECN), it's to
discourage such behavior.

> I also note that section 6 imposes a MUST requirement on applications
> that depends on a non-standard TCP sockets API feature (SO_OOBINLINE)

I guess this could be rephrased as "applications that still decide to
employ it MUST process the "urgent data" in-line, as intended by the ETF
specifications (e.g., by setting the SO_OOBINLINE socket option)"?

> Recommendations:
> 
> 1. Label the descriptive sections of this document as non-normative, or
> otherwise make clear the distinction between the informative/descriptive
> portions of the document and the prescriptive portions of the document.

My take (probably biased, since I'm a co-author of the I-D), is that
Sections 4 through 6 contain all the requirements, and are clear in this
respect. I agree that some text could be moved out of Section 4, though.

What do others think?

> 2. Add a normative section describing new requirements on TCP
> implementations, even if the new requirements are very similar to what
> popular implementations already do.

Isn't this reflected in Section 4, already?

> 3. Consider defining (perhaps in a informative appendix) a uniform
> mechanism for socket-based applications to use to put OOB data inline.

See my counter-proposal for Section 6.

> SHOULD NOT alter the URG bit.

I don't think that tcpm is going to get consensus on "pros" of altering
the URG bit. I guess that the idea is that no firewall or packet
scrubber should modify TCP header fields.

But, again, I'd like to know what others think.

Thanks!

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Sep 2010 20:19:52 -0400

> virtually all implementations of the urgent mechanism.

Yes, but you're also recommending a change from what the existing specifications say to do.  So, in effect, your intent is to revise the TCP specification. 

> updating (RFC 793, RFC 1122) doesn't use RFC-2119, either.

Mumble.  I really don't like the term "updating" when referring to existing RFCs because we don't change the text of those RFCs.  When we say we're "updating" existing RFCs, what we mean is that we're changing the overall recommendations and/or requirements that were specified in those RFCs, to something different.

The point here is that your draft doesn't actually make it very clear that you're revising the TCP specification.    I get the impression that you are assuming that there's no actual need to change the specification, because most existing implementations already behave according to your recommendation.  I'm just asking you to make it clear that you're revising the TCP specifications, and thus imposing requirements on new TCP implementations, in addition to whatever other requirements you impose on applications or whatever.  

(In making that clear, there's no need to use RFC 2119 language if you don't find it appropriate to do so.  But the only purpose of RFC 2119 language is to specify requirements.  So in the current draft, it's really clear that you're imposing requirements on applications, and less clear that you're imposing requirements on TCP stacks.)

> discourage such behavior.

Mumble.  This is obviously a lot bigger problem than just this one document.  But it is a huge problem that IETF has, and (because it's so limited in scope) your document is as good a place as any to start addressing it.

IETF nearly always takes a "somebody else's problem" view with respect to intermediaries.    IETF will impose requirements on endpoints, or make recommendations for endpoints, to work around harmful behavior of intermediaries.   But IETF rarely imposes requirements on intermediaries, or makes recommendations for intermediaries to follow.   

There are lots of problems with this approach, not the least of which is that IETF is in nowhere nearly as good a position to communicate to application developers, as it is to communicate to vendors of intermediaries.     Another reason I believe this approach is unsound, is that it constantly shifts the burden of coping with violations of the Internet Protocol to endpoints - host stacks and applications - to the point that there is very little that endpoints can safely assume about the behavior of the network anymore. 

IETF documents in general need to make it clear that intermediaries that alter IP packets (other than TTL) are violating the IP protocol - i.e. they are not making a best effort to deliver the packet intact - and this is harmful to the Internet.  "Simply deciding to clear a bit" is deliberate data corruption.   

I can understand temporary ad hoc measures that are employed to address known security vulnerabilities, but they need to be understood - and documented - as just that.  There need to be mechanisms for cleaning up these temporary measures, for recommending that they go away when better fixes are in place.   Ironically, by not documenting such temporary measures (along with the problems that they address, and the new problems that they cause), there is a tendency for such measures to become even more entrenched than our well-documented and -reviewed protocol standards.

Obviously you're not going to be able to address this whole problem in a document about TCP urgent data.  But if it's reasonable for your document to impose requirements on applications, it's even more reasonable for your document to impose requirements on intermediaries.

> specifications (e.g., by setting the SO_OOBINLINE socket option)"?

Pretty much.  Assuming, of course, that the host stack and API used by the application actually have the ability to do that.
(maybe you should just make it a SHOULD for that reason)

> the URG bit.

Perhaps not, but my concerns are addressed to the entire IETF, and hopefully IESG will also give them careful consideration.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Sep 2010 00:06:40 -0300

Hi, Keith,

> Mumble.  I really don't like the term "updating" when referring to
> existing RFCs because we don't change the text of those RFCs.  

RFC's that update other RFCs explicitly indicate so in the front page.
So I don't see there's a conflict with the use of the term "Updates".

> The point here is that your draft doesn't actually make it very clear
> that you're revising the TCP specification.    I get the impression
> that you are assuming that there's no actual need to change the
> specification, because most existing implementations already behave
> according to your recommendation.  

I don't follow. The fact that this document updates the specs is even
stated in the very Abstract of the document.

I'll wait for others to comment on this issue....

>> No TCP specs that I know of accommodate packet scrubbers or
>> firewalls that simply decide to clear a bit, etc (except for NATs,
>> which are a completely different issue). When they do (e.g., ECN),
>> it's to discourage such behavior.
> 
> Mumble.  This is obviously a lot bigger problem than just this one
> document.  But it is a huge problem that IETF has, and (because it's
> so limited in scope) your document is as good a place as any to start
> addressing it.
> 
> IETF nearly always takes a "somebody else's problem" view with
> respect to intermediaries.    IETF will impose requirements on
> endpoints, or make recommendations for endpoints, to work around
> harmful behavior of intermediaries.   But IETF rarely imposes
> requirements on intermediaries, or makes recommendations for
> intermediaries to follow.

I guess the rationale is that any intermediary that clears e.g. the URG
bit is violating the specs. So the advice would be "don't violate the
specs".

An I really doubt it that even if you had RFCs that explicitly required
intermediaries to not do these things (e.g. clear bits in the TCP
header), they wouldn't mind.

> There are lots of problems with this approach, not the least of which
> is that IETF is in nowhere nearly as good a position to communicate
> to application developers, as it is to communicate to vendors of
> intermediaries.     Another reason I believe this approach is
> unsound, is that it constantly shifts the burden of coping with
> violations of the Internet Protocol to endpoints - host stacks and
> applications - to the point that there is very little that endpoints
> can safely assume about the behavior of the network anymore.

I agree. But the world is... what it is. Once those boxes are there
(deployed), you cannot assume the mechanism is reliable.

Cisco Pix, a widely deployed device, clears the URG bit. Hence I don't
think you can assume that the urgent mechanism is reliable anymore.

> Obviously you're not going to be able to address this whole problem
> in a document about TCP urgent data.  But if it's reasonable for your
> document to impose requirements on applications, it's even more
> reasonable for your document to impose requirements on
> intermediaries.

I'll let others weigh in...

>>> I also note that section 6 imposes a MUST requirement on
>>> applications that depends on a non-standard TCP sockets API
>>> feature (SO_OOBINLINE)
>> I guess this could be rephrased as "applications that still decide
>> to employ it MUST process the "urgent data" in-line, as intended by
>> the ETF specifications (e.g., by setting the SO_OOBINLINE socket
>> option)"?
> 
> Pretty much.  Assuming, of course, that the host stack and API used
> by the application actually have the ability to do that. (maybe you
> should just make it a SHOULD for that reason)

Applications that are processing "urgent data" as "out of band" data
area already violating the specs -- hence the "MUST".

>>> 5. Add a informative section discussing the pros/cons of IP-level
>>>  intermediaries altering the URG bit. 6. Add a normative section
>>> which states that IP-level intermediaries SHOULD NOT alter the
>>> URG bit.
>> I don't think that tcpm is going to get consensus on "pros" of
>> altering the URG bit.
> 
> Perhaps not, but my concerns are addressed to the entire IETF, and
> hopefully IESG will also give them careful consideration.

Fair enough.

Thanks!

Kind regards,

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Sep 2010 23:37:34 -0400

> So I don't see there's a conflict with the use of the term "Updates".

I wouldn't call it a conflict.   More like a lack of clarity.   To me, the document reads as if you're imposing more of a burden on applications than you are on TCP stacks.

> header), they wouldn't mind.

Well, something's wrong, because we keep writing documents that describe how to work around problems caused by intermediaries, but mostly not trying to fix the actual problems.  

> think you can assume that the urgent mechanism is reliable anymore.

Serious question:  What can an application assume is reliable any more?    

Firewalls second-guess apps, and apps second-guess firewalls.   Maybe the right thing for everybody to do is not try to second-guess what kind of brain damage Cisco or anyone else is going to put into their products, and just expect the Internet to work as it was intended.  That way, when such products break things, it will be very clear that it's those vendors' responsibility to fix it, and not the apps developers.

Granted, there's a lot worse breakage out there than clearing the URG bit, because not many applications use TCP urgent data.

> area already violating the specs -- hence the "MUST".

Ah, I think see what you mean.   But aren't you essentially requiring the application developer to work around a bug which might or might not be present in his network stack, using an API feature that might or might not be present?  What bugs me about that it's sort of out of the control of the application developer.   

Keith

---

From: Bob Braden <[email-masked]>
Date: Wed, 08 Sep 2010 12:04:27 -0700

I find a lot to agree with, in Keith's message.

This whole thing makes me very sad. RFC 793 was written by a small group 
of computer scientists who assumed (naively) that subsequent 
implementors would implement the TCPspec as written, rather than ignore 
the spec and implement according to their own preconceptions (which came 
from the OSI culture) about "urgent data". Unfortunately, the writers of 
RFC 793 did not do a very good job of explaining in detail what they 
meant; they assumed that implementors would understand the obvious. 
(RFC1122 tried hard to correct this omission, but nobody paid attention).

The TCP Urgent mechanism was designed to solve the problem of a 
networked computer system that is spewing out data to the user, filling 
the receiver's buffers so that it never sees the user's Control-C (or 
whatever) to interrupt the flow. The OSI Urgent mechanism, which 
involved out of band data, was conceptually repugnant to the TCP/IP 
designers, because it led to a specific byte limit on buffer space for 
the OOB data.  As the present I-D notes, this finally leads to the 
horror of security-oriented middle boxes that destroy the desired 
semantics. The TCP Urgent mechanism avoided this problem.

The TCP Urgent mechanism is a sad chapter in the implementation of 
(slightly) subtle protocol mechanisms.  It raises the question of how 
far the IETF should go in changing protocol mechanisms to match 
brain-dead implementations and change bugs into features.

Bob Braden

On 9/7/2010 5:19 PM, Keith Moore wrote:
>>> intermediaries altering the URG bit.
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 8 Sep 2010 14:35:28 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Fernando Gont
>Sent: Tuesday, September 07, 2010 11:07 PM
>
>Hi, Keith,
>

I agree with Fernando, though I can see Keith's point that the blanket
designation doesn't make the scope of the update as clear as a set of
from/to changes to the specification would be.  However, in this
particular case, the document content is fairly clear, and I think
Keith's point is more general to the process for updating RFCs rather
than something to hang up this particular document on.  The use of
"Updates" here is consistent with other cases, and is the proper way
to signal in the database that this document should be read by people
implementing 793, though it doesn't obsolete 793.

>header), they wouldn't mind.

This is another problem larger than the document, but I can see that
we might want to simply add a sentence in an appropriate place that
says flipping the urgent bit in middleboxes by default does not seem to
be advisable since some legacy applications may require it in order to
use the OOB facility, and these will break, however it may have some
security merits that make doing so desirable.  I think whether or not a
particular middlebox is configured to do this would have to be evaluated
on a case-by-case basis as to whether what it breaks is more valuable
than what it may save.

Since OOB data is not part of the TCP specification, this is really a
security BCP issue, and not something that really impacts TCP, so I
don't think we would want to make any "requirement" or use 2119 type
of language in discussing it here.

>area already violating the specs -- hence the "MUST".

Agreed; an application is not properly using the specification if it
does anything else.

--
Wes Eddy
MTI Systems

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Sep 2010 17:08:15 -0300

Hi, Bob,

Thanks so much for your comments! Please find my responses inline...

> semantics. The TCP Urgent mechanism avoided this problem.

Middleboxes that break the urgent mechanism do it for any of these two
reasons:

* Preventing NIDS evasion
* Mitigating an old attack against MS stacks

None of these have to do with OOB vs. in-band. The former has to do with
the two different interpretations of the semantics of the Urgent
Pointer. The latter has to do with a bug in MS stacks.

> brain-dead implementations and change bugs into features.

Note that this I-D does not change in-band from/to OOB. It only changes
the semantics of the Urgent pointer -- whether it points to "the last
byte of urgent data" versus "the byte following the last byte of urgent
data". None of these interpretations has any benefits over the other, as
long as everybody agrees on *one* interpretation.

The working code settled for "the byte following the last byte of urgent
data" (as a result of ambiguities in RFC 793), and this never changed.
-- one might even argue that since there's no way of notifying the other
end how you're interpreting the UP, trying to change this would actually
break the current working code.

Thanks!

Kind regards,