[17245] in bugtraq
Re: TOS Field value in ICMP Error Messages with LINUX Kernels
daemon@ATHENA.MIT.EDU (Robert Bihlmeyer)
Tue Oct 17 13:40:29 2000
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="----------=_971797585-786-3";
micalg="pgp-sha1"; protocol="application/pgp-signature"
Message-Id: <873dhvh3nv.fsf@hoss.orcus.priv.at>
Date: Tue, 17 Oct 2000 17:45:56 +0200
Reply-To: Robert Bihlmeyer <robbe@ORCUS.PRIV.AT>
From: Robert Bihlmeyer <robbe@ORCUS.PRIV.AT>
X-To: Ofir Arkin <ofir@ITCON-LTD.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Ofir Arkin's message of "Sat, 14 Oct 2000 00:37:08 +0200"
This is a multi-part message in MIME format.
It has been signed conforming to RFC2015.
You'll need PGP or GPG to check the signature.
------------=_971797585-786-3
Content-Type: text/plain; charset=us-ascii
Ofir Arkin <ofir@ITCON-LTD.COM> writes:
> RFC 1349 states that ICMP Error messages should be
> sent with TOS field value of 0x00. Nearly all stack implementations
> send back 0x00 as the TOS field value when generating an ICMP error
> message. All but LINUX.
There seems to be a misunderstanding about what bits comprise the "TOS
field". Specifically, you cite rfc1349 which talks about a four bit
"TOS field", which is part of the "type of service octet". Here you
seem to refer to the whole octet:
> Fyodor had outlined in his paper ``Remote OS Identification by TCP/IP
> Fingerprinting" the fact that LINUX is using the value of 0xc0 (an
> unused precedence value) as its TOS field value with ICMP Port
> Unreachable error messages.
rfc1349 does say nothing about precedence, so the tos *octet* may as
well be non-zero.
[...]
> How is the TOS field value used in the LINUX ICMP Error message is
> calculated?
Essentially, what Linux does boils down to (tos denotes the whole
octet, here):
icmp_error->tos = (incoming->tos & 0x1E) | 0xC0
This is readily apparent from the source code (net/ipv4/icmp.h)
The code implements the following SHOULDs of rfc1812:
4.3.2.5 TOS and Precedence
ICMP error messages SHOULD have their TOS bits set to the same value
as the TOS bits in the packet that provoked the sending of the ICMP
error message, unless setting them to that value would cause the ICMP
error message to be immediately discarded because it could not be
routed to its destination. [...] An ICMP reply message SHOULD
have its TOS bits set to the same value as the TOS bits in the ICMP
request that provoked the reply.
ICMP Source Quench error messages, [...] All other ICMP error
messages (Destination Unreachable, Redirect, Time Exceeded, and
Parameter Problem) SHOULD have their precedence value set to 6
(INTERNETWORK CONTROL) or 7 (NETWORK CONTROL). [...]
> I hope this will clarify the subject.
Ditto,
--
Robbe
------------=_971797585-786-3
Content-Type: application/pgp-signature; name="signature.ng"
Content-Disposition: inline; filename="signature.ng"
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE57HRR8g21h7wYWrMRAio4AJ9g2enoyTiyEi4sjdC7xIf40/LnvQCgtBBu
a9Xvzli3yMaZSchoBkjz+Qs=
=/++F
-----END PGP SIGNATURE-----
------------=_971797585-786-3--
