October 2002 - Test - lists.nanog.org

AT&T NYC
by Bryan Heitman 04 Sep '03

04 Sep '03

Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc.

10 11

question concerning traceroute?
by Darrell Carley 01 Dec '02

01 Dec '02

I am trying to troubleshoot a latency issue for some of our networks, and was wondering about this.Knowing that routing isn't always symmetrical, is it possible for a traceroute to traverse a different reverse path, than the path that it took to get there? .or will it provide a trace of the path the packet took to reach the destination? According to definition, is should take the same path, but are there any other cases that I should be aware of? Darrell

24 34

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

07 Nov '02

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. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Hank Nussbacher Sent: Wednesday, October 30, 2002 2:27 PM To: variable(a)ednet.co.uk Cc: nanog(a)nanog.org Subject: Re: no ip forged-source-address 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. 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. 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. -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. > > >

13 27

no ip forged-source-address
by variable＠ednet.co.uk 04 Nov '02

04 Nov '02

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.

11 14

ISDN tip wanted
by Andre Chapuis 04 Nov '02

04 Nov '02

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

9 11

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

03 Nov '02

David, We had a circuit through AGIS, who was bought by Telia, who was then bought by Aleron. Their billing practices were utterly terrible. Several months after Aleron aquired the network they informed us that we would now be billed an additional $250/month per /24 that we had with them! Since we had about 16 /24s (well utilized) this was going to effectively multiply our monthly bill by several hundred percent! When I called to clarify (ie. "You're telling me that we must pay almost $1 per month per IP address?!") they basically said "yup, take it or leave it." We left it.. They're still chasing us for the money that we supposedly owe them. The renumbering was hell, but we switched to UUnet. Slightly more expensive, but good service and no crazy extortion attempts! --Dan > > > I am considering using Aleron (http://www.aleron.com/network) as an > internet service provider and wondering if anyone has an opinion on > their network, service or it's support. > > You can contact me off-list if you like. > > David A. Lauer > Network Engineer > Tristar Communications > dalauer(a)tristarcorp.net > > > > >

4 4

Re: no ip forged-source-address
by Daniel Senie 01 Nov '02

01 Nov '02

At 10:44 AM 10/30/2002, variable(a)ednet.co.uk wrote: >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. BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation. > 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"). So you're suggesting the router vendors provide default configurations which the ISPs will overwrite with their current configurations anyway? Which interface would you filter on? If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user. For dialups, such filtering can and should be done, and should be automatic in the NAS boxes. But the #1 question I have to ask you is, how are you going to have any more luck enforcing ingress filtering with what you propose, than what we have in the BCP on the subject? If the government or other large buyers require network-wide ingress filtering in any supplier they buy from (something I suggested to the folks at eBay, Schwab, etc. in our phone calls after the attacks a few years ago), or if there were legal incentive, there might be a chance ISPs would find a financial motive to implement BCP 38. As it is, there's no incentive, so the path of least resistance is to do nothing.

4 4

RE: ICANN Targets DDoS Attacks
by H. Michael Smith, Jr. 01 Nov '02

01 Nov '02

Source address verification at access layer and rate limiting icmp would be fine starts. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of fingers Sent: Tuesday, October 29, 2002 1:12 AM To: nanog(a)merit.edu Subject: Re: ICANN Targets DDoS Attacks > "Meanwhile, U.S. government security officials are discussing the > possibility of creating new regulations that would require federal > agencies to buy Internet service only from ISPs that have DDoS protection > on their networks, according to people familiar with the situation. Such > a decision could place economic pressure on the other ISPs to follow suit, > thereby improving Internet security." just how would an isp stamp themselves with the "DDoS protected" rubber stamp? I'm just curious as to what the next sales person is going to request as a product/service they're going to want to charge customers for. best practices like filtering != DDoS protection imho

10 14

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

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