-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Fernando Gont
Sent: Tuesday, September 07, 2010 11:07 PM
Hi, Keith,
* 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.
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".
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.
* 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.
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.
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.
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".
Agreed; an application is not properly using the specification if it
does anything else.
--
Wes Eddy
MTI Systems
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf