Re: TOS values
On 07/16/2014 11:01 PM, 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. I am not proposing to not use TOS values from RFC2697. I am proposing to warn users when TOS values other than those in RFC2697 are used. The user will be able to ignore warning, but at the same time he will know that this TOS value is free for use. Thank you, Alex.
Re: TOS values
On 07/17/2014 02:51 AM, Amos Jeffries wrote: 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, At least for linux this is done by OS. If you try to use 0x23 as TOS value the 0x20 will be used instead. The problem is that this is done silently, without any warn to the user. 3) when TOS named options are found display an upgrade warning and mask out the ECN bits. What do you mean with TOS named options? Are they the AF1x, AF2x referred in RFC2597? PS. need to add RFC3260 to the doc/rfcs/1-index.txt listing after this. Amos
Re: TOS values
On 17/07/2014 10:25 p.m., Tsantilas Christos wrote: On 07/17/2014 02:51 AM, Amos Jeffries wrote: 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, At least for linux this is done by OS. If you try to use 0x23 as TOS value the 0x20 will be used instead. The problem is that this is done silently, without any warn to the user. Yes but not reliably for other OS. So we may as well do it ourselves and get it right in regards to that warning. 3) when TOS named options are found display an upgrade warning and mask out the ECN bits. What do you mean with TOS named options? Are they the AF1x, AF2x referred in RFC2597? No I mean our squid.conf directive names, parameters etc. PS. need to add RFC3260 to the doc/rfcs/1-index.txt listing after this. Amos
Re: TOS values
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. Thank you, Alex.
Re: TOS values
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
