Hi, Bob, Thanks so much for your comments! Please find my responses inline... > 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. 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. > 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. 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, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf