Date: Fri, 23 Feb 2001 04:34:05 +0100 From: Jesper Skriver <jesper@skriver.dk> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: net@freebsd.org Subject: Re: ICMP unreachables, take II. Message-ID: <20010223043405.B6694@skriver.dk> In-Reply-To: <20010222212044.H5714@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Feb 22, 2001 at 09:20:44PM -0600 References: <20010222185412.E5714@prism.flugsvamp.com> <20010223034952.A6694@skriver.dk> <20010222212044.H5714@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 22, 2001 at 09:20:44PM -0600, Jonathan Lemon wrote:
> On Fri, Feb 23, 2001 at 03:49:52AM +0100, Jesper Skriver wrote:
> >
> > I still think we should react to the following as a minimum
> > - type 3 code 0 net unreachable
> > - type 3 code 1 host unreachable
>
> RFC 1122, Section 4.2.3.9 says:
>
> o Destination Unreachable -- codes 0, 1, 5
> Since these Unreachable messages indicate soft error
> conditions, TCP MUST NOT abort the connection, and it
> SHOULD make the information available to the
> application.
>
> I think that these should be transients.
As discussed on IRC I suggest adding the ability (under control of a
sysctl, disabled by default) to treat 0/1 (perhaps even 5) like 2,3,9 &
10.
This would be of benifit to server whose application will retry itself,
a example of such a server would be a mailserver ...
Routers sending host/net unreachables would enable the mailserver to
immediate delay delivery of that email instead of waiting for the long
TCP timeout, thus freeing delivery processes.
And for transients it doesn't matter as the mailserver will just retry
shortly after.
> > Perhaps you could keep some of the comment ...
>
> Hmm, yeah, I was probably a little too overzealous with the axe there
>
>
> > > if (cmd == PRC_QUENCH)
> > > notify = tcp_quench;
> > > - else if ((icmp_unreach_like_rst == 1) && ((cmd == PRC_UNREACH_HOST) ||
> > > - (cmd == PRC_UNREACH_ADMIN_PROHIB)) && (ip) &&
> > > - ((IP_VHL_HL(ip->ip_vhl) << 2) == sizeof(struct ip))) {
> >
> > Sure we'll not try to read off the end of the recieved packet, when we
> > remove the check for the header length.
> >
> > I put it there as a extra check against "attackers" sending us malformed
> > ICMP messages with only part of the attached IP header, or even without
> > it.
>
> Yup, but if you exmaine icmp_input, which calls this code, it has
> already verified that there are a full 8 bytes of the TCP packet
> in existence; if this is not the case, icmp_input will drop the packet.
Ok - thanks, still havn't got a full overview of the networking code,
but getting closer ...
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work: Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010223043405.B6694>