August 2002 - Test - lists.nanog.org

Re: RFC 2870's applicability (Re: Deaggregating for emergency purposes)
by Paul Vixie 09 Aug '02

09 Aug '02

> > There's no way to change this, really, and one of the ways to not change > > it would be to write an RFC. USGov has its own way of doing things. ... > > They're welcome to run their own servers however they like. > However, if they want to arbitrarily cut off their networks from > "subversive" networks around the world, then I feel that they should ... When I tell USG how I feel, they seem to ignore me. Your mileage may vary.

8 7

Re: your mail
by Ukyo Kuonji 09 Aug '02

09 Aug '02

In my case, my VP had come up to me telling me that another group (where I had just transfered out of) wanted me fired from the company. Of course, my VP wasn't about to roll over for them, so my job remained intact. After a couple other failed attempts to get rid of me, the company finally layed me off with about 700 other employees. Of course, 10 months later, my old VP told me very well could have won a wrongful termination suit, as he had plenty of documentation. Either way, it was a sad parting, but I'm not so sure I would have wanted to work for the company any longer anyways. >From: Scott Granados <scott(a)graphidelix.net> >To: Ukyo Kuonji <kawaii_iinazuke(a)hotmail.com> >CC: <nanog(a)merit.edu> >Subject: Re: your mail >Date: Thu, 8 Aug 2002 14:42:37 -0700 (PDT) > >Do people really almost get fired for what they write here? I'd think >there would be more constructive things to do by management than read >nanog for questionable posts. If I were managing someone and they >posted their feeling on a subject and clearly said it was their own who >am I to have a problem with that. It might be in my best interest and >listen to them then silence them. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0

Re: Re: Network inventory and configuration tracking tools
by Frank Coluccio 09 Aug '02

09 Aug '02

> > On Wed, 7 Aug 2002, Sean Donelan wrote: > > > How about an operations oriented question. What is the current > > preferences amoung network operators for network inventory and > > configuration management tools? Not so much status monitoring (up, > > down) but other stuff network operator wants to know like circuit > > IDs (how many IDs can a circuit have?), network contacts, design layout > > reports (layer 1/2/3), what's supposed to be connected to that port? > > The stuff you can't get out of the box itself. > > > > Most ISPs seem to end up with a combination of homegrown systems, > > opensource, and commercial products. The commercial "integrated" > > systems have lots of stuff, and according to the vendors can do > > anything including splice fiber. > > We ended up in large part developing our own tools in-house. > > One is an SQL database to store and link network elements (routers, > interfaces/ports, circuits, IP addresses, contacts, etc) with hooks into > other internal databases and other outward-facing applications, such as > our rwhois server. > > Another is a tool that polls our network devices once every few hours and > backs up their configuration into an RCS filestore so we have journaling > capabilities. > > We do use some commercial tools, but those are mainly for customer > presentation (VitalSuite) and up/down reporting and event correlation > (Netcool). > > jms > jms, your message highlights the extent to which various systems with different missions in life come to interact with one another - 0R NOT. To wit, event correlation, network performance, line and port configs & inventory, etc. What I've not seen here spoken about much (if at all) has been the link between billing systems and all of the above. I recently undertook to reconcile billing discrepancies for a business unit in a large corporate account (a very large intl bank with 132 pops around the globe), and I found that there was no linkage between their *multiple,* internal bill-back systems (which naturally factored in markups to leased line costs that are paid by IT) and the circuit inventory systems. This has to be an issue with BBPs and ISPs, too, I'd imagine, if accurate and up to date billing is an interest. The manual processes that I had to endure in tallying the live circuit charges, and separating those charges from those being assessed for the "dead wood pile" were quite unbelievable in this day and age.

1 0

Network inventory and configuration tracking tools
by Sean Donelan 09 Aug '02

09 Aug '02

How about an operations oriented question. What is the current preferences amoung network operators for network inventory and configuration management tools? Not so much status monitoring (up, down) but other stuff network operator wants to know like circuit IDs (how many IDs can a circuit have?), network contacts, design layout reports (layer 1/2/3), what's supposed to be connected to that port? The stuff you can't get out of the box itself. Most ISPs seem to end up with a combination of homegrown systems, opensource, and commercial products. The commercial "integrated" systems have lots of stuff, and according to the vendors can do anything including splice fiber. CiscoWorks www.cisco.com Netcracker www.netcracker.com NetView www.tivoli.com Openview www.hp.com VitalQIP www.qip.lucent.com Visionael www.visionael.com

4 3

Re: If you have nothing to hide
by Steven M. Bellovin 09 Aug '02

09 Aug '02

In message <20020805225221.82473.qmail(a)sidehack.sat.gweep.net>, bdragon(a)gweep.n et writes: > >> >> >> "You know, there's quite a difference between source routing and >> IP spoofing .." >> >> >> >> As true as this statement is, the two walk hand in hand (especially during >> certain attacks). >> >> If I send an attack from a spoofed address to a victim, I can turn blue in >> the face waiting for a response that will never come. >> If I spoof an address and use loose source routing I can force the response >> to return right through my network. > >I was not aware that responses to source-routed packets were themselves >source-routed. I also don't believe it is the case, but am open to being >contradicted. If the responses aren't source-routed, then the packets would >only return through your network if your network was the path back to the >spoofed source. See section 3.2.1.8c of RFC 1122: If host receives a datagram containing a completed source route (i.e., the pointer points beyond the last field), the datagram has reached its final destination; the option as received (the recorded route) MUST be passed up to the transport layer (or to ICMP message processing). This recorded route will be reversed and used to form a return source route for reply datagrams (see discussion of IP Options in Section 4). When a return source route is built, it MUST be correctly formed even if the recorded route included the source host (see case (B) in the discussion below). --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

4 3

BGP evaluation
by Sathya Perla 09 Aug '02

09 Aug '02

Hi, In general, how is a BGP implementation evaluated/benchmarked by an operator? Are there any well-known figures relating to memory-consumption, speed of convergence, scalability etc. that one can benchmark with? There was a write-up on Data Comm magazine testing Juniper's M40 BGP. I haven't seen much more than that - especially test procedures used to compare various vendor implementations. Thanks in advance, -Sathya

2 1

Re: NSPs filter?
by Stephen Stuart 08 Aug '02

08 Aug '02

> One thing that sometimes comes up is that people do number links using > RFC1918 address space which occasionally results in an ICMP 'fragmentation > needed but DF bit set' packet with an RFC1918 source address. Filtering out > this packet could result in TCP breaking. That can be accomodated; behold, all the joy of PMTUD, with none of the other crap from designated special-use address space: firewall { family inet { filter external-filter { term allow-icmp-unreach { from { protocol icmp; icmp-type unreachable; icmp-code fragmentation-needed; } then { count allow-icmp-need-frag; accept; } } term allow-icmp-timxceed { from { protocol icmp; icmp-type time-exceeded; icmp-code [ ttl-eq-zero-during-transit ttl-eq-zero-during-reassembly ]; } then { count allow-icmp-timxceed; accept; } } term deny-rfc1918 { from { source-address { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; } } then { count deny-rfc1918; discard; } } term deny-test { from { source-address { 192.0.2.0/24; } } then { count deny-test-net; discard; } } term deny-autoconfig { from { source-address { 169.254.0.0/16; } } then { count deny-autoconfig; discard; } } term LAST { then accept; } } } } Application is left as an exercise to the reader. Stephen

1 0

Re: Re: NSPs filter?
by sal_sabella＠hushmail.com 08 Aug '02

08 Aug '02

Stephen Stuart wrote: >I made what I consider to be non-trivial progress toward stamping that >out before my time at the helm of 6461 ended. I happen to know that >the people still there are trying to continue making progress on that >front, what is going on around them. Confucious say: Man who sit on rose bush soon get point. >Would you care to take a shot at answering my question, or is >contributing productively too much to ask? My employer believes against filtering on source or destination. Communicate in total privacy. Get your free encrypted email at https://www.hushmail.com/?l=2 Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople

4 3

Re: your mail
by Ukyo Kuonji 08 Aug '02

08 Aug '02

Sorry, but there are valid reasons for posting anonymously. As one person that almost got fired from a company for expressing what was clearly marked as his own opinion to this list, I can attest to this. Some employers are concerned that you post during working hours, some are concerned that you use a work address, some are concerned that anything you say, no matter what email you use, will be considered as representations of the company's direction, even if it is clearly marked as not. I like helping and sharing my opinions, but I'm not willing to loose my job over it. UK >Date: Thu, 8 Aug 2002 00:13:22 -0400 (EDT) >From: Brian Wallingford <brian(a)meganet.net> > >Perhaps it's time to bar posting privileges from those who insist on >remaining entirely anonymous? > >I doubt that anyone who has anything substantive to offer would need to >use a hushmail/yahoo/etc. return address. > >The initial posts from Bandy, Vaul, et al were mildly amusing at first, >but the novelty wore out very quickly. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

3 2

[lamour@mail.argfrp.us.uu.net: Fwd: Re: If you have nothing to hide]
by Todd MacDermid 08 Aug '02

08 Aug '02

In message <20020805225221.82473.qmail(a)sidehack.sat.gweep.net>, bdragon(a)gweep.n et writes: > >I was not aware that responses to source-routed packets were themselves >source-routed. I also don't believe it is the case, but am open to being >contradicted. If the responses aren't source-routed, then the packets would >only return through your network if your network was the path back to the >spoofed source. A friend of mine directed me to this thread. Source routed packets can indeed be used to spoof IP connections, and I've written a tool to do it. It's available at http://www.synacklabs.net/projects/lsrtunnel If you simply want to check host behaviour to see if you can spoof connections, I've written a scanner at http://www.synacklabs.net/projects/lsrscan Short story is Solaris < 8 will reverse source routes by default, and Windows boxes will reverse source routes by default. The BSDs and Linuces I've tested mostly block source routed packets by default. Todd

1 0