- NZNOG - lists.nznog.org

Arrgh! READ ME
by Joe Abley 26 Oct '98

26 Oct '98

Arron/Sandy, You people seem to be advertising an awful lot of crap to us over NZIX; the following is an example (209.155.82.18 is ftp.cdrom.com): ba1.acld#ping ftp.cdrom.com Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.155.82.18, timeout is 2 seconds: .!!.. Success rate is 40 percent (2/5), round-trip min/avg/max = 1108/1388/1668 ms ba1.acld#show ip route 209.155.82.18 Routing entry for 209.155.82.18/32 Known via "ospf 1", distance 110, metric 5000 Tag 9999, type extern 2, forward metric 100 Redistributing via ospf 1 Last update from 203.97.1.70 on ATM5/0.1, 1d00h ago Routing Descriptor Blocks: * 203.97.1.70, from 203.97.1.82, 1d00h ago, via ATM5/0.1 Route metric is 5000, traffic share count is 1 ba1.acld#traceroute 209.155.82.18 Type escape sequence to abort. Tracing the route to wcarchive.cdrom.com (209.155.82.18) 1 ba1-ser0-15.hmtn.clix.net.nz (203.97.1.70) 32 msec 12 msec 16 msec 2 ngthn1-b1.nzix.waikato.ac.nz (140.200.128.9) [AS 681] 136 msec 20 msec 28 msec 3 s6-1.akcr1.netgate.net.nz (202.37.245.125) [AS 4648] 36 msec 32 msec 28 msec 4 f0-0.akbr1.netgate.net.nz (202.37.245.58) [AS 4648] 2144 msec * * 5 This seems bad! Anybody else seeing this? I will be blocking OSPF updates from NetGate over NZIX very shortly... Any feedback or confirmation from anybody else would be most welcome. Joe -- Joe Abley <jabley(a)clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 3

Fw: Arrgh! READ ME
by Tony Wicks 25 Oct '98

25 Oct '98

Well, thats what you get for working at 10:30pm on a public holiday !.. hold on, so am I..... damn.... -----Original Message----- From: Joe Abley <jabley(a)clear.co.nz> To: arrons(a)netgate.net.nz <arrons(a)netgate.net.nz>; s.davidson(a)netgate.net.nz <s.davidson(a)netgate.net.nz> Cc: nznog(a)list.waikato.ac.nz <nznog(a)list.waikato.ac.nz> Date: Monday, 26 October 1998 22:43 Subject: Re: Arrgh! READ ME >Well... > >I know that I'm talking to myself here :) but it seems like I overreacted >somewhat; on closer examination, the only erroneous route I can find from >140.200.128.9 is for 209.155.82.18/32. I can't find anything else that >shouldn't be there. > >It was just the first thing I tried, and so I assumed the worst :( > >209.155/16 is definitely operated by CRL though, and so the host route >for 209.155.82.18/32 _is_ bogus. > >Many apologies for casting aspersions on NetGate's OSPF speaker! > >Yours in drugs, > > >Joe > >-- >Joe Abley <jabley(a)clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 >Network Architect, CLEAR Net http://www.clear.net.nz/ > >--------- >To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz >where the body of your message reads: >unsubscribe nznog > --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: ?
by Michael Newbery 22 Oct '98

22 Oct '98

Seems good to me. Is item 2 there explicitly to provide for the "it's Friday, let's go to the pub" postings? -- Michael Newbery Technology Manager Saturn Communications Tel: +64-4-915 5102 Mobile:021-642 957 Fax:+64-4-939 5100 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

None
by Donald Neal 21 Oct '98

21 Oct '98

NZNOG Subscribers, Below is a suggested Acceptable Use Policy, based on the one for the North American Network Operators' Group mailing list which I posted last week. I believe it accurately reflects the use of this list, but I'd like to hear any comments on it. Donald Neal NZNOG list owner/administrator/muggins ---------- Proposed Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1.Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 3.Postings to multiple mailing lists are discouraged. 4.Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 5.Blatant product or service marketing is unacceptable. 6.Postings of political, philosophical, and legal nature are discouraged. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: NZGATE addressing within NZ
by Robert Gray 21 Oct '98

21 Oct '98

>This is only one possible solution. This document is DRAFT. This document >does not attempt to define policy; it is merely intended to provoke some >useful discussion. I'd like to propose something of a variation to Joe's 'One Possible Solution' to the addressing issues. This is based on a little research and a selective interpretation of the following references: http://www.ripe.net/docs/ripe-160.html <http://www.ripe.net/docs/ripe-160.html> Ripe-160: Guidelines for Setting up a Local Internet Registry at the RIPE NCC [and if you don't think this is relevant take a peek at http://www.ripe.net/lir/registries/indices/NZ.html <http://www.ripe.net/lir/registries/indices/NZ.html> ] http://ftp.apnic.net/apnic/archive/apnic-001.txt <http://ftp.apnic.net/apnic/archive/apnic-001.txt> ' Local IR's are of three types: 'Service Provider', 'Enterprise' and 'National'. An Internet service provider (ISP) is an organisation that supplies Internet connectivity to its customers or users. An ISP can become a local IR by agreeing to certain conditions (see APNIC-011). A 'National' local IR's handle all requests from organisations that have no connection to the Internet at present or planned. In addition, National IRs may also delegate addresses to ISPs within a national context. 'National' IR's are often run by a consortium of ISP's as a voluntary and neutral service to the community.....' http://ftp.apnic.net/apnic/archive/apnic-011.txt <http://ftp.apnic.net/apnic/archive/apnic-011.txt> 'With respect to IP address 'ownership', service providers have the option of treating the sub-delegation of networks to customers as permanent or, if explicitly specified in the service provider's contractual agreement, temporary. It must be stressed that without a contractual agreement stating otherwise, assignment of networks to end users is always considered permanent (e.g., the 'ownership' of the network is transferred to the client).' The essence of the proposed variation is that instead of APNIC, a 'National' IR would be established in NZ (run by a consortium of ISP's as a voluntary and neutral service to the community). This 'National' IR to take over management of the NZGATE space for use as PI space for those who need it. This would not preclude any organisation obtaining space elsewhere. Clearly taking over the NZGATE space would require consent and co-operation from APNIC but with a broad based approach from NZ ISP's surely this would be possible? The following suggested changes to Joe's document are not intended to be complete and are also in draft form only. This is to give a general flavour, provide a basis for discussion and goes something like this: >2.3. Administrative control of NZGATE blocks returned to APNIC >All NZGATE-derived subnets not in use at the agreed time should be >returned to APNIC for administration. No further delegations from the >NZGATE blocks should be permitted by any NZ provider. All NZGATE-derived subnets not in use at the agreed time should be passed to the 'National' IR for administration. No further delegations from the NZGATE blocks should be permitted by any NZ provider. >2.4. Forced renumbering >No end-user network using NZGATE subnets should be obliged to renumber as >part of the normal course of their operation (but see [2.5] and [2.6]). No end-user network using PI (NZGATE) subnets should be obliged to renumber as part of the normal course of their operation (but see [2.5] and [2.6]) however an annual charge may be levied by the 'National' IR. [to act as a disincentive to retaining unused addresses and help cover costs]. >2.5. Process for extending address space delegations >Any end-user network which needs additional addresses due to growth should >be obliged to renumber with provider-based addressing in order to obtain >their larger address range. The released NZGATE addresses will be returned >to APNIC by the ISP. Any end-user network which needs additional addresses due to growth should be obliged to renumber with provider-based addressing (PA) in order to obtain their larger address range. The released PI addresses will be returned to the 'National' IR by the ISP. Any provider network which needs additional addresses due to growth should be obliged to renumber to an alternative PI range provided by the 'National' IR if a contiguous allocation cannot be provided to obtain their larger address range. >2.6. Process for managing ISP-hopping by end-user networks >Any end-user network that uses NZGATE numbers and decides to change ISPs >must renumber using provider-based addressing provided by the new ISP. The >released NZGATE addresses will be returned to APNIC by the former ISP. Any end-user network that uses PI (NZGATE) numbers and decides to change ISPs must renumber using provider-based addressing provided by the new ISP. The released PI addresses will be returned to the 'National' IR by the former ISP. >2.7. Process for managing ISP-hopping by national providers >Any national provider that uses NZGATE numbers and decides to change >global transit providers must renumber its own infrastructure using >provider-based addressing provided by the new global transit provider. >Customers of the national provider who use NZGATE numbers will not be >required to renumber (but see [2.5], [2.6]). Any national provider that uses PI (NZGATE) numbers and decides to change global transit providers will not be required to renumber (but see [2.5], [2.6]). I have retained the terms 'end user' 'national provider' and 'global transit providers' assuming I know what they mean but I think some form of definition would be in order. Constructive comments (and other responses) to the list please. Robert Gray Clearview Communications, Auckland New Zealand bobg(a)clearview.co.nz <mailto:bobg(a)clearfield.co.nz> http://www.clearview.co.nz/ <http://www.clearview.co.nz/> Phone DDI +64 9 529 5704, Fax +64 9 529 5702, Mob +64 25 971 860 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: NZGATE addressing within NZ
by craig＠laptop.iprolink.co.nz 21 Oct '98

21 Oct '98

Hi. > It would be useful to know what size blocks the major US backbone > providers see as viable entries. Currently they will accept a /24 but > I've seen numbers like /18 or /19 bandied around in the past as the size > of blocks that will be routable on the backbone for the forseeable > future. (I recall Sprint for example saying that they would support > blocks of this size.) Well Sprint only accepts /24 in historical ranges (to which the NZGATE addresses belong). Current practice seems to be to filter at the minimum allocation size for the /8's. For all new and assignments in the recent past this seems to be /19 (from all registries), for older addresses this was /24. Because of the dramatic slowdown in router table growth, there doesn't seem to be any forseeable technical reason to have to alter current practice. Should growth threaten to become unmanagable, increasing the minimum allocation size to /18 or /17 could slow growth, without having to attempt to retroactively assume a new minimum allocation size. It's difficult to retroactively try to filter out routes shorter than the minimum allocation size at the time they were issued as this results in cutting onself off from too much of the Internet. And so for commercial reasons this has not happened (except perhaps briefly) and cannot be reasonably expected to happen. I cannot find information at APNIC for what they consider to be the minimum allocation sizes for 202/8 nor 203/8 -- something we should find out and (attempt to) correct if desirable/necessary. -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

Re: NZGATE addressing within NZ
by craig＠laptop.iprolink.co.nz 20 Oct '98

20 Oct '98

Hi. > Just because network addresses could be considered portable a few years ago > doesn't make it so forever - the network is changing, and best current > practices change with it. True, but if you look at best current practice, that does not including route filtering more strictly than the minimum allocation size (i believe it was tried and rejected :-), and it does not involve restrictions on portability. It's easy to argue that within the NZGATE addresses the minimum allocation size is /24. There is also a very serious danger with trying to force this non-portability aspect. It reeks of commercial and not technical motives. It looks like a way to lock up customers by making it difficult to change providers. And without a serious technical reason (like if we don't do it, no one will be able to use the Internet), it is. If i didn't know Joe better, i would have suspected this was part of the reasoning. Nevertheless, one has to look as well as be very clean on any proposal in this area -- looking or behaving like a cartel will cause serious problems. I believe we can accomplish the basic goals with different rules, rules that are fair, fit existing practices, and have little potential commercial motive. How about we use: You can't move unless the entire block allocated by Waikato was allocated to you (or else you renumber). This allows ISPs to move about freely as suggested, some companies will also be able to move, but not those who obtained their IP addresses from an ISP. This will help prevent much further fragmentation, will help prevent overlapping advertisements, and helps clarify "ownership". It would seem prudent for us to at least look at the current allocations and estimate the amount of address space assigned to ISPs and to end users. I suspect there is only a small percentage of end user blocks. And if this is the case there would be very little practical difference between this and the draft's rules. -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

5 10

Re: NZGATE addressing within NZ
by craig＠laptop.iprolink.co.nz 18 Oct '98

18 Oct '98

Hi. > I took another look at this data and I see some differences. I see a lot too :-( Turns out my program for doing joins on CIDR blocks had a bug and that the inetnum's in the APNIC database couldn't always be rewritten as a single CIDR block (e.g. 202.36.149.0-202.36.153.255) which i had assumed... However, i guess after the beers on Friday this is no longer needed :-) -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

mail storm via 203.98.24.1
by Joe Abley 17 Oct '98

17 Oct '98

Hi, Someone is using 203.98.24.1 (pcombo.co.nz) to relay mail to the CLEAR Net MX hosts. Since 00:16:57 this morning there have been several hundreds of thousands of attempts to deliver mail to CLEAR Net, which have been blocked at CLEAR Net since the senders' domain is not real. Oct 17 00:16:57 fep4 sendmail[25135]: Ruleset check_mail (<hacka(a)udie.com>) rejection: 451 <hacka(a)udie.com>... Sender domain (udie.com) not found in DNS, or not compliant with section 6 of RFC822 Oct 17 00:16:57 fep4 sendmail[25135]: AAA25135: from=<hacka(a)udie.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=pcombo.co.nz [203.98.24.1] Oct 17 00:16:57 fep3 sendmail[1621]: Ruleset check_mail (<hacka(a)udie.com>) rejection: 451 <hacka(a)udie.com>... Sender domain (udie.com) not found in DNS, or not compliant with section 6 of RFC822 Oct 17 00:16:57 fep3 sendmail[1621]: AAA01621: from=<hacka(a)udie.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=pcombo.co.nz [203.98.24.1] The offending relay is reached from CLEAR via Xtra and onthenet: traceroute to 203.98.24.1 (203.98.24.1), 30 hops max, 40 byte packets 1 router (203.97.2.225) 3.125 ms 2.839 ms 2.940 ms 2 d1.test.clear.net.nz (203.167.224.30) 26.798 ms 27.121 ms 26.944 ms 3 ba1-atm1-0-1.acld.clix.net.nz (203.167.224.1) 27.307 ms ba2-atm1-0-1.acld.clix.net.nz (203.167.224.2) 27.199 ms 27.307 ms 4 ba1-ser0-15.hmtn.clix.net.nz (203.97.1.70) 37.072 ms s3-0.akcr1.netgate.net.nz (202.37.245.33) 30.615 ms 29.995 ms 5 xtra.akcr1.netgate.net.nz (202.37.245.46) 29.765 ms ngthn1-b1.nzix.waikato.ac.nz (140.200.128.9) 34.387 ms 36.746 ms 6 192.168.200.241 (192.168.200.241) 35.184 ms 35.428 ms s6-1.akcr1.netgate.net.nz (202.37.245.125) 42.860 ms 7 xtra.akcr1.netgate.net.nz (202.37.245.46) 38.670 ms 34.878 ms 53.744 ms 8 192.168.30.18 (192.168.30.18) 65.403 ms 192.168.200.241 (192.168.200.241) 42.500 ms 192.168.30.18 (192.168.30.18) 100.988 ms 9 otn2.gw.onthenet.co.nz (210.55.215.247) 48.387 ms 72.757 ms pcombo.co.nz (203.98.24.1) 131.373 ms I have just checked 203.98.24.1 from tardis.patho.gen.nz, and it is indeed a promiscuous relay: tardis[5]% telnet pcombo.co.nz 25 Trying 203.98.24.1... Connected to pcombo.co.nz. Escape character is '^]'. 220 pcombo.co.nz ESMTP Sendmail 8.8.7/8.8.5; Sat, 17 Oct 1998 10:01:33 +1245 HELO blah 250 pcombo.co.nz Hello tardis.patho.gen.nz [203.97.2.226], pleased to meet you MAIL FROM:<moo(a)cow.dog.horse> 250 <moo(a)cow.dog.horse>... Sender ok RCPT TO:<jabley(a)patho.gen.nz> 250 <jabley(a)patho.gen.nz>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: moo(a)cow.dog.horse To: jabley(a)patho.gen.nz Subject: oh no This is an open relay . 250 KAA19201 Message accepted for delivery QUIT 221 pcombo.co.nz closing connection Connection closed by foreign host. which resulted in the following delivery attempt to tardis: Oct 17 10:05:58 tardis sendmail[21233]: KAA21233: ruleset=check_mail, arg1=<moo(a)cow.dog.horse>, relay=root(a)pcombo.co.nz [203.98.24.1], reject=501 <moo(a)cow.dog.horse>... Sender domain must exist Until it is evident that these antics have stopped, we have applied packet filters to refuse connections from 203.98.24.1 on tcp/25. We would be grateful if appropriate people at Xtra and/or onthenet could take similar action or otherwise arrange for this to stop. Joe -- Joe Abley <jabley(a)patho.gen.nz> --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 1

Re: mail storm via 203.98.24.1
by Norman Burgess 17 Oct '98

17 Oct '98

Well, it was early morning Saturday that I discovered this was happening .. it is on the go again right now! Take some action please. Regards Norman Burgess ---------- > From: Joe Abley <jabley(a)patho.gen.nz> > To: soa(a)xtra.co.nz; abuse(a)xtra.co.nz; postmaster(a)xtra.co.nz; info(a)onthenet.co.nz; soa(a)onthenet.co.nz > Cc: nburgess(a)clear.net.nz; bob(a)wonderland.org.nz; olof(a)clear.net.nz; nznog(a)list.waikato.ac.nz > Subject: mail storm via 203.98.24.1 > Date: Saturday, 17 October 1998 10:23 > > Hi, > > Someone is using 203.98.24.1 (pcombo.co.nz) to relay mail to the CLEAR Net > MX hosts. Since 00:16:57 this morning there have been several hundreds of > thousands of attempts to deliver mail to CLEAR Net, which have been blocked > at CLEAR Net since the senders' domain is not real. > > Oct 17 00:16:57 fep4 sendmail[25135]: Ruleset check_mail (<hacka(a)udie.com>) > rejection: 451 <hacka(a)udie.com>... Sender domain (udie.com) not found in DNS, > or not compliant with section 6 of RFC822 > > Oct 17 00:16:57 fep4 sendmail[25135]: AAA25135: from=<hacka(a)udie.com>, > size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=pcombo.co.nz > [203.98.24.1] > > Oct 17 00:16:57 fep3 sendmail[1621]: Ruleset check_mail (<hacka(a)udie.com>) > rejection: 451 <hacka(a)udie.com>... Sender domain (udie.com) not found in DNS, > or not compliant with section 6 of RFC822 > > Oct 17 00:16:57 fep3 sendmail[1621]: AAA01621: from=<hacka(a)udie.com>, size=0, > class=0, pri=0, nrcpts=0, proto=ESMTP, relay=pcombo.co.nz [203.98.24.1] > > The offending relay is reached from CLEAR via Xtra and onthenet: > > traceroute to 203.98.24.1 (203.98.24.1), 30 hops max, 40 byte packets > 1 router (203.97.2.225) 3.125 ms 2.839 ms 2.940 ms > 2 d1.test.clear.net.nz (203.167.224.30) 26.798 ms 27.121 ms 26.944 ms > 3 ba1-atm1-0-1.acld.clix.net.nz (203.167.224.1) 27.307 ms ba2-atm1-0-1.acld.clix.net.nz (203.167.224.2) 27.199 ms 27.307 ms > 4 ba1-ser0-15.hmtn.clix.net.nz (203.97.1.70) 37.072 ms s3-0.akcr1.netgate.net.nz (202.37.245.33) 30.615 ms 29.995 ms > 5 xtra.akcr1.netgate.net.nz (202.37.245.46) 29.765 ms ngthn1-b1.nzix.waikato.ac.nz (140.200.128.9) 34.387 ms 36.746 ms > 6 192.168.200.241 (192.168.200.241) 35.184 ms 35.428 ms s6-1.akcr1.netgate.net.nz (202.37.245.125) 42.860 ms > 7 xtra.akcr1.netgate.net.nz (202.37.245.46) 38.670 ms 34.878 ms 53.744 ms > 8 192.168.30.18 (192.168.30.18) 65.403 ms 192.168.200.241 (192.168.200.241) 42.500 ms 192.168.30.18 (192.168.30.18) 100.988 ms > 9 otn2.gw.onthenet.co.nz (210.55.215.247) 48.387 ms 72.757 ms pcombo.co.nz (203.98.24.1) 131.373 ms > > I have just checked 203.98.24.1 from tardis.patho.gen.nz, and it is indeed > a promiscuous relay: > > tardis[5]% telnet pcombo.co.nz 25 > Trying 203.98.24.1... > Connected to pcombo.co.nz. > Escape character is '^]'. > 220 pcombo.co.nz ESMTP Sendmail 8.8.7/8.8.5; Sat, 17 Oct 1998 10:01:33 +1245 > HELO blah > 250 pcombo.co.nz Hello tardis.patho.gen.nz [203.97.2.226], pleased to meet you > MAIL FROM:<moo(a)cow.dog.horse> > 250 <moo(a)cow.dog.horse>... Sender ok > RCPT TO:<jabley(a)patho.gen.nz> > 250 <jabley(a)patho.gen.nz>... Recipient ok > DATA > 354 Enter mail, end with "." on a line by itself > From: moo(a)cow.dog.horse > To: jabley(a)patho.gen.nz > Subject: oh no > > This is an open relay > . > 250 KAA19201 Message accepted for delivery > QUIT > 221 pcombo.co.nz closing connection > Connection closed by foreign host. > > which resulted in the following delivery attempt to tardis: > > Oct 17 10:05:58 tardis sendmail[21233]: KAA21233: ruleset=check_mail, > arg1=<moo(a)cow.dog.horse>, relay=root(a)pcombo.co.nz [203.98.24.1], reject=501 > <moo(a)cow.dog.horse>... Sender domain must exist > > Until it is evident that these antics have stopped, we have applied packet > filters to refuse connections from 203.98.24.1 on tcp/25. > > We would be grateful if appropriate people at Xtra and/or onthenet could > take similar action or otherwise arrange for this to stop. > > > Joe > > -- > Joe Abley <jabley(a)patho.gen.nz> --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0