RE: draft-ietf-opsec-infrastructure-security-01 - Infrastructure Hiding

["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 Tony Rall
> Sent: Thursday, April 26, 2007 7:16 PM
> To: opsec@ops.ietf.org
> Subject: RE: draft-ietf-opsec-infrastructure-security-01 - 
> Infrastructure Hiding
> 
> On Thursday, 2007-04-26 at 18:44 CST, "Smith, Donald" 
> <Donald.Smith@qwest.com> wrote:
> > From rfc 1918:
> > Some examples, where external connectivity might not be required,
> > are:
> > <snip>
> > "Interfaces of routers on an internal network usually do not
> > need to be directly accessible from outside the enterprise."
> > <snip>
> > "Because private addresses have no global meaning, routing 
> information
> > about private networks shall not be propagated on inter-enterprise
> > links, and packets with private source or destination addresses
> > should not be forwarded across such links. Routers in networks not
> > using private address space, especially those of Internet service
> > providers, are expected to be configured to reject (filter out)
> > routing information about private networks. If such a 
> router receives
> > such information the rejection shall not be treated as a routing
> > protocol error."
> > So the way I read that as long as we don't provide a path 
> back to the 
> rfc1918 
> > space and don't expect external connectivity directly to 
> the 1918 space 
> this is 
> > within the guidance of the rfc.
> 
> Not in my mind.  In no way is an ISP's network private (ok, 
> parts of it 
> might be, but those parts would not be on the path of transit 
> traffic).

The transport gear is private in most ISPs.
As we switch to MPLS as transport why shouldn't it be private?
Why should would you expose the managment or control plane to customer's
beyond the PE? 

> 
> > While that clearly says enterprise I believe it can be applied here.
> > Your statement "assuming you ever source packets with these 
> addresses to 
> 
> > targets outside your "private" network" is of course correct.
> > But when mixed with other infrastructure core hiding techniques it 
> should be 
> > possible to never source traffic outside your "private network".
> 
> But if you never source such packets, you're breaking all 
> sorts of RFCs - 
> mainly related to icmp.
>  
> > Making portions of your network, such as core routers, 
> "untargetable" 
> > specifically making the control plane addresses not 
> routable externally 
> makes 
> > it EXTREMELY difficult to attack those portions.
> 
> Certainly it's still possible to target them.  Perhaps you 
> can't overload 
> them by direct addressing, but all that's necessary is to get 
> traffic to 
> go through them.

"Fill the pipe" attacks are very difficult to prevent but also very
noticeable. 
In many cases you can ratelimit those types of attacks.
This isn't meant to prevent that. It is meant to prevent direct attacks
against the router's managment or control plane.
Successful attacks against the mgmt or control plane of the routers can
involve several orders of magnitude less packets that a bandwidth
resource attack. They are harder to detect at the edges.


> 
> Regardless, I never buy the argument that adding any subtle amount of 
> protection for my network justifies breaking all kinds of 
> other things. 

This is not subtle. 
Done correctly it prevents nearly EVERY resource exaustion attack
against the infrastructor 
except the bandwidth resource exaustion attacks.


>If it's really thought otherwise, I don't know what stops those 
> who do from 
> using the ultimate firewall - wire cutters.

The fact they we wish to make money selling bandwidth:)

> 
> > you have probably already ratelimited 
> > icmp unreachables. 
> 
> Nope, never done this.  But that is not nearly as bad as 
> cutting them out 
> completely.  I can justify some collateral damage in response 
> to an actual 
> attack, but I can't condone blindly blocking (whether by filtering or 
> using invalid addresses) of legitimate traffic.

It helps prevent your routers from being fast DDOS reflectors.
When your routers are fast reflectors they will be used to reflect DDOS
traffic.
The fact that routers make very fast dos reflectors was discovered years
ago.
The first one I was aware of was SMURF which really used the router to
fan out the icmp traffic destined to the broadcast address. I assume you
disabled directed broadcasts.

From rfc 1812
" A router MUST classify as network-prefix-directed broadcasts all
   valid, directed broadcasts destined for a remote network or an
   attached nonsubnetted network.  Note that in view of CIDR, such
   appear to be host addresses within the network prefix; we preclude
   inspection of the host part of such network prefixes.  Given a route
   and no overriding policy, then, a router MUST forward network-
   prefix-directed broadcasts.  Network-Prefix-Directed broadcasts MAY
   be sent.
   A router MAY have an option to disable receiving network-prefix-
   directed broadcasts on an interface and MUST have an option to
   disable forwarding network-prefix-directed broadcasts.  These options
   MUST default to permit receiving and forwarding network-prefix-
   directed broadcasts."
This was later changed by http://rfc.net/rfc2644.html but most of us
turned off directed broadcasts before rfc2644 was published.

The next one was the one I refered to against GRC where the attacker
spoofed GRC ip addresses and sent them towards routers on BGP ports.
That attack was spoofed syn's no amplification. It would have (and does)
work just as well today if you send back a icmp port/host unreachable to
the spoofed src address.
The attack still gets to hide the attacking systems behind real fast
routers:(

  
> 
> > To stop people from doing negitive scanning of our 
> > infrastructure I require SILENT drops (not tcp reset no icmp 
> unreachables) from 
> > network vendors.
> 
> This is really pushing the "security by obscurity" modus.  I 
> see no value 
> in it, and plenty of problems.

It is sometimes refered to as stealth mode.
Why double the effects of a DDOS attack?
Why would you want your router to tell the world what ports are closed?
So they can figure out what ports are open?

>  
> > No rfc that I know of requires I publish/advertise all the IPs of a 
> router.
> 
> Certainly not, but those addresses that communicate outside 
> your network 
> should be legitimate and reachable.

Agreed those that communicate with our customers (edges or PEs) are
legitimate and reachable by the directly connected customers. No IP
address other then our managment addresses have authorization or a
legitimate reason to access the managment plane of the routers so that
is restricted. Major portions of the control plane are also resticted to
address space that requires access to that control plane service. 

Those that are part of the MPLS transport have no need to communicate
with any ip other then a few qwest ips for management and control plane.

> 
> > PTMUD has been blocked in many networks as a result of this issue.
> 
> Yes, and I consider that a significant negative against what has been 
> proposed (and any other techniques that cause the same 
> problem).  I do not 
> consider this a "best" practice or even a slightly good practice.
> 
> Don't get me wrong - I feel the other sections (other than 
> 6.x) of the 
> draft might be beneficial, but I wanted to strongly object to 6.

I appreciate that and have been enjoying this discussion.
Thanks!

 
> --
> Tony Rall
 


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.