LCP Echo in Cisco Environment

[Ronald W. Jean Jr.]

Good day all, 

 

I am curious if anyone is familiar with the role of LCP echo
requests in Mobile IP environments to maintain session activity. Specifically,
I am wondering does anyone have familiarity with the Cisco CSG (billing) and its
ability if any to interpret that traffic.

 

Thanks 

 

Ron Jean

Miller Technologies Group LLC

Re: Triple Play [was: CAUTION: Potentially Dumb Question...]

[Christian Kuhtz]

On Feb 6, 2006, at 11:17 PM, Sean Donelan wrote:

On Mon, 6 Feb 2006, Bora Akyol wrote:

He hasn't taken broadcast TV delivery into account in the
Triple Play scenario.  You gotta plumb them packets good for that...


I don't watch anything live anymore, all via Tivo. If Tivo could
do bittorrent and download the content, then would I need
broadcast?


Broadcast remains an extremely efficient method for bulk  
distribution of

content to those TiVo's even if you watch everything on a delay.  Some
grad student can probably write a thesis what the cross-over point  
is for
different use conditions.  FedEx vs. P2P vs. Unicast vs. Broadcast  
vs. ???


If you're near real time, you have lots of options actually. And I  
would contend that p2p can be efficient for broadcast distribution  
actually.  There already are several startups doing exactly that for  
large scalability.



I think BitTorrent is successfull because that's where the content
people want is.  I don't think users actually care much about the
protocols.  We've seen how fickle users can be, quickly migrating
to different protocols/applications depending on where the content
they want is.  Are there any Gopher servers left?


No actual end user (other than the geek crowd) will ever care that  
it's BitTorrent or whatever.  Agreed.  But that doesn't mean a  
bastardization of the idea won't run underneath.


Best regards,
Christian

RE: Triple Play [was: CAUTION: Potentially Dumb Question...]

[Sean Donelan]

On Mon, 6 Feb 2006, Bora Akyol wrote:
> > He hasn't taken broadcast TV delivery into account in the
> > Triple Play scenario.  You gotta plumb them packets good for that...
>
> I don't watch anything live anymore, all via Tivo. If Tivo could
> do bittorrent and download the content, then would I need
> broadcast?

Broadcast remains an extremely efficient method for bulk distribution of
content to those TiVo's even if you watch everything on a delay.  Some
grad student can probably write a thesis what the cross-over point is for
different use conditions.  FedEx vs. P2P vs. Unicast vs. Broadcast vs. ???

I think BitTorrent is successfull because that's where the content
people want is.  I don't think users actually care much about the
protocols.  We've seen how fickle users can be, quickly migrating
to different protocols/applications depending on where the content
they want is.  Are there any Gopher servers left?

> TV model is going to change significantly in the next 3-5 years.

I'll agree, but I have no idea how.  Most of the predictions will
be wrong, they always are.

I've seen a lot of cool future stuff from various companies and individual
inventors.  But it will be the consumer that decides the winners.

Re: Triple Play [was: CAUTION: Potentially Dumb Question...]

[Christian Kuhtz]

On Feb 6, 2006, at 8:33 PM, Bora Akyol wrote:






He hasn't taken broadcast TV delivery into account in the
Triple Play scenario.  You gotta plumb them packets good for that...


I don't watch anything live anymore, all via Tivo. If Tivo could
do bittorrent and download the content, then would I need
broadcast?


Because of the nature of broadcast sports events as well as live news  
channels.



TV model is going to change significantly in the next 3-5 years.


Sure. But you're deluding yourself if you think it's going to go all  
VoD.

RE: Triple Play [was: CAUTION: Potentially Dumb Question...]

[Bora Akyol]

> 
> He hasn't taken broadcast TV delivery into account in the 
> Triple Play scenario.  You gotta plumb them packets good for that...

I don't watch anything live anymore, all via Tivo. If Tivo could
do bittorrent and download the content, then would I need
broadcast?

TV model is going to change significantly in the next 3-5 years.

Bora

Triple Play [was: CAUTION: Potentially Dumb Question...]

[Scott Weeks]

:* Date: Mon Feb 06 15:34:00 2006
:
: > I'm interested in responses to this ...  MPLS is
: > still a four letter word ..  :)
:
: 


"By any accounts peer-to-peer file sharing has taken over
the Internet...one reasonable conclusion is that real time
content delivery, or Triple Play time, is over –
BitTorrent has won over the user!"

"today’s carrier is being pushed into the role of packet
plumber...It would appear that want customers want today is
for packet carriers to stick to the basics"


He hasn't taken broadcast TV delivery into account in the
Triple Play scenario.  You gotta plumb them packets good for
that...

scott

Re: Interesting netflow entry

[Wil Schultz]

Bill Nash wrote:

You may find it far simpler to just ask the person who owns the 
sources that those packets are. While this may not be politically 
feasible (insert network and privacy policies here), given the amount 
of VPN traffic that's encapsulated in UDP, that may be anything. The 
problem with netflow is that it does reveal many interesting, hypnotic 
patterns inside your network. Having spent my share of time on the 
receiving end of that lunacy, I can only offer this advice: Drinking 
from the firehose is only funny for a little while.


Depending on your deployment method (transit flow monitoring vs 
locally sourced, data center vs office campus, college campus vs four 
hippies with tin cans), identifying flows may be far easier if you 
have a network inventory to refer to. Even something as simple as 
parsing XML output from NMAP into a db will give you better insight 
into what your flows are.


Incidentally (because I ask everyone this), what's your flow volume 
(flows per second)?


- billn

Cannot get ahold of the machine until tomorrow. I did a 'wc' on 4 
devices for 5 minutes and it comes out to just under 3600, about 11-12 
per second...


-Wil

Re: Interesting netflow entry

[Bill Nash]

On Mon, 6 Feb 2006, Wil Schultz wrote:



Here is another pattern, sourced off of one the destinations:



[snip]

You may find it far simpler to just ask the person who owns the sources 
that those packets are. While this may not be politically feasible (insert 
network and privacy policies here), given the amount of VPN traffic that's 
encapsulated in UDP, that may be anything. The problem with netflow is 
that it does reveal many interesting, hypnotic patterns inside your 
network. Having spent my share of time on the receiving end of that 
lunacy, I can only offer this advice: Drinking from the firehose is only 
funny for a little while.


Depending on your deployment method (transit flow monitoring vs locally 
sourced, data center vs office campus, college campus vs four hippies with 
tin cans), identifying flows may be far easier if you have a network 
inventory to refer to. Even something as simple as parsing XML output from 
NMAP into a db will give you better insight into what your flows are.


Incidentally (because I ask everyone this), what's your flow volume 
(flows per second)?


- billn

Re: Interesting netflow entry

[Wil Schultz]

Here is another pattern, sourced off of one the destinations:

2006-02-06 10:37:17.3920.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   68 1
2006-02-06 10:50:39.4740.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 11:03:11.2800.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 11:15:23.1990.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 11:28:45.1290.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 11:42:07.0320.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 11:54:08.7610.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 12:06:10.5240.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 12:19:22.7060.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 12:31:24.3400.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 12:42:36.1610.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 12:54:38.1120.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 13:06:50.1980.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 13:20:12.7720.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 13:32:14.6260.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1
2006-02-06 13:44:16.6080.000 UDP  10.XX.XX.99:1204  ->  
BB.BB.BB.BB:159891   69 1


Looks like it atempts to hit every 10 minutes or so. I was able to grab 
a few packets, here they are:


No. TimeSourceDestination   Protocol 
Info
  3047 3.58745910.XX.XX.99   AA.AA.AA.AA UDP  
Source port: 1204  Destination port: 33255


Frame 3047 (139 bytes on wire, 139 bytes captured)
   Arrival Time: Feb  6, 2006 10:55:20.087322000
   Time delta from previous packet: 3.587459000 seconds
   Time since reference or first frame: 3.587459000 seconds
   Frame Number: 3047
   Packet Length: 139 bytes
   Capture Length: 139 bytes
Ethernet II, Src: 00:12:3f:34:b1:8d, Dst: 00:00:0c:07:ac:cf
   Destination: 00:00:0c:07:ac:cf (10.XX.XX.1)
   Source: 00:12:3f:34:b1:8d (10.XX.XX.99)
   Type: IP (0x0800)
Internet Protocol, Src Addr: 10.XX.XX.99 (10.XX.XX.99), Dst Addr: 
AA.AA.AA.AA (AA.AA.AA.AA)

   Version: 4
   Header length: 20 bytes
   Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    00.. = Differentiated Services Codepoint: Default (0x00)
    ..0. = ECN-Capable Transport (ECT): 0
    ...0 = ECN-CE: 0
   Total Length: 125
   Identification: 0x2254 (8788)
   Flags: 0x00
   0... = Reserved bit: Not set
   .0.. = Don't fragment: Not set
   ..0. = More fragments: Not set
   Fragment offset: 0
   Time to live: 128
   Protocol: UDP (0x11)
   Header checksum: 0x748d (correct)
   Source: 10.XX.XX.99 (10.XX.XX.99)
   Destination: AA.AA.AA.AA (AA.AA.AA.AA)
User Datagram Protocol, Src Port: 1204 (1204), Dst Port: 33255 (33255)
   Source port: 1204 (1204)
   Destination port: 33255 (33255)
   Length: 105
   Checksum: 0xb250 (correct)
Data (97 bytes)

  00 00 0c 07 ac cf 00 12 3f 34 b1 8d 08 00 45 00   ?4E.
0010  00 7d 22 54 00 00 80 11 74 8d c0 a8 cf cc 42 d7   .}"Tt.B.
0020  d0 42 04 b4 81 e7 00 69 b2 50 c2 d3 02 96 e1 7d   .B.i.P.}
0030  27 ee 2f cb ab aa 64 67 d5 43 d6 b7 d7 54 22 41   './...dg.C...T"A
0040  f8 4f d3 cb 04 48 f8 33 20 a5 cf 1d f4 15 51 9e   .O...H.3 .Q.
0050  9e 57 35 ca e4 76 54 06 54 67 7a 26 35 01 1d 5b   .W5..vT.Tgz&5..[
0060  70 b3 cf c3 20 e2 d6 30 8d df 0b ab 62 66 39 84   p... ..0bf9.
0070  8d d2 f8 e5 9f ef 59 68 4c e3 7f 0c 19 65 6d 9b   ..YhLem.
0080  cb 37 58 3e 2e 74 33 8e b9 4a c4  .7X>.t3..J.

No. TimeSourceDestination   Protocol 
Info
  3048 3.58746310.XX.XX.99   BB.BB.BB.BB  UDP  
Source port: 1204  Destination port: 29717


Frame 3048 (139 bytes on wire, 139 bytes captured)
   Arrival Time: Feb  6, 2006 10:55:20.087326000
   Time delta from previous packet: 0.04000 seconds
   Time since reference or first frame: 3.587463000 seconds
   Frame Number: 3048
   Packet Length: 139 bytes
   Capture Length: 139 bytes
Ethernet II, Src: 00:12:3f:34:b1:8d, Dst: 00:00:0c:07:ac:cf
   Destination: 00:00:0c:07:ac:cf (10.XX.XX.1)
   Source: 00:12:3f:34:b1:8d (10.XX.XX.99)
   Type: IP (0x0800)
Internet Protocol, Src Addr: 10.XX.XX.99 (10.XX.XX.99), Dst Addr: 
BB.BB.BB.BB (BB.BB.BB.BB)

   Version: 4
   Header length: 20 bytes
   Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    00.. = Differentiated Services Codepoint: Default (0x00)
    ..0. = ECN

Re: On the inoc-dba subject

[Bill Woodcock]

> Advising people who do not validate with spf to 
> whitelist by domain name is an over-simplification.

In fact, we don't advise them to do either one.  The cautionary message is 
to remind the significant (~10%) portion of people who try to sign up 
using blocked email addresses why it might be that they're failing and not 
seeing any error messages from us.

Believe me, we'd much prefer people found better ways of dealing with 
spam.

-Bill

Lightning Talks at NANOG 36

[Steve Feldman]

We have reserved one hour of the NANOG 36 agenda for "Lightning Talks".

A lightning talk is a very short presentation or speech by any
attendee on any topic relevant to the NANOG audience.  These are
limited to ten minutes; this will be strictly enforced.

If have a topic that's timely, interesting, or even a crackpot idea
you want to share, we encourage you to consider presenting it.

Signups for lightning talks will be accepted during the NANOG
meeting.  The Program Committee will accept relevant talks until
all the slots are filled.  (Details will be announced during the
meeting.)

Use of slides is optional.  Any slides must be in PDF or Powerpoint
format, and will be loaded in advance onto the speaker laptop on
the podium.

There is a good overview of the use of lightning talks at the Perl
coference at:
  http://www.perl.com/pub/a/2004/07/30/lightningtalk.html

Although their format is slightly different, many of their ideas
will apply here.

Looking forward to seeing you in Dallas,
Steve Feldman
PC Chair

Interesting netflow entry

[Wil Schultz]

After setting up netflow this morning I have a of recurring flow that 
seems bothersome to me. I have an internal host (10.X.X.99) that 
continually attempts to hit various external hosts (AA, BB, CC, etc...) 
on seemingly random ports but always sources port udp.1204. In about 2 
hours this host has hit 155 different external hosts, some of them once 
or twice and some of them more than 10 times. Below is a sanitised 10 
minute output.


11:41:37.0310.000 UDP  10.XX.XX.99:1204  ->
AA.AA.AA.AA:46299   (RoadRunner, VA US)
11:42:07.0320.000 UDP  10.XX.XX.99:1204  ->
BB.BB.BB.BB:15989 (Comcast, MI US)
11:42:37.0960.000 UDP  10.XX.XX.99:1204  ->
CC.CC.CC.CC:52566   (Comcast, IL US)
11:43:17.2040.000 UDP  10.XX.XX.99:1204  ->DD.DD.DD.DD:47756 
 (Adelphia, CA US)
11:45:27.5210.000 UDP  10.XX.XX.99:1204  ->EE.EE.EE.EE:20797 
 (Tokyo)
11:46:07.6850.000 UDP  10.XX.XX.99:1204  ->FF.FF.FF.FF:21363
  (Surrey UK)
11:48:47.9910.000 UDP  10.XX.XX.99:1204  ->GG.GG.GG.GG:48324 
 (Israel)


Interestingly enough, I've checked to see if this seemingly random port 
was actually listening and each of the 15-20 hosts I've checked are all 
listening on their port, i.e. AA.AA.AA.AA has udp.46299 open while 
BB.BB.BB.BB has udp.15989 open. When a host was contacted multiple times 
the "random" dstport is always the same.


Anyone have any clue on to what could be going on here?

-Wil

CAIDA analysis on CME-24/BlackWorm

[Gadi Evron]

The analysis can be found here:
http://www.caida.org/analysis/security/blackworm/

As usual, CAIDA's people have done amazing work.

Gadi.

Re: NetFlow tools?

[Wil Schultz]

Thanks for all of the responses!

So the goal is to be able to monitor flows real time as well as 
historically, set up triggers when specific criteria is met, and nice 
graphs are always a definate plus. Site consists of 4 6509's with a 95th 
percentile of about 120MBits, along with about 30 other various devices 
along the way.


I've set up a pretty default installation of nfdump, seems reasonable. 
Already have found some stuff that seems out of the norm, I'll probably 
start another thread about that shortly.


I am looking forward to getting nfsen up and running probably within the 
next couple of days.


-Wil

Re: CAUTION: Potentially Dumb Question...

[Randy Bush]

> I'm interested in responses to this ...  MPLS is still a four letter word
> ..  :)

Re: CAUTION: Potentially Dumb Question...

[Jason Frisvold]

On 2/6/06, Rich Sena <[EMAIL PROTECTED]> wrote:
> I'm trying to cut a few financial corners in our remote site budgets.  I

*insert network crash noises here*

> have sites that are homed back to the main campus offices via ATM and
> other leased lines.  These sites also currently have dedicated Internet
> access.  I was doing some brain cramming re: MPLS and possibly killing
> our dependence on ATM by going the MPLS route over a common provider.  It
> struck me to venture a guess as to why I couldn't utilize the same
> connection for both - Internet transit via the common provider as well as
> an MPLS mesh between all my sites and my main campuses also via that same
> connection with the common provider...

Wouldn't this be something similar to frame relay?  If I understand
MPLS correctly, this should be a fairly simple implementation ...

> If you feel this is OT then reply to me direct if there is other interest
> I will summarize...

I'm interested in responses to this ...  MPLS is still a four letter word ..  :)

> --
> Rich Sena - [EMAIL PROTECTED]

--
Jason 'XenoPhage' Frisvold
[EMAIL PROTECTED]

TWTC as4323 full routes

[Jon Lewis]

Has anyone else with a transit connection to Time Warner Telecom noticed 
TWTC on and off over the past few days advertising an extra 2500 or so 
routes?  Right now, I've got 180169 routes from 4323...and 176-177K from 
other transits.  I noticed them setting off my BGP-4-MAXPFX warning :(


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

intergalactic nog

[Randy Bush]

as gadi has just discovered there's a whole world out there, he
seemed unaware of your all being there so is sending this message
to everyone he can find.  hence, the message is not private, so i
can distribute, and i thought i would save everyone the trouble.

[ btw, i personally don't support this ]

randy


From: Gadi Evron <[EMAIL PROTECTED]>
To: Randy Bush <[EMAIL PROTECTED]>
Subject: establishing a global NOG
Date: Mon, 06 Feb 2006 21:23:09 +0200

Hello! How are you?

After the recent CME-24/BlackWorm incident I finally realized just how
large the net-ops world outside of the US really is. I found many people
from South Asia, Africa, etc. who were very helpful, serious and
knowledgeable yet outside of my normal circles.

The global ad-hoc cooperation that took place really made me realize
that it is past time for a global NOG to form.

We are working on locating leading net-ops people from different NOGs
around the world in order to get started.

What we have in mind is an open and public group, but with a semi-strict
code. I figure we'll figure it out as we go.

I'd like to invite you on-board, as well as ask you if you know of
others who may be a good addition for our critical mass when we start.

Thanks, I'd appreciate any input.

Gadi.

Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T

[Alain Hebert]

   ( You can said that it means nothing but... (; )

   I second that.  I always crimp (or check) for it.

   Also watch for Cat 6 cabling ... 23 gauge is hell to crimp.  24 is 
livable but takes twice as much time to do than Cat 5e.
   (You have to cut that little plastic guide and the pairs are a bit 
more twisted)


   I just did a 72 pairs (BIXed + crimped) in Cat 6...  And I'm still 
wondering if its that advantagious.



Also:
   Anybody fix a cabling issue by using Cat 6 over Cat 5e?


   Let us know.

   ( There is nothing nicer than a POP on a diet...  a fiber diet that 
is! )


Jeff Rosowski wrote:




According to "Ethernet, The Definitive Guide", that feature is an
optional part of the spec.

One thing I've heard people encounter is that if they use a cross-over
cable, which probably really implies a 100BASE-TX cross-over, then the
ports only go to 100Mbps. A Gig-E rated straight through, in conjunction
with the automatic crossover feature, was necessary to get to GigE.



A lot of cross over cables only cross pairs 1-2 with 3-6, leaving 4-5, 
and 7-8 as straight through.  Gig-E uses all four pair.





--
Alain Hebert[EMAIL PROTECTED]   
PubNIX Inc.
P.O. Box 175   Beaconsfield, Quebec H9W 5T7	

tel 514-990-5911   http://www.pubnix.netfax 514-990-9443

Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T

[Jeff Rosowski]

According to "Ethernet, The Definitive Guide", that feature is an
optional part of the spec.

One thing I've heard people encounter is that if they use a cross-over
cable, which probably really implies a 100BASE-TX cross-over, then the
ports only go to 100Mbps. A Gig-E rated straight through, in conjunction
with the automatic crossover feature, was necessary to get to GigE.


A lot of cross over cables only cross pairs 1-2 with 3-6, leaving 4-5, and 
7-8 as straight through.  Gig-E uses all four pair.

Re: Did anyone else notice the CAIDA skitter poster in the background of George Bush's speech at the NSA?

[Austin McKinley]

Etaoin Shrdlu wrote:

The *entire* point of that, was to make it clear that everything you 
saw was *manufactured*, that the NSA (and other agencies) are _not_ 
going to have data up on a screen that pertains to _anything_ during a 
photo op, with a bunch of reporters and politicos.




Go forward a few more pictures; check out the dshield map on image 23 :)

Austin

Re: So -- what did happen to Panix?

[Martin Hannigan]

At 02:05 AM 2/6/2006, Nick Feamster wrote:


Martin Hannigan wrote:

[ SNIP ]


> If you are changing providers, which takes

awhile anyway,


That process seems to be getting quicker:
http://www.equinix.com/prod_serv/network/ed.htm


NOT an ISP product.


Independent of ED, one should be cautious when designing routing 
protocols based on logistical and business assumptions (e.g., 
switching providers takes awhile, most business policies are vanilla 
peering, etc.).


These assumptions are certainly not fundamental, and they may not 
always be true, regardless of what exists today.



I got some "can you elaborate" comments so please forgive my
second response.

What I thought I read was that you thought Equinix had an interesting
play in a transitioning and provisioning strategy for ISP's.

My answer, in short, was to say that I see it as more of an enterprise
play because it's a managed service and the hardest part of
provisioning is typically the order cycle.
If you are an ISP, you are theoretically multi homed by definition
and your providers are going to remain fairly stable (you hope)
based on your own needs.

Equinix direct is a bandwidth commodity in my mind. Anyone remember
Invisible Hand (still in business, btw http://www.invisiblehand.net/)

Equinix handles the software interaction and is the market maker. Customers
appear to providers and providers can decide if they want to sell to
customers. For example, if you show up at ED and need X gigs, a provider
could opt out of the market because you are a highcap customer. In the end,
the market maker gets a piece of the action from the provider and sends the
"customer" a bill since it is theoretically the provider. I think there's
a question about neutrality, but there are no more pure neutral colo
houses so that is somewhat irrelevant unless it's completely bogus like
selling interconnect network or something vs. the ILEC.

In an environment like Equinix or S&D, you could attach to the public
peering fabric and "make connections", and then if you need someone
specific you can hope to get them on ED (in Equinixs case) without
buying dedicated transit. In short, it's easy.

With that said, I believe most ISP's would be better suited to
overlapped service or TE'ing vs. using commodity markets for
b/w, IMHO.

Thanks,


-M<




Martin Hannigan(c) 617-388-2663
Renesys Corporation(w) 617-395-8574
Member of Technical Staff  Network Operations
   [EMAIL PROTECTED]  

RE: Did anyone else notice the CAIDA skitter poster in the background of George Bush's speech at the NSA?

[Joel Jaeggli]

On Mon, 6 Feb 2006, Barry Greene (bgreene) wrote:




Maybe now the US Gov can open their pocket book and pay for Skitter? :-)


DARPA grant N66001-01-1-8909
DARPA grant N66001-98-2-8922
NSF ANIR Grant NCR-9711092


-Original Message-
From: Martin Hannigan [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 05, 2006 10:55 PM
To: Etaoin Shrdlu
Cc: Barry Greene (bgreene)
Subject: Re: Did anyone else notice the CAIDA skitter poster
in the background of George Bush's speech at the NSA?

At 06:02 PM 2/5/2006, Etaoin Shrdlu wrote:


Joe McGuckin wrote:


http://tinyurl.com/doy6r



Um... (noticed on other lists, by the way)

http://securitywizardry.com/radar.htm





I like the skitter chart, but at the Vegas NANOG, Barry
Greene disclaimed it and said it was "out of date". I hope
the NSA is using up to date data. It would be horrific if
they weren't.




Martin Hannigan(c) 617-388-2663
Renesys Corporation(w) 617-395-8574
Member of the Technical Staff  Network Operations
[EMAIL PROTECTED]





--
--
Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: Did anyone else notice the CAIDA skitter poster in the background of George Bush's speech at the NSA?

[Etaoin Shrdlu]

Barry Greene (bgreene) wrote:

[moved comment to bottom; top posting bad]

From: Martin Hannigan [mailto:[EMAIL PROTECTED] 
   


[also hate outlook]


At 06:02 PM 2/5/2006, Etaoin Shrdlu wrote:
   




Joe McGuckin wrote:

 


http://tinyurl.com/doy6r
   


Um... (noticed on other lists, by the way)

http://securitywizardry.com/radar.htm
 



The *entire* point of that, was to make it clear that everything you saw 
was *manufactured*, that the NSA (and other agencies) are _not_ going to 
have data up on a screen that pertains to _anything_ during a photo op, 
with a bunch of reporters and politicos.


I like the skitter chart, but at the Vegas NANOG, Barry 
Greene disclaimed it and said it was "out of date". I hope 
the NSA is using up to date data. It would be horrific if 
they weren't.
   



My bet is that they have more up to date data.


Maybe now the US Gov can open their pocket book and pay for Skitter? :-)
 



Well, as I'd said first time around, it was probably just an image that 
was a part of the overall construction. Amusing to look at, but I doubt 
whether you can take anything you see there as reality.


--
Everyone picks and chooses, an infinite number of times a day.

- David Phalen, One For the Road, in Analog, March 2001

Re: On the inoc-dba subject

[Jon Lewis]

On Mon, 6 Feb 2006, Joe Maimon wrote:


pch.net publishes a SPF record:
"v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org
a:ghosthacked.net ~all"

Besides going from soft-fail (~all) to fail (-all), they are already
giving you the tools you need to validate a MAIL FROM: claim.


Thats all very well and good, but advising people who do not validate with 
spf to whitelist by domain name is an over-simplification.


So call it additional clue-boundary to entry and be done with this silly 
thread.


Besides, the site doesn't specify how to filter/whitelist...just to make 
sure you can accept mail from pch.net.  A simple person might take that to 
mean "I better allow any @pch.net from address" but that's not what the 
site says.


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: On the inoc-dba subject

[Suresh Ramasubramanian]

On 2/6/06, Rubens Kuhl Jr. <[EMAIL PROTECTED]> wrote:
>
> pch.net publishes a SPF record:
> "v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org
> a:ghosthacked.net ~all"
>
> Besides going from soft-fail (~all) to fail (-all), they are already
> giving you the tools you need to validate a MAIL FROM: claim.
>

*koff* .forwards etc cans of worms *koff*

Woody's clear enough there - make sure your filters allow email from us.

Minor but tedious details like "how to do that" can best be left to
individual administrators.  Probably get the job done without turning
on spf lookups.

--
Suresh Ramasubramanian ([EMAIL PROTECTED])

RE: Did anyone else notice the CAIDA skitter poster in the background of George Bush's speech at the NSA?

[Barry Greene (bgreene)]

 
Maybe now the US Gov can open their pocket book and pay for Skitter? :-)

> -Original Message-
> From: Martin Hannigan [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, February 05, 2006 10:55 PM
> To: Etaoin Shrdlu
> Cc: Barry Greene (bgreene)
> Subject: Re: Did anyone else notice the CAIDA skitter poster 
> in the background of George Bush's speech at the NSA?
> 
> At 06:02 PM 2/5/2006, Etaoin Shrdlu wrote:
> 
> >Joe McGuckin wrote:
> >
> >>http://tinyurl.com/doy6r
> >
> >
> >Um... (noticed on other lists, by the way)
> >
> >http://securitywizardry.com/radar.htm
> >
> 
> 
> 
> I like the skitter chart, but at the Vegas NANOG, Barry 
> Greene disclaimed it and said it was "out of date". I hope 
> the NSA is using up to date data. It would be horrific if 
> they weren't.
> 
> 
> 
> 
> Martin Hannigan(c) 617-388-2663
> Renesys Corporation(w) 617-395-8574
> Member of the Technical Staff  Network Operations
> [EMAIL PROTECTED]  
> 

Re: On the inoc-dba subject

[Joe Maimon]

Rubens Kuhl Jr. wrote:




pch.net publishes a SPF record:
"v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org
a:ghosthacked.net ~all"

Besides going from soft-fail (~all) to fail (-all), they are already
giving you the tools you need to validate a MAIL FROM: claim.


Rubens




Thats all very well and good, but advising people who do not validate 
with spf to whitelist by domain name is an over-simplification.

Re: On the inoc-dba subject

[Rubens Kuhl Jr.]

> "
> Please make sure that your spam filters allow email from "pch.net"
> before you sign up, since we will need to automatically verify your
> email address.
> "
>
> Since we all know that whitelisting and blacklisting by in-band stated
> "from" email address is quite wrong-headed, from a clue standpoint.
>
>
> Perhaps something like this?
>
> "
> Please make sure that your spam filters allow email sent from
>  with a from address of pch.net before you sign up, since
> we will need to automatically verify your email address.
> "
>
> Where  is the output of a dig command against the outgoing
> smtp servers sending the notifications?

pch.net publishes a SPF record:
"v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org
a:ghosthacked.net ~all"

Besides going from soft-fail (~all) to fail (-all), they are already
giving you the tools you need to validate a MAIL FROM: claim.


Rubens

On the inoc-dba subject

[Joe Maimon]

Is it really cluefull to have this paragraph?


"
Please make sure that your spam filters allow email from "pch.net"
before you sign up, since we will need to automatically verify your
email address.
"

Since we all know that whitelisting and blacklisting by in-band stated 
"from" email address is quite wrong-headed, from a clue standpoint.



Perhaps something like this?

"
Please make sure that your spam filters allow email sent from 
 with a from address of pch.net before you sign up, since 
we will need to automatically verify your email address.

"

Where  is the output of a dig command against the outgoing 
smtp servers sending the notifications?


In general, ML and other automated email things should have a way to 
display the bounce to the user, which would mean storing it for some 
small period of time. Otherwise it becomes rather difficult to do the 
right thing filtering wise.


(Google seems to do this for their notifications that get 45x/55x)

Joe

Re: Anyone heard of INOC-DBA?

[Michael . Dillon]

> > How about INOC-DBA, which is supposed to have a clue threshold you
> > obtained an ASN by some means in order to have a dial-by-asn phone.
> 
> Obtaining an ASN isn't much of a clue threshold.

However, obtaining an ASN is a volume threshold which
is far more important to the people on the receiving
end of the communications.

--Michael Dillon

Re: So -- what did happen to Panix?

[Michael . Dillon]

> Other networks have no such incentive, since their transit providers 
> and peers either build their filters in other ways, or don't filter 
> at all.

There is nothing wrong with building your filter in
some other way, however, that does not mean that you
cannot validate your filters against the IRR and take
some action on mismatches. For instance you could email
the prefix owners about the mismatch and ask them to
update the IRR.

> Wherever there is a lack of incentive to keep records accurate, we 
> can probably safely assume that they are either missing or stale.

Yes. Without regular validation or auditing of data,
it does not stay up to date.

> It's probably fair to say that if all the large, default-free 
> carriers insisted that their customers submitted their routes to the 
> IRR, then every route would be registered. This would not completely 
> address the problem of stale data, though.

It's a good start. Perhaps if we decouple the idea of an IRR
from "building filters" more people will see the usefulness
of a distributed repository of information against which
they can validate (cryptographically or otherwise) their
routing data.

Right now the secure BGP protocols require a network to
climb the hurdles of cryptographic certification in order
to participate. A revised and renewed IRR can lower that
barrier so that people can participate even before they
implement cryptographic signing and certification.

> The IRR is a loosely-connected collection of route registries, all 
> run by different people. Data originating in one database is 
> frequently found to be mirrored in other databases, but not in any 
> great systematic fashion.

If the networking community can't solve the problem
of managing the distributed route registries in a systematic
fashion, then how can it implement one of the secure BGP proposals?

--Michael Dillon

Re: So -- what did happen to Panix?

[Michael . Dillon]

> > If an IRR suffers from bit-rot, then I don't consider
> > it to be "well-operated" and therefore it cannot be
> > considered to be part of a well-operated network of
> > IRRs.
> 
> honestly I'm not a fan of IRR's, so don't pay attention to them, but... 
is
> the IRR 'not well operated' or is the data stale because the 'users' of
> the IRR are 'not well operated' ? (the IRR as near as I can tell is
> nothing but a web/whois server that you sign-up-for and push/pull data
> through, right?)

Indeed it is not much more than a server with a database
which is why I do not consider it to be well-operated.
In order to be "well-operated", somebody (or some organization)
needs to take responsibility for the data in the database
and make sure that this data is as accurate as can be.

I'm really saying that if people want to solve this
problem jointly, then the tools are already there for
a membership organization to use. And such an organization
could also work on a revised BGP protocol as a longer term
solution.

But, in the absence of such an organization we have nothing
more than a disorganized chaos in which nothing much changes.

--Michael Dillon

AW: flow -> web

[tom]

If one does not wanna use netflow, but ipaccounting, then this is a also a
nice solution...
http://ipacco.sourceforge.net/index.php

tom from munich/germany


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
Randy Bush
Gesendet: Montag, 6. Februar 2006 09:25
An: [EMAIL PROTECTED]
Betreff: Re: flow -> web


folk have asked me to summarize.  so here it goes

"Justin M. Streiner" <[EMAIL PROTECTED]> and Nicolas Strina
<[EMAIL PROTECTED]> recommended the nfdump nfsen pair,

http://nfsen.sourceforge.net
http://nfdump.sourceforge.net

Chris Kuethe <[EMAIL PROTECTED]> and Peter Wohlers <[EMAIL PROTECTED]>
recommended ntop

http://www.ntop.org/

Peter Wohlers <[EMAIL PROTECTED]> also recommended Stager

http://software.uninett.no/stager/?page=docs

Steven Rakick <[EMAIL PROTECTED]> recommended nSight

http://www.obtuse.net/software/nsight

Tony Hacche <[EMAIL PROTECTED]> recommended Crannog's NetFlow Tracker

 
http://www.crannog-software.com/index.php?go=Product.ShowDetail&ProductID=1

Jared Mauch <[EMAIL PROTECTED]> has a tool to detect and highlight ddos
symptoms, but it does not have per-protocol sexy graphs.  looks very useful
for ddos detection, though

---

i am currently playing with nfsdump/nfsen

randy

Re: flow -> web

[Randy Bush]

folk have asked me to summarize.  so here it goes

"Justin M. Streiner" <[EMAIL PROTECTED]> and Nicolas Strina
<[EMAIL PROTECTED]> recommended the nfdump nfsen pair,

http://nfsen.sourceforge.net
http://nfdump.sourceforge.net

Chris Kuethe <[EMAIL PROTECTED]> and Peter Wohlers
<[EMAIL PROTECTED]> recommended ntop

http://www.ntop.org/

Peter Wohlers <[EMAIL PROTECTED]> also recommended Stager

http://software.uninett.no/stager/?page=docs

Steven Rakick <[EMAIL PROTECTED]> recommended nSight

http://www.obtuse.net/software/nsight

Tony Hacche <[EMAIL PROTECTED]> recommended Crannog's NetFlow
Tracker

http://www.crannog-software.com/index.php?go=Product.ShowDetail&ProductID=1

Jared Mauch <[EMAIL PROTECTED]> has a tool to detect and
highlight ddos symptoms, but it does not have per-protocol sexy
graphs.  looks very useful for ddos detection, though

---

i am currently playing with nfsdump/nfsen

randy