netdev - Re: [RFC] sctp/tcp: Question -- ICMPv4 length check (not) redundant?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080728112527.GB7589@gerrit.erg.abdn.ac.uk>
Date:	Mon, 28 Jul 2008 12:25:27 +0100
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, vladislav.yasevich@...com,
	netdev@...r.kernel.org
Subject: Re: [RFC] sctp/tcp: Question -- ICMPv4 length check (not)
	redundant?

Thank you for the input. To sum up,
 * removing the per-protocol "ICMP payload too short" test and error counter
   increment as initially suggested does not seem right;
 * there are protocols such as IPComp which have a header length less than
   8 bytes(and for these the test in the ICMP handler may be too much);
 * there are protocols such as DCCP which need more than 8 bytes (at least 12)
   to interpret the ICMP message in a meaningful way;
 * the requirement of having at least 8 bytes of transport-layer data available
   is stringent (afaik) only for ICMPv4, but not ICMPv6;
 * only TCP/SCTP seem to have a proper per-protocol "payload too short" test;
 * for DCCP, the work is actually doubled since 
   - first the ICMP handler tests for minimally 8 bytes, 
   - then the DCCP error handler tests for required minimum of 12 bytes.

Thus the patch at the begginning of this thread should be disregarded.
It might be worth to consider per-protocol handlers.

Gerrit
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html