White House to Propose System for Wide Monitoring of Internet (fwd)

Christopher L. Morrow chris at UU.NET
Sat Dec 21 04:33:15 UTC 2002

On Fri, 20 Dec 2002, batz wrote:

> On Fri, 20 Dec 2002, Christopher L. Morrow wrote:
> :Cough!
> Heh. Bless you. ;)

its this damned changing weather :)

> :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.

its not that they misinterpretted, its that its NOT EVER been implemented.

> 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.

Except rarely (for larger pipes) are things symetrically routed. So, lets
take my favorite example: ebay. Your session to ebay is only really
reliably symetric at the router upstream from your workstation... all
other paths become highly asymetric quickly, most likely.

> 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.

For this I'd think 'riverhead box' and again, only at the datacenter where
the LB was, or at your facility infront of your workstation.

> :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.

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

The CenterTrack concept was never supposed to IDS traffic, it incurs a
large latency for the traffic and actually isn't implementable on 90% or
more of the edge routing gear of these providers.

> :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.

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'.

> 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?

I'm not, but lots of people are already selling this very thing...


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'.

More information about the NANOG mailing list