On Fri, 20 Dec 2002 11:31:39 MST, "Wayne E. Bouchard" said:

On Fri, Dec 20, 2002 at 11:12:43AM -0500, David Lesher wrote:

...

[This just jumped into the operational arena. Are you prepared with the router port for John Poindexter's vacuum? What changes will you need to make? What will they cost? Who will pay?]

Heard about this on the news this morning and you know, I am so not worried about it.

IMO, it's so completely unfeasable at every level as to be actually funny.

All the same, I suggest you forward the rest of your quite well-reasoned comments to your congresscritter and/or the White House. Remember that the idea was probably propsed by people who have little or no clue of what the actual impact would be - and the final decision will likely be made by somebody with even less technical edge. The truly scary part is that it could actually be approved....

Cough! On Fri, 20 Dec 2002, batz wrote:

On Fri, 20 Dec 2002, David Lesher wrote:

:[This just jumped into the operational arena. Are you prepared :with the router port for John Poindexter's vacuum? What changes :will you need to make? What will they cost? Who will pay?]

There is a really easy way to accomplish this, and it has been apparently partially implemented within UUNet as an overlaid network of GRE tunnels for a few years, at least based on a Nanog presentaton from October 1999.

This is incorrect, this isn't implemented, its not implementable, current routing gear doesn't gre tunnel a) fast enough, b) at all.... HOWEVER, juniper will allow you to copy packets on an interface in 5.5 or perhaps a bit later code, this is one way to implement this... however having a new oc-X for each oc-X you wanna monitor. I wonder if there is a limit to the amount of fiber the OCS/NCS/NPIC wants to monitor?

This can be accomplished quite cost effectively, provided the government doesn't want to archive *everything*.

even if the gre tunnel (Center Track (c) Robert Stone, et al.) idea worked right and scaled correctly things would still be 'expensive'... to monitor/maintain/manage.

I keep mentioning this, and for some reason few people seem to recognize how profoundly simple it would be for the government to legislate themselves into exchange points and have the authority to announce certain prefixes to the IX, tunnel the traffic of the affected route into their own network, and monitor it without ever showing up in a traceroute.

Sure, or they could ask carriers to tap lines for them silently... in fact they can do that today with a court order. -Chris

On Fri, 20 Dec 2002, Christopher L. Morrow wrote: :Cough! Heh. Bless you. ;) :This is incorrect, this isn't implemented, its not implementable, current :routing gear doesn't gre tunnel a) fast enough, b) at all.... HOWEVER, :juniper will allow you to copy packets on an interface in 5.5 or perhaps a :bit later code, this is one way to implement this... however having a new :oc-X for each oc-X you wanna monitor. I wonder if there is a limit to the :amount of fiber the OCS/NCS/NPIC wants to monitor? I was told it was implemented when I called security a couple of years ago, and then my other questions were met with "no comment". "No comment" is the appropriate response to a stranger calling and asking for security information, and doesn't imply any other answer, and I am willing to accept that it is no longer implemented, but somebody told me it was. I am willing to accept that the person I spoke to misinterpreted my question. That said, I don't think it's economical to want to tap an oc-X, but being able to grab single sessions doesn't necessarily have to scale if they aren't grabbing lots of them, and can access them relatively close to their source. It's the same issues as running IDS's. Lets say you have a an IDS load balancer sitting on a GigE span port with a few sensors watching everything go by. If an alert is triggered, a script is executed which goes out to the router closest to the origin of the session and initiates the overlaid tunnel. :even if the gre tunnel (Center Track (c) Robert Stone, et al.) idea worked :right and scaled correctly things would still be 'expensive'... to :monitor/maintain/manage. Well, one would assume that these features would be necessary for the maintainance of a robust security policy and architecture implementation. The value is the same value that you get from regular IDS's, just with a new customer. :Sure, or they could ask carriers to tap lines for them silently... in fact :they can do that today with a court order. Indeed, and building features for automating the initialization of those taps into the network is not extrordinarily difficult. (I retract my "profoundly simple" comment.) The cost of doing so is another loss avoidance cost that would be integrated into the overhead cost that we currently call security anyway. Are you suggesting that there might be money to be made by someone who offered to integrate this sort of surviellence architecture into a network? -- batz

On Sat, 21 Dec 2002, Christopher L. Morrow wrote: Regarding CenterTrack: : :its not that they misinterpretted, its that its NOT EVER been implemented. I am content to believe you. However, that CenterTrack has never been implemented does not mean that a system for collecting IP session data has never been implemented. This further suggests that automated law enforcement access is also not impossible, which was my original point. :Ok, so lets say you wanted to IDS the 'internet' or 'any large ISP' :(Verio/UU/AOL/ATT/Sprint... make your list) there is little gig-e to :monitor, alot of oc-12/48/192. There isn't an IDS that can truely monitor :a oc-12 yet, never mind multipath oc-12's (dual/tri/quad paths in the same :box) Anyone with that size link could be deemed "carrier class" and be compelled to install monitoring equipment within their network. Though admittedly I don't think it's useful to speculate on the legislative "could"'s. :Hmm, actually it is pretty darned simple, no-export+no-advertise do this :for you quickly, then trigger when you want to watch paul vixie's hotmail :activities... simple enough really. This gets back to distributing :'sensors' to each pop, on each carrier and having dedicated ports on :routers to support this... This seems like a very large cost to bear, more :than 'cost of doing business'. Those costs of doing business can be regulated, which it looks like they just might be. Same as the whole PEN register thing for telcoms. Also, if you have an existing IDS infrastructure, it is not difficult to add this kind of LEO-access to it. It is as simple as giving them a view of your security management console. :all of these vendors provide products capable of this kind of :'surveillance', whether or not thats the touted talking point or not, each :can provide this 'surveillance'. At least one of the vendors you listed does in fact tout the products surveillance features, at least during their sales pitch. The funny thing in my biz (IT security) is that I think it's the only one where people sell things by not saying what they can be used for. They nod meaningfully while saying that they can't really say just what it is that people use it for. Customers think "Wow, I've never even heard of this, and the sales guy won't even tell me what it does, it *must* be valuable beyond imagination!". To hear them tell it, it's as if they are selling a turnkey blackbox ROI Generator, which uses top secret military technology that "leverages dynamic security policies". Before there was carnivore, law enforcement got access to network data, and I have a few anecdotal accounts of how this was done. There is no reason why LEA's couldn't ask ISP's to permanently integrate this access into their networks. -- batz

On Sun, 22 Dec 2002, Sean Donelan wrote:

On Fri, 20 Dec 2002, batz wrote:

...

Lets say you have a an IDS load balancer sitting on a GigE span port with a few sensors watching everything go by. If an alert is triggered, a script is executed which goes out to the router closest to the origin of the session and initiates the overlaid tunnel.

On any major backbone the IDS function becomes

GlobalIDSFunction() { While (1) { printf("Attack Detected!"); } }

An overlaid tunnel initiates each time THIS MANY attack is detected? Wow... I'd imagine...: System restarted by error - a Software forced crash, PC 0x602E3780 :-) -hc

Do you really want an automatic wiretap installed on your line every time an attack is detected? Have you recently connected a system to the Internet that hasn't been attacked?

On Mon, 23 Dec 2002 13:26:16 EST, batz said:

You will miss script kids that bounce all over their compromised machines around the world, but even if you collected all the information about those attacks, there is little value in tracking them down anyway. The interjurisdictional administrative hell makes it more cost effective to just lock down your network than to re-enact The Cuckoos Egg.

Unfortunately, this is (or should be) part of the threat model. What makes you think that J Random Cyberterrorist is any stupider than the guys Stoll was chasing? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech

Also, this threat can be mitigated more cost effectively through system and network hardening than by expanding the monitoring infrastructure to be able to handle such a difficult to codify threat (in any general sense).

I agree totally. However, it's unglamorous, and not as sexy of an announcement - or as cool looking - as saying the Federal UberSOC is on its way. But it's Uncle Sam doing what he does best - reinventing a less-capable wheel at a higher cost.

Cyberattacks (again IMHO) are still in the realm of being opportunistic, as we have seen that given as little as $5-10,000, the resources necessary to reliably cause widespread damage are better spent on a plane ticket than a hacker.

Definitely agree - 0911 was done for under $150K according to some reports, and if you think about it, the terrorists got a heck of a return for their investment, far more than they could hope to achive in a 'cyberwar' attack. The motive of terrorism is to sow fear. There's much more visceral fear seeing the WTC collapse than watching a graphic on television trying to show how a buffer overflow worked on SCADA system. :)

The cyberterrorist threat is based upon the exposure of network systems and the motivation of the attacker. What is not taken into account in this threat description is the other, more reliable and severe options available to someone with the same resources and motives.

No, the cyberterrorist threat is a sensational concept based on FUD, ignorance, and hype....and believed to be true by the same politicos who think "Swordfish" was a realistic movie about INFOSEC. If we're going to say there are cyberterrorists, then we've got to start saying 0911 was the result of aeroterrorists. The manner in which the attack is carried out doesn't matter -- terrorism is terrorism is terrorism. As George Carlin might say, "there are no cyberterrorists." In this case, instead of accepting responsibility for our actions (or inactions) regarding INFOSEC, we point fingers at anyone else - such as phantom cyberterrorists - to avoid responsibility and accountability. It's nothing more than the latest version of Passing The Buck. We see INFOSEC incidents occur regularly because WE MAKE IT EASY FOR THEM TO OCCUR and thus BRING IT ON OURSELVES....either through poor management, bad system/network administration and design, or shoddy software. (BTW, I meant "we" in terms of the IT Society, not "we" meaning the experts here on NANOG!)

threat model, we can be relatively successful. However, some threats are best dealt with by limiting our assets exposure to them instead of building in safeguards whose reliability is inversely proportional to their complexity. :)

Which goes along with what I tell students at NDU each month -- if something's deemed a 'critical infrastructure system' (SCADA, banking, etc.) it should not be on any publicly-accessible network, and the higher costs associated with higher levels of security (eg, using dedicated, privately-owned pipes vice a VPN over the Internet) must be an acceptable and necessary part of the security solution. If something's deemed 'critical' to a large segment of the population, then security must NEVER outweigh conveinience. Period. Non-negotiable.

inherant administrative overhead of tracking them. The only defense against them is to keep your patch levels current, your firewalls strict, and watch until they get lazy and make a mistake.

Amen! This goes back to making sure system admins are competent, trained, and have the time to ensure these security functions are carried out. Unfortunately, I've found they spend most of their time hunting repeated problems in certain mainstream OS environments -- which means that PROACTIVE security routinely takes a back-burner to REACTING to the latest overflow, trojan, worm, or virus....or to a 'new' problem injected by the vendor-endorsed patches that allegedly fixed existing ones. Of course, while no OS is perfect, if our systems weren't built on such a flaky foundation, we'd have more time to work on securing them instead of just keeping them operational and somewhat less-annoying while simultaneously providing a self-inflicted target of opportunity for some n'er-do-well.

It does not matter who is watching if you are invisible. A sensor can only see what it is looking for. A hacker cannot be seen merely by looking.

Hence the need for intelligent network monitoring and pattern profiling, something I've been mulling over for a while now. /rant. :) Rick Infowarrior.org

On Tue, 24 Dec 2002 10:26:09 EST, Richard Forno said:

In my last post when I said this:

...

If something's deemed 'critical' to a large segment of the population, then security must NEVER outweigh conveinience. Period. Non-negotiable. I meant to say that security must ALWAYS outweigh convienience.

My goof....guess I had too much NOG and not enough NAN at the party last night. :)

A case could be made that you had it right the first time, in that a "large segment" of the population cares less about security than they do about dancing hamsters, and that they'd designate the latter as "critical". Thus the sorry state of certain end-user software on 90% of the desktops. Happy Holidays! ;)

On Tue, 24 Dec 2002, Richard Forno wrote:

In my last post when I said this:

...

If something's deemed 'critical' to a large segment of the population, then security must NEVER outweigh conveinience. Period. Non-negotiable.

I meant to say that security must ALWAYS outweigh convienience.

Sigh, people are playing games with words to force false choices. Of course its negotiable because the act of defining something "critical" is a negotiation.

Thus spake <Valdis.Kletnieks@vt.edu>

On Mon, 23 Dec 2002 13:26:16 EST, batz said:

...

The interjurisdictional administrative hell makes it more cost effective to just lock down your network than to re-enact The Cuckoos Egg.

Unfortunately, this is (or should be) part of the threat model. What makes you think that J Random Cyberterrorist is any stupider than the guys Stoll was chasing?

Whether they're smart or dumb is moot when there's 100+ human attacks (not [D]DoS) against your network every day, plus tens of thousands of worms. It's simply not possible to respond in any meaningful way. Even if you could track down each attacker, they are often in countries that don't consider hacking a crime and won't grant extradition. This is why many organizations (eg .MIL) try to filter non-US addresses. S

Also, if you want to monitor massive amounts of data (something people say can't be done easily) you just demux it using a device like those at www.toplayer.com, or http://www.radware.com/content/products/fire.asp . Both solutions are adequate for breaking up massive amounts of data.

I could write snort signatures that will trigger a session to be re-routed based on packet content. It's fugly, but if I can do it in my basement, a multi-billion dollar agency acting on behalf of the only global superpower can probably think up something a little more elegant. :)

The problem with this argument is you have to know exactly what you are looking for *before* the event. Foresight is almost never 20/20. How many times have we all encountered a variation of the following?: 1. Get a call from an FBI agent (or insert any other gov't agency) 2. Play phone tag for a week. 3. Finally get each other on the phone. 4. Special Agent So&so requests a log file or packet trace from X months ago. The value of X usually = 6 months or more. Only when it was a murder case have I seen a request come in under 3 months. 5. Laugh and say... "OK, we'll try." 6. Dig and Dig... if lucky, find a 200+ megabyte log file. 7. Call agent back, offer to FTP/burn to a CD and send. 8. Agent replies: "Can you look at it for us, we are real busy." 9. Reply: "Uh... so are we, we'll let you know if we have a minute..." 10. Lather, rinse, repeat. I have personally had this exact scenario play out four times so far in 2002. That said, the way we have chosen to empower our government to act is as a tool of justice (after the act), not prevention. I have no problem with that setup, and really don't like the 'shoot first, ask later" direction drift of the current administration. Too many packets, not enough time, too many cooks in the government's kitchen all looking over their shoulders at all the *other* cooks and closely guarding their little corner of counter space and utensils. Nothing to see, carry on... --chuck <insert ironic sig>.... -- ____________________________________________________________ Were there mistakes? Yes. Only those who don't act don't make mistakes. But to organize well --- *that* is a difficult task. -- Lenin, April 24, 1917