- Test - lists.nanog.org

Re: Important Informational Message - root.zone change
by Daniel Karrenberg 05 Nov '02

05 Nov '02

At 12:59 AM 11/5/2002, Sean Donelan wrote: >Since its been 5 years since the hints/cache boot file has changed, >it may be useful to remind people an immediate change to your >local configuration files is not required. You don't need to >slashdot internic.net tomorrow morning trying to download the file. > >As long as 1 listed IP address responds with the current list of root >servers, the server doesn't even need to be a root server itself, your >name server should figure out who are the current roots. In the 1980's >and 1990's when the hints/cache file changed regularly, some people when >years without updating it. Or only updated it when they upgraded their >name server code. > >Don't Panic. Well said! I am quite disappointed that ICANN has not included similar language in their announcement. They know better. Daniel

1 0

Important Informational Message - root.zone change
by John Crain 05 Nov '02

05 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 *****PLEASE NOTE***** This is an important Informational Message to the internet community: November 5, 2002, the IP address for J.root-servers.net will change in the authoritative NS set for "dot". The change will be reflected in zone serial # 2002110501. The new set of servers authoritative for "dot" will be: A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 This WILL require a change to your root hints file. The new file will be available via anonymous ftp from rs.internic.net:/domain/named.root as well as ftp.internic.net:/doamin/named.root starting 11/5/02 1700UTC (12pm EST/9am PST). Both the new and old j.root-servers.net IP space will provide answers in parallel for the foreseeable future. _________________________________________ John Crain Manager of Technical Operations ICANN/IANA crain(a)icann.org 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _________________________________________ -----BEGIN PGP SIGNATURE----- Version: PGP Personal Security 7.0.3 iQA/AwUBPcb/pdGxp5XUiliSEQJzewCg2sa+RFanZQ9XZa+t0Yif0zKnzhkAoMSa FVW9Q1ekZl49+X1RGPKaHqNy =FZjZ -----END PGP SIGNATURE-----

2 2

IP Address Allocations
by Gawie Marais (Home) 05 Nov '02

05 Nov '02

Hi, Is there a site on the Internet that actually has a up-to-date list of all IP subnet allocations that will show me who actually owns the IP range ? 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

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