[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <488E0B73.8070701@hp.com>
Date: Mon, 28 Jul 2008 14:09:55 -0400
From: Vlad Yasevich <vladislav.yasevich@...com>
To: Gerrit Renker <gerrit@....abdn.ac.uk>,
Vlad Yasevich <vladislav.yasevich@...com>,
netdev@...r.kernel.org
Subject: Re: [RFC] sctp/tcp: Question -- ICMPv4 length check (not) redundant?
Gerrit Renker wrote:
> | > In TCP, the 8 bytes happen to be enough for doing sequence number checks. Other
> | > protocols have different header lengths and semantics. Thus doing the checks
> | > at the transport layer makes more sense than in the ICMP handler.
> | >
> | > RFC 1122 is almost 20 years old, from a time before IPcomp, SCTP, or DCCP.
> |
> | So the suggestion really is then to remove the length check icmp_unreach()?
> |
> Yes, but there are a large number of handlers in which the check is absent
> (TCPv4, SCTPv4 and DCCP are exceptions). This would need to be added.
>
> The ipv6/icmp.c code agrees with your suggestion of using 8 bytes as
> lower bound.
>
> I did not want to jump to the conclusion of writing a patch, since there are
> more complex uses of ICMP (such as in a nested tunnel, perhaps with IPsec).
> This needs to be understood.
>
Well, simply from the ICMP protocol perspective the 8 byte lower bound is all
that's required. Each tunnel decapsulation point would have to provide it's own
additional validation on top of the 8 byte, but everyone should be guaranteed at
least 8 bytes for IPv4 ICMP errors.
The IPv6 checks are much different. The MUST requirement is to provide as much
data as possible upto IPv6 min mtu. So, the IPv6 icmp code should probably look
to see if min(payload_len, min_mtu) is provided.
-vlad
--
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
Powered by blists - more mailing lists