- Test - lists.nanog.org

Re: ICANN Targets DDoS Attacks
by Crist J. Clark 01 Nov '02

01 Nov '02

On Tue, 29 Oct 2002 16:00:06 -0500, Valdis.Kletnieks(a)vt.edu wrote, > On Tue, 29 Oct 2002 12:48:39 PST, Jeff Shultz said: > > > >Smurf. > > > Okay. What will this do to my user's ping and traceroute times, if > > anything? I've got users who tend to panic if their latency hits 250ms > > between here and the moon (slight exaggeration, but only slight). > > > > I just love it when I've got people blaming me because the 20th hop on > > a traceroute starts returning * * * instead of times. > > So you rate limit it to several/second or something appropriate for the normal > traffic levels. You don't allow ping/traceroute to broadcast addresses. On the classless Internet, how does any router know what is or is not a broadcast address when the final destination is not local? -- Crist J. Clark | cjclark(a)alum.mit.edu | cjclark(a)jhu.edu http://people.freebsd.org/~cjc/ | cjc(a)freebsd.org

3 3

RE: Provider feedback Aleron=BAD!
by Tech Team1 01 Nov '02

01 Nov '02

We were multi-homed. Sprint was our other provider. They've been great. > > If they were singly homed to Aleron, technically, they don't qualify. >

1 0

Aleron maybe not so bad...
by Tech Team1 31 Oct '02

31 Oct '02

In the situation described in my last post, I was apparently dealing with a pre-bankrupt Aleron, which has now been bought out by another group which is improving things. So, let me restate my opinion.. I have no experience with the CURRENT Aleron, only the OLD Aleron. --Dan

1 0

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) 31 Oct '02

31 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