From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Gerrit Renker <gerrit@erg.abdn.ac.uk>,
Vlad Yasevich <vladislav.yasevich@hp.com>,
netdev@vger.kernel.org
Subject: Re: [RFC] sctp/tcp: Question -- ICMPv4 length check (not) redundant?
Date: Mon, 28 Jul 2008 14:09:55 -0400 [thread overview]
Message-ID: <488E0B73.8070701@hp.com> (raw)
In-Reply-To: <20080728174432.GA15892@gerrit.erg.abdn.ac.uk>
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
next prev parent reply other threads:[~2008-07-28 18:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-25 15:20 [RFC] sctp/tcp: Question -- ICMPv4 length check (not) redundant? Gerrit Renker
2008-07-26 2:15 ` Vlad Yasevich
2008-07-26 4:38 ` David Miller
2008-07-26 7:03 ` Gerrit Renker
2008-07-26 7:36 ` David Miller
2008-07-26 8:10 ` Gerrit Renker
2008-07-27 4:48 ` Herbert Xu
2008-07-27 4:51 ` Herbert Xu
2008-07-28 11:25 ` Gerrit Renker
2008-07-28 13:08 ` Herbert Xu
2008-07-28 13:14 ` Vlad Yasevich
2008-07-28 17:08 ` Gerrit Renker
2008-07-28 17:27 ` Vlad Yasevich
2008-07-28 17:44 ` Gerrit Renker
2008-07-28 18:09 ` Vlad Yasevich [this message]
2008-07-30 10:19 ` David Miller
2008-07-30 12:49 ` Vlad Yasevich
2008-07-29 1:56 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=488E0B73.8070701@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=gerrit@erg.abdn.ac.uk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).