North American Network Operators Group
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: icmp rpf
- From: Roland Dobbins
- Date: Sun Sep 24 20:36:34 2006
- Authentication-results: sj-dkim-6.cisco.com; header.From=rdobbins@cisco.com; dkim=pass (sig from cisco.com verified; );
- Dkim-signature: a=rsa-sha1; q=dns; l=1150; t=1159144204; x=1160008204;c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=rdobbins@cisco.com; z=From:Roland=20Dobbins=20<rdobbins@cisco.com>|Subject:Re=3A=20icmp=20rpf;X=v=3Dcisco.com=3B=20h=3DLmT01Oz0KAXVWXghRHk99mwCGD8=3D; b=eBcW9Z8N/UYxLjsTEKcry3MlwdnkGpB3vPdBVuHeX5Ei3iAdQXZ+PXmhZYUC9vBUsB2DfLMLGng1J0imtRlDkmVSF3swYZjxyRisJBaoVi1sXK+qtZX+ln5TqBhjXk6Z;
On Sep 24, 2006, at 4:33 PM, Mark Kent wrote:
Remember, we're not talking about RFC1918 space,
where there is a BCP that says we should filter it at the edge.
We're talking about public IP space, that just doesn't happen to be
announced outside of a particular AS.
If the intent is to prevent folks from reaching out and touching
random network infrastructure devices directly whilst still allowing
traceroute to work, iACLs and/or using IS-IS as one's IGP and null-
routing the infrastructure blocks at one's various edges achieves the
same effect with less potential for breakage:
http://www.nanog.org/mtg-0405/mcdowell.html
Note that a good infrastructure addressing plan is a prerequisite for
both of these methods.
-----------------------------------------------------------------------
Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice
Any information security mechanism, process, or procedure which can
be consistently defeated by the successful application of a single
class of attacks must be considered fatally flawed.
-- The Lucy Van Pelt Principle of Secure Systems Design
|
