RE: draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding

["Smith, Donald" <Donald.Smith@qwest.com>]

if( sent(protocol= 1, type=8) && 
!((received()=(protocol=1,type=0))))
then plz reping.
Donald.Smith@qwest.com giac 

> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On 
> Behalf Of Pekka Savola
> Sent: Wednesday, May 02, 2007 11:44 PM
> To: Tony Rall
> Cc: opsec@ops.ietf.org
> Subject: Re: draft-ietf-opsec-infrastructure-security-01 - 
> InfrastructureHiding
> 
> On Thu, 26 Apr 2007, Tony Rall wrote:
> >   "Hiding the infrastructure of the network provides one layer of
> >   protection to the devices that make up the network core."
> >
> > Please reconsider.  Not only does this whole section 
> provide no better
> > than weak protection, it violates numerous suggestions and 
> mandates in
> > other RFCs.
> ...
> 
> I have stated this before,but I'll have to say I'll agree with a lot 
> of Tony's comments.
> 
> In September 2006 Donald Smith said as follows about this document 
> after the previous round of comments and discussion why this should 
> be BCP instead of Informational:
> 
>    "If its not done as a BCP it will be harder to get some ISPs to
>     adopt. Some of the features in this draft will prevent 
> your network
>     elements from becoming reflectors in a dos attack and therefore
>     general adoption is better for the internet at large."
> 
> Which is (IMHO) exactly the backwards logic.  "Best Current" practice 
> should come first, and when it has been deployed wide enough 
> and there 
> are no obvious bad effects, it shouldn't need the power of 'BCP' to 
> coerce others to deploy networks in a similar manner.

For those network operators that haven't already done some
infrastructure hiding 
it is easier to justify if its a BCP. 

Security features nearly always have to be justified against the risk to
operations or support.

For those that have some infrastructure hiding its easier to justify
continuing and maintaining whatever infrastructure hiding they have
implemented.

When BCP38 was written in 2000 some ingress filtering concepts 
had been adopted by many ISPs but it was
not the Best "Current" Practice nor the Best "Common" Practice.
It has since been fairly widely adopted but I am not sure that today it
has been implemented on more then 50% of the router interfaces. Would
50% adoption qualify it as a "common" practice?

 
> Further in the thread, people have stated that most of these 
> techniques have already been deployed in many large provider 
> networks. 
> Could you please name a couple?  I'd like to run traceroute etc. 
> through them to see if my requirements (as a customer of said transit 
> operators) for usability are being met or not.

With out providing details I believe ALL of the tier1 ISPs 
have implemented some infrastructure hiding.

> 
> I could imagine that it could be possible to hide some infrastructure 
> in a manner that doesn't __necessarily__ hurt the users very badly, 
> but as shown by this thread, the understanding of what infrastructure 
> hiding means (just iBGP loopback addresses vs everything including 
> interface addresses as an example) implies that there's likely still 
> some work to do.

I think that was misunderstood. The GRC attack I was referring to used
multiple interfaces/ips on a router to reflect a spoofed bgp attack. The
details are here http://www.grc.com/dos/drdos.htm 
So it this case changing the dns entry to only return the loop back IP
limited the number of interfaces involved in the attack.
Its not a matter of hiding IPs as much as not advertising all the
interface ips.


Traceroute through various networks and see if they give you the
INTERFACE ip or the loop back ip in the icmp ttl expire message. Many
today return the loopback ip not the interface ip.
This is an additional layer or level of hiding.
Not returning ANY ttl expire message provides an additional level or
layer that you may not be comfortable with but is very common in mpls
clouds.

http://www.juniper.net/techpubs/software/junos/junos53/swconfig53-mpls-a
pps/html/mpls-summary35.html

http://www.cisco.com/en/US/products/ps6350/products_command_reference_ch
apter09186a0080430c47.html#wp1049262


> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.