Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Jan 2001 23:45:19 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        Mike Silbersack <silby@silby.com>, Wes Peters <wes@softweyr.com>
Cc:        Don Lewis <Don.Lewis@tsc.tdk.com>, Umesh Krishnaswamy <umesh@juniper.net>, <freebsd-security@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG>
Subject:   Re: Spoofing multicast addresses
Message-ID:  <200101100745.XAA20130@salsa.gv.tsc.tdk.com>
In-Reply-To: <Pine.BSF.4.31.0101100102020.13616-100000@achilles.silby.com>
References:   <Pine.BSF.4.31.0101100102020.13616-100000@achilles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10,  1:13am, Mike Silbersack wrote:
} Subject: Re: Spoofing multicast addresses
} 
} On Wed, 10 Jan 2001, Wes Peters wrote:
} 
} > Don Lewis wrote:
} > > A good reason for putting these checks in their present location is
} > > that it gets them out of the main code path.  Under normal circumstances,
} > > the vast majority of the incoming packets will be for established
} > > connections and it wasteful to do unnecessary checking on these packets.
} >
} > But that is exactly NOT the case when being attacked with a SYN flood
} > or something like that.  Perhaps it would be advantageous to trip a flag
} > if we hit the bandwidth limiting rate and do the checks much earlier only
} > if we're under attack?
} 
} I'm not sure that really matters.  Since (nearly) any packet will undergo
} the pcb lookup, reducing the overhead of multicast packets wouldn't make
} much difference - attackers can just use non-multicast packets.

Yup, if we're DoSed in one of these attacks because of the expense of
doing the PCB lookup before the source address check, then the attacker
just has to craft the packets so that they pass the filters.

I don't think an adaptive algorithm would be the way to go either.  It's
just more code that the CPU would have to run and an attacker might be
able to keep things in the non-optimal state by varying the packet stream.

} Does anyone have an idea on what the performance impact of the multicast
} checks really is?  Just having a single check at the top of the code would
} be nice from a readability standpoint.

The current checks are reasonably cheap, though I would really like to
add a check of the source address against the broadcast addresses of
each interface on the box.  That could be quite a bit more expensive.

} Speaking of stream, I wonder if proper multicast checks are done for icmp
} responses.  Hrm.

I'm pretty sure that UDP is handled OK, but it can't hurt to take another
look.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101100745.XAA20130>