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; [email protected]; 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; [email protected]; z=From:Roland=20Dobbins=20<[email protected]>|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 <[email protected]> // 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