RE: Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.

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

As ONE measure to help mitigate attacks against the router's managment plan filters to prevent
access except from a set of managment stations it sounds like we agree on the filtering requirment. 

I think we also agree that getting CORRECT fiters on your the edges of your network further mitigates attacks on the managment plane. 

I dont think the physical security of the lines is in the scope of this document.
Encrytion may not help if the physical plane has been compromised.

-----Original Message-----
From: Perry E. Metzger
To: Smith, Donald
Cc: Ross Callon ; gmj@pobox.com; opsec@ops.ietf.org; bwijnen@lucent.com
Sent: 2/22/2004 2:52 PM
Subject: Re: Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.


I've reformatted your quoting:

"Smith, Donald" <Donald.Smith@qwest.com> writes:
>>> Similarly, the security threat implicit in having hackers break into

>>> network management will depend upon other details of how the 
>>> network is set up. For example, there are some networks where 
>>> there are a moderate number of very large routers, and where *all*
>>> incoming interfaces (from customers) have packet filters set which
>>> prevent the customers from sending packets to the routers (ie, 
>>> they can't set the IP destination address to be the address of an 
>>> internal router within the network). In this case hackers can't
break 
>>> into a router
>
>> Wanna bet?
>
> It helps to limits your exposure. Overflows that only require
> the router to PROCESS the packet such as the recent H323
> vulnerabilites are sill a possible vector of attack.

Actually, in most instances, I can still directly attack the
router. People usually screw up the filters, or don't do ingress
filtering in some places on the net, thus permitting me to forge
packets from "legitimate" management stations, etc. It is rare to see
a commercial deployment where the filters were all done correctly,
because few people use fully automated systems to manage the entire
set of filters, which is what you need to do past even the most modest
sizes. (When I say fully automated, I include figuring out what the
filters should be everywhere in the network based on high level
descriptions of policy, not just pushing them out.)

However, even ignoring that, the fact remains that physical security
of your lines is usually extremely crappy, and it is often trivial to
get access to them somewhere along their very long unguarded path and
play vicious games that would not be possible if the underlying
management traffic was encrypted -- and yes, it can be very much worth
doing that depending on the value of the target, especially given how
cheap and easy it is.

Potemkin security isn't something to be encouraged. Pretending that
packet filtering can provide security for management is just that --
usually a pretense. At best it should be thought of as a way of
raising the bar -- and only as that. I have no objections to raising
the bar, by the way -- but only so long as you don't depend on such
measures.

>>> because they can't send a packet to the router at all
>>> (they can send packets via the router, but only if the destination
is
>>> not the router). In this case the urgency of encrypting network 
>>> management might be lower than in other cases. 
>
>> Most big iron these days lets me ssh in. That is nice and
>> secure. Most of them will do other kinds of secure management as
>> well. Given that, why should we encourage Potemkin security?
>
> Blocking access to services on the router prevents other attacks
> such as syn floods against a service on the router.

Perhaps. If it is thought of just as one element of a deeply layered
defense, I wouldn't have much trouble with it -- anything cheap that
makes the attacker's life a wee bit harder is fine by me. However,
generally, I would expect that at least large chunks of the network
don't have flawless ingress filtering so it won't matter much.


-- 
Perry E. Metzger		perry@piermont.com