October 2002 - Test - lists.nanog.org

RE: Provider feedback
by Tech Team1 31 Oct '02

31 Oct '02

I wanted to, but there were "political" reasons why we didn't. That's about all I can say. > -----Original Message----- > From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > Sent: Thursday, October 31, 2002 4:35 PM > To: Todd Graf > Subject: RE: Provider feedback Aleron=BAD! > > > > TT> Date: Thu, 31 Oct 2002 16:10:01 -0600 > TT> From: Tech Team1 > > > TT> Since we had about 16 /24s (well utilized) this was going to > > And you didn't approach ARIN for PI space? > > > Eddy > -- > Brotsman & Dreger, Inc. - EverQuick Internet Division > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 (785) 865-5885 Lawrence and [inter]national > Phone: +1 (316) 794-8922 Wichita > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) > From: A Trap <blacklist(a)brics.com> > To: blacklist(a)brics.com > Subject: Please ignore this portion of my mail signature. > > These last few lines are a trap for address-harvesting spambots. > Do NOT send mail to <blacklist(a)brics.com>, or you are likely to > be blocked. > >

1 0

Troubles reaching hosts through propagation.net
by Damian Gerow 31 Oct '02

31 Oct '02

Can anyone with a host on 64/8 try reaching termforsale.net or creativesound.ca? We're having troubles reaching either of those from various hosts on that subnet. Just looking for some more details, since some hosts on 64/8 can reach it, while others cannot. We've been trying to get this solved since last Monday, and have just been getting the runaround from them. If anyone's got a contact there, or can pass this off to them, I'd greatly appreciate it.

1 2

RE: ISDN tip wanted
by Jim Deleskie 31 Oct '02

31 Oct '02

While its been many years since I've done ISDN, I do know it was quite common for 64k call to be rejected but a 56k make it though, as I remember from a bell tech I worked with it has to do with 'new' channels being full and dropping to an older path that can only handle 56k. But like it said its been years since I've work with ISDN. -Jim -----Original Message----- From: Ian MacKinnon [mailto:ian@teliauk.com] Sent: Thursday, October 31, 2002 10:36 AM To: nanog(a)nanog.org Subject: Re: ISDN tip wanted Surely it can't be that, as the call has been answered. Neil J. McRae wrote: > > try making it a 56K isdn call. > > Neil. > > [ Charset ISO-8859-1 unsupported, converting... ] > >>Hi, >>I'm trying to establish an ISDN call between Switzerland and New-York. The destination is in New-York, ISDN line provided by Verizon. The called is disconnected just after being set up (see NY-router log below), and the problem seems to be that Verizon switch does not understand the callref flag (0x01 and 0x81) correctly. >> >>The funny thing is that i have another router in NY, another ISDN line from Verizon, and i'm calling from the same number in CH and it works perfectly... >> >>Does anyone have a hint for me ? >>Thanks >>Andr? >> >>Oct 31 14:23:56.350 MET: ISDN BR0/0: RX <- SETUP pd = 8 callref = 0x01 >>Oct 31 14:23:56.350 MET: Bearer Capability i = 0x8890 >>Oct 31 14:23:56.350 MET: Channel ID i = 0x89 >>Oct 31 14:23:56.350 MET: Signal i = 0x40 - Alerting on - pattern 0 >>Oct 31 14:23:56.350 MET: Calling Party Number i = 0x1183, '<calling number removed>' >>Oct 31 14:23:56.354 MET: Called Party Number i = 0xC1, '<called number removed>' >>Oct 31 14:23:56.354 MET: Locking Shift to Codeset 5 >>Oct 31 14:23:56.354 MET: Codeset 5 IE 0x2A i = 0x808B0B, '<calling number removed>', 0x800109800114800114800114 >>Oct 31 14:23:56.358 MET: ISDN BR0/0: Incoming call id = 0x9E, dsl 0 >>Oct 31 14:23:56.358 MET: ISDN BR0/0: received HOST_INCOMING_CALL call_id 0x9E >>Oct 31 14:23:56.358 MET: ISDN BR0/0: HOST_INCOMING_CALL: voice_answer_data = FALSE >>Oct 31 14:23:56.358 MET: ISDN BR0/0: Event: Received a DATA call from <calling number removed> on B1 at 64 Kb/s >>Oct 31 14:23:56.358 MET: ISDN BR0/0: RM returned call_type 0 resource type 0 >>Oct 31 14:23:56.362 MET: ISDN BR0/0: TX -> CALL_PROC pd = 8 callref = 0x81 >>Oct 31 14:23:56.362 MET: Channel ID i = 0x89 >>Oct 31 14:23:56.362 MET: ISDN BR0/0: isdn_send_connect(): msg 4, call id 0x9E, ces 1 bchan 0, call type DATA >>Oct 31 14:23:56.366 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up >>Oct 31 14:23:56.370 MET: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to <calling number removed> >>Oct 31 14:23:56.462 MET: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0x01 >>Oct 31 14:23:56.462 MET: Cause i = 0x82D1 - Invalid call reference value >>Oct 31 14:23:56.466 MET: ISDN BR0/0: received HOST_DISCONNECT_ACK call_id 0x9E >>Oct 31 14:23:56.466 MET: ISDN BR0/0: HOST_DISCONNECT_ACK: call type is DATA >>Oct 31 14:23:56.466 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down >>Oct 31 14:23:56.666 MET: CC: dsl 0 No CCB Src->HOST cid 0x9E, ev 0x4 ces 1 >>Oct 31 14:23:56.666 MET: ISDN BR0/0: received HOST_QUERY_RESPONSE call_id 0x9E >> >> >>--------------------- >>Andre Chapuis >>IP+ Engineering >>Swisscom Ltd >>Genfergasse 14 >>3050 Bern >>+41 31 893 89 61 >>chapuis(a)ip-plus.net >>CCIE #6023 >>---------------------- >> > > > > > -- > Neil J. McRae - Alive and Kicking > neil(a)DOMINO.ORG > > -- Ian

2 1

RE: no ip forged-source-address
by H. Michael Smith, Jr. 31 Oct '02

31 Oct '02

If you go back to the thread, you'll see that I was responding to the idea that using src-addr verification would not prevent someone from spoofing addresses on his/own own subnet. Others pointed out that while this might hide the true offender, it would still make the DoS attack easier to mitigate because the src addresses would indicate the network from which the attack originated (if not the actual hosts). Some folks didn't seem to appreciate the value here, therefore I asserted that there is a specific difference between packets with virtually random src addrs, and packets that passed through src-addr filters. The first set are not traceable and src addresses generally useless, while the 2nd set have src addresses that can be used to trace to at least the attack's source network. As for your confusion, I am not sure that I can help with that. :-) -----Original Message----- From: Christopher L. Morrow [mailto:chris@UU.NET] Sent: Thursday, October 31, 2002 1:21 AM To: H. Michael Smith, Jr. Cc: 'Hank Nussbacher'; variable(a)ednet.co.uk; nanog(a)nanog.org Subject: RE: no ip forged-source-address On Wed, 30 Oct 2002, H. Michael Smith, Jr. wrote: > > A fundamental effect of spoofing addresses from your local subnet is > that when the packets reach their target, the source addresses are > meaningful. I realize that the traceability of these packets has > already been mentioned, but I want to point out the profound difference > between a DDoS attack with meaningful vs. meaningless source addresses. > I'm confused.. its still a DoS attack, eh??

1 0

Re: no ip forged-source-address
by Michael Lamoureux 31 Oct '02

31 Oct '02

"daniel" == Daniel Senie <dts(a)senie.com> writes: daniel> If the government or other large buyers require network-wide daniel> ingress filtering in any supplier they buy from (something I daniel> suggested to the folks at eBay, Schwab, etc. in our phone daniel> calls after the attacks a few years ago), or if there were daniel> legal incentive, there might be a chance ISPs would find a daniel> financial motive to implement BCP 38. As it is, there's no daniel> incentive, so the path of least resistance is to do nothing. I find it interesting that you suggest that the legal incentive should be toward having the ISPs come up with a magic solution and not toward having the customers do egress filtering at the edge(s) of their network and actually perform something resembling security on the hosts on their networks. After all, it is not usually a security failing of the ISP that causes a DoS or DDoS attack, but utter incompetence or neglect by someone at the edge of the network. The problem is that it's those same people who have the money needed to keep the ISPs in business. Unless all ISPs decided to hold the customers responsible, they'd just move to another ISP. I'm not saying I don't think ISPs should filter where feasible, I'm just saying that if we're going to hold someone responsible, it should be the people who are responsible, not the people who are convenient. but my opinions are probably worthless, Michael

3 2

Active measurements BCP Internet Draft (fwd)
by Henk Uijterwaal (RIPE-NCC) 30 Oct '02

30 Oct '02

Folks, I've put the latest version of the Active Measurements BCP Internet Draft, that I mentioned during yesterday's Measurements panel, online at: http://www.ripe.net/home/henk/draft-ietf-ippm-owmetric-as-01.txt The draft is still very rough, comments, to the ippm(a)advanced.org list, are welcome, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)

2 1

OT: Fast.net NOC contact
by Jamie Norwood 30 Oct '02

30 Oct '02

OK, I normally try to avoid doing this, but could someone in Fast.net's NOC please drop me an email about a job you guys have posted there? Or just plain have a contact there they would be willing to set me up with? :) Thanks if you can help! Jamie

1 0

Re: no ip forged-source-address
by Daniel Senie 30 Oct '02

30 Oct '02

At 02:26 PM 10/30/2002, you wrote: >On Wed, 30 Oct 2002 variable(a)ednet.co.uk wrote: > >If every router in the world did this I could still use spoofed IP >addresses and DDOS someone. My little program could determine what subnet >I am on, check what other hosts are alive on the subnet and then when it >decides to attack, it would use some neighbor's IP. The subnet I am on is >a /24 and there very well may be a few dozen hosts. I could be real >sneaky and alter my IP randomly to be any of my neighbors for every packet >I send out. And the company being attacked would be able to find out what network you are on. >Traceback would get me instantly back to the offending subnet but then it >would take a bit of digging on the network admin to track me down and >applying RPF checking won't help. While that traceback is happening, your upstream ISP would be quite able to cut connectivity to your /24 while investigating which machine was causing the problem. It's a question of accountability. If that /24 is used by one company, it's now possible to know that company is your target when you file your court papers. >RPF checking can only go so far. You would need RPF checking down to the >host level and I haven't heard anyone discuss that yet. Getting to the subnet is sufficient bring the problem to the local entity involved. I think that's quite reasonable. If the /24 is a cable network, a packet analyzer in use by the local cable ISP will find the culprit. >-Hank > > > > > Hi, > > > > I've been following the discussion on DDoS attacks over the last few weeks > > and our network has also recently been the target of a sustained DDoS > > attack.I'm not alone in believing that source address filters are the > > simplest way to prevent the types of DDoS traffic that we have all been > > seeing with increasing regularity.Reading the comments on this list have > > lead me to believe that there is a lot of inertia involved in applying > > what appears to me as very simple filters. > > > > As with the smurf attacks a few years ago, best practice documents and > > RFC's don't appear to be effective.I realise that configuring and > > applying a source address filter is trivial, but not enough network admins > > seem to be taking the time to lock this down.If the equipment had > > sensible defaults (with the option to bypass them if required), then > > perhaps this would be less of an issue. > > > > Therefore, would it be a reasonable suggestion to ask router vendors to > > source address filtering in as an option[1] on the interface and then move > > it to being the default setting[2] after a period of time?This appeared > > to have some success with reducing the number of networks that forwarded > > broadcast packets (as with "no ip directed-broadcast"). > > > > Just my $0.02, > > > > > > Richard Morrell > > edNET > > > > [1] For example, an IOS config might be: > > > > interface fastethernet 1/0 > > no ip forged-source-address > > > > [2] Network admins would still have the option of turning it off, but this > > would have to be explicitly configured. > > > > > >

1 0

NMS/OSS commercial software : short summary from NANOG replies - here it is
by m.rapoport＠completel.fr 30 Oct '02

30 Oct '02

Sorry for my previous mail that was sent empty, due to a mouse clicking bug ;-) So, at last, here is the summary of the answers, plus additional information resulting from meetings I had with some vendors in the last days : First of all, one contributor emphazises on the fact that focusing on people and process is at least as important as on the tools used for NMS. Now the products : - Infovista : According to someone (Hi Mike,see you on rs-sp ;-) ), the product is considered to be flexible to build SLA reporting package, and very customizable to specific needs. According to another one: "Our NOC uses it and it just is not useful in any way, it usually is not common sense, the implementation is not straight- forward, it is awkward, and makes shortcuts that shall not be made". no comments .... >From a meeting I had with Infovista recently, my personal feelings are a mix of both opinions : It is surely a powerful tool, very customizable and scalable, but quite complex and heavy to deploy, and it costs a fortune (multiple hundreds of K$, not to say more). - Concord : >From one contributor :"horrible in multi-vendor environments" I have briefly met a Concord integrator, the product seems quite straight and simple to deploy, but very limited in terms of customization (all changes require C developpment). - Proviso : I have met the people from Quallaby today, the product looks both simple to install and powerful in terms flexibility and scalability. It might be a good product for perfs monitoring and customer SLA reports, but I had some rumors of possible bankrupcy of Quallaby ... I need to check more about it. - Netcool : seems to be quite a reference on the market, I only had good but not detailed opinions on it. - Cisco Works: not recommended by some people, or to be used for Natkit, which requires the NSA (Network supported account) level of support from Cisco (which is not cheap at all ;-). Quite an interesting doc recommended on NOC topics in general : http://www.cisco.com/networkers/nw02/presos/pws/docs/PS-510.pdf Other products that have been recommended by people on the list : - Smarts : http://www.smarts.com/ . The product looks interesting, and it was recommended by several persons on the list. Regarding my personal needs, I am not sure how well it is supported in Europe, and especially in France .... - LINMOR : www.linmor.com : a Canadian product. >From the contributor :"They are the prefered vendor for both Cisco & Micromuse when it comes to performance management" I might have the same problem that with Smarts in terms of finding here a reseller and appropriate support ... - SpiderMon, from Pathway Communication (a Canadian ISP reselling its in house NM tool) : It seems to be an all-in-1 product covering the whole FCAPS range. I can give more details on the product for person requesting it. An interesting article comparing Spectrum, Patrol, Netcool, and Smarts : http://www.networkcomputing.com/1316/1316f2.html All comments welcomed. ________________________ Marc Rapoport Architecture Dpt Completel tel : +33 1 72 92 25 38 fax: +33 6 09 76 56 79 m.rapoport(a)completel.fr ________________________

1 0

tiscali please:)
by Scott Granados 30 Oct '02

30 Oct '02

Can someone with Tiscali write to me off list concerning as9105.net Thanks Scott

1 0