On 17/07/2014 8:01 a.m., Alex Rousskov wrote: > On 07/16/2014 11:39 AM, Tsantilas Christos wrote: >> Hi all, >> Squid currently does not make a check for the TOS values used in squid >> configuration file. Squid will accept 8bit numbers as TOS values, however: >> 1) TOS values with 1st ad 2nd bit set can not be used. These bits used >> by the ECN. For Linux if someone try to set the 0x23 value as TOS value >> (which sets 1st and 1nd bits), the 0x20 will be used instead, without >> any warn for the user. >> >> 2) Some of the TOS values are already reserved for example those which >> are reserved from RFC2597. >> >> The above may confuse squid users. >> >> Maybe it is not bad idea to: >> - Warn users when try to use TOS value which uses the ECN bits >> - Warn users when try to use TOS values which are not reserved. The >> user will know that this value is free for use. >> >> Opinions? > > > This is not my area of expertise, but > > * the first proposed warning sound good to me, and > > * it is not clear to me whether Squid should avoid using ToS values from > RFC 2597. It feels like Squid could, in some cases, _set_ those ToS > values to use RFC 2597 features provided by its network. >
For now Squid still follows RFC 2474 and have the documented comment about ECN problems for somewhat loose RFC 3168 (ECN) support. RFC 3260 section 4 "Definition of the DS Field" explicitly obsoletes the name IPv4 "TOS" and IPv6 "TCLASS". They are both now defined as a 6-bit "DS" value followed by separate ECN bits. IMO, we should update Squid to RFC3260 support - ie mask out the ECN bits and prevent configuring them. Like so: 1) replace all config detailes named "TOS" with "DS" ones that only takes a hex bytecode so that, 2) DS values always be masked with 0xFC and, 3) when TOS named options are found display an upgrade warning and mask out the ECN bits. PS. need to add RFC3260 to the doc/rfcs/1-index.txt listing after this. Amos
