November 2002 - Test - lists.nanog.org

Re: Where is the edge of the Internet? Re: no ip forged-source-address
by Daniel Senie 04 Nov '02

04 Nov '02

At 06:18 PM 11/4/2002, Sean Donelan wrote: >On Mon, 4 Nov 2002 bdragon(a)gweep.net wrote: > > What about the other large isps? What would it take for you to do > > something? Chris is gracious enough to show up and participate, at > > least even if it does mean he has to wear nomex. > >I'm in favor of source address filtering at the edges. > >I'm opposed to some of the suggestions where to put source address >filters, especially placing them in "non-edge" locations. No argument there. Bogon filtering could (should?) be done everywhere, but ingress is best when done close to, well, the ingress point. > E.g. requiring >address filters at US border crossings is a *bad* idea, worthy of an >official visit from the bad idea fairy. This would be a bad idea even if it were possible to clearly delineate border crossings somewhere. Many foreign ISPs collocate routers in the USA, leading to all kinds of fun questions of where borders lie in cyberspace. >Our networks, and our customer bases, are not identical. This is good >and bad. Not to make excuses, the ease with which this can technically be >done depends on your network and type of customer connections. Or more >precisely how you aggregate customer connections. Doing absolutely nothing, in any part of one's network seems unreasonable. For the large backbone providers, they might consider adding terms-of-service requirements for their downstreams, if they themselves can't implement on their equipment. UUNet was able to impose something like that with port 25 blocking, requiring their wholesale POP customers to add that to their RADIUS server configs. Even the Cisco RPF check that looks to see if there is ANY route to a net would be helpful. That would squelch out the packets with 0.0.0.0 source addresses and other such bogons. Cisco claims that's not even high overhead. Perhaps turning that on in the backbone routers would be worthwhile? >IMHO the edge is generally the best place to do source address filtering. >After traffic is aggregated its more difficult. Clearly. The question is the definition of aggregation. Is it the customer premesis router that must do the work, the aggregation router at the local ISP? The backbone vendor's aggregation router that regional ISPs attach to? > Some folks have already >identified the technical limitations of some types equipment. And with >the market, we're going to be stuck with that equipment for a while. In >hindsight, if every provider and every equipment vendor did it from day 1, >we would be in great shape. > >Does that mean I can wave my magic wand and fix everything tomorrow? No. > >Can I work on standards, vendors and purchasing agents to change this over >time? Yes. Will yelling at me make it happen faster? I doubt it, but I >know you will anyway. When I first got involved in this back in 1996, this was my answer to those who complained their routers would melt. "Add it to your requirements document for your next round of purchasing" was a common comment. If you don't tell your vendors you need a feature, they won't spend their time on it. Cisco, to their credit, has been working on this issue. Their automated solutions have shortcomings, but they seem to be working on improvements. In edge cases with single-homed customers, there's really no excuse not to have an ACL to take care of the issue. The extra few lines of config (probably script generated anyway) would not hurt. Seems some folks won't even do that.

1 0

Port 137 scans
by blitz 04 Nov '02

04 Nov '02

Seeing a ton of them mostly from South America rite now.

3 2

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

Re: ICANN Targets DDoS Attacks
by alok 04 Nov '02

04 Nov '02

is any active working group persuing this matter seriously? -rgds Alok ----- Original Message ----- From: alok <alok.dube(a)apara.com> To: <cjclark(a)alum.mit.edu>; <Valdis.Kletnieks(a)vt.edu> Sent: Saturday, November 02, 2002 4:26 AM Subject: Re: ICANN Targets DDoS Attacks >The first, dropping broadcasts destined to your customers, is possibly >doable, but not trivial. ------> IGP learnt networks .. a small tweaky bit which learns broadcast addresses via the networks in the IGP wud help (again summarization wud make it bad) >The second, catching all broadcasts coming >in, out, or just passing through, is pretty much impossible. -----> a very small percentage cud be blocked if u were willing to link this to BGP learnt networks..at least those are "complete networks", not subnetted.... ofcourse its a very small portion, mebbe u cud ask guys to send more specific BGP routes from now.... -A

4 4

Re: BGP security in practice
by alex＠yuriev.com 04 Nov '02

04 Nov '02

> I didn't say that MD5 would solve the configuration problems, but > that the fact that just mis-configuration errors can cause lots of > damage should clue people into the fact that the protocol has > vulnerabilities to deliberate attack. Every protocol is vulnerable if the principals are mis-configured (i.e. do not follow the protocol). The protocol for crossing a busy street at the light involves checking for the green light before crossing the street. A mis-configured principal checks the light, ignores red or yellow, and immediately crosses. Does it mean that the protocol is broken or does it mean that a principal is broken? Alex P.S. In this specific case I am strictly looking at "misconfiguration causes problems" implies brokenness of the protocol.

3 2

Re: ICANN Targets DDoS Attacks
by alok 04 Nov '02

04 Nov '02

Hi, { this is one "snappy" mailing list :o) }...... I meant, where can I find the people bouncing ideas on this topic.... -rgds Alok ----- Original Message ----- From: <bmanning(a)beguile.ip4.int> To: David Conrad <david.conrad(a)nominum.com> Cc: <bmanning(a)vacation.karoshi.com>; alok <alok.dube(a)apara.com>; <cjclark(a)alum.mit.edu>; <Valdis.Kletnieks(a)vt.edu>; nanog <nanog(a)merit.edu> Sent: Tuesday, November 05, 2002 5:58 AM Subject: Re: ICANN Targets DDoS Attacks ok, so i exploited the ambiguity in the original question. wrt "active" - there is a sub-group from within the RSSAC members that seems to be exchanging email on a regular basis on various response vectors to either diffuse an attack (anycast) or repel an attack (rate-limits). On Mon, Nov 04, 2002 at 09:08:44AM -0800, David Conrad wrote: > Just to be clear: > > (a) RSSAC is not an IETF working group. It is an ICANN thing and not open > to the public (last I heard) > > (b) "active" in this context must be using a definition of that term that > I'm unfamiliar with. > > Rgds, > -drc > > On 11/4/02 3:47 PM, "bmanning(a)vacation.karoshi.com" > <bmanning(a)vacation.karoshi.com> wrote: > > > > > > > yes. this is a topic of active discussion within > > the RSSAC. > > > > > >> > >> > >> is any active working group persuing this matter seriously? > >> > >> -rgds > >> Alok > >> ----- Original Message ----- > >> From: alok <alok.dube(a)apara.com> > >> To: <cjclark(a)alum.mit.edu>; <Valdis.Kletnieks(a)vt.edu> > >> Sent: Saturday, November 02, 2002 4:26 AM > >> Subject: Re: ICANN Targets DDoS Attacks > >> > >> > >> > >> > >>> The first, dropping broadcasts destined to your customers, is possibly > >>> doable, but not trivial. > >> > >> ------> IGP learnt networks .. a small tweaky bit which learns broadcast > >> addresses via the networks in the IGP wud help (again summarization wud make > >> it bad) > >> > >>> The second, catching all broadcasts coming > >>> in, out, or just passing through, is pretty much impossible. > >> > >> -----> a very small percentage cud be blocked if u were willing to link this > >> to BGP learnt networks..at least those are "complete networks", not > >> subnetted.... > >> > >> ofcourse its a very small portion, mebbe u cud ask guys to send more > >> specific BGP routes from now.... > >> > >> -A > >> > >> > >> > >> > >> > >

1 0

point-click consulting or gblx
by Scott Granados 04 Nov '02

04 Nov '02

Can someone from point-click consulting andor globalcrossing contact me off list please. Thanks Scott

1 0

Alternative in Web Hosting ?
by Gawie Marais (Home) 04 Nov '02

04 Nov '02

I know that this list would not quite cover my topic, but please excuse me... We are a small ISP company based in South Africa and I am looking at alternative ISP's in several other countries around the world to provide our clients with International hosting solutions for their customer base abroad. For the time being, I think we are looking at America & Europe. Could someone suggest alternative ISP's where we could host our client's existing web sites (as a mirror) ? Thank You, Gawie J Marais Technical Member inX - Internet eXchange SA Tel: +27 11 956 6935 Fax: +27 11 956 6851 Mail: gawie(a)inx.co.za Web: http://www.inx.co.za/

2 1

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

UUnet West Coast glitch?
by Steve Francis 03 Nov '02

03 Nov '02

We just saw RTT times to a bunch of sites (yale, ucsb, cisco, yahoo, mci) all go up to 3 second RTT with lots of loss. The one traceroute I did before it corrected itself showed long delays once traceroute entered UUnet - but could be the return path. (This was from an Internap colo site, so there is often assymetry.) I saw the same delays out of another TimeWarner connected site... Anyone else know what was going on? trace www.mci.com Translating "www.mci.com"...domain server (63.251.224.9) [OK] Type escape sequence to abort. Tracing the route to mci.com (199.249.20.30) 1 border5.fe5-3.expertcity-4.sfo.pnap.net (63.251.61.117) [AS 14743] 4 msec 0 msec 4 msec 2 core2.ge2-0-bbnet2.sfo.pnap.net (63.251.63.66) [AS 14743] 120 msec 0 msec 0 msec 3 gige4-0-233.ipcolo1.SanFrancisco1.Level3.net (63.211.143.17) [AS 3356] 4 mse c 8 msec * 4 gigabitethernet4-2.core2.SanFrancisco1.Level3.net (209.244.14.225) [AS 3356] 4 msec 4 msec * 5 100.ATM2-0.BR5.SAC1.ALTER.NET (166.90.50.134) [AS 3356] 2536 msec 2536 msec 2532 msec 6 0.so-2-1-0.XL1.SAC1.ALTER.NET (152.63.52.226) [AS 701] 2676 msec

2 1