- NZNOG - lists.nznog.org

Updated BGP monitoring
by Rob Thomas 12 Sep '02

12 Sep '02

Hi, NZNOG listfolk. [ Apologies to those of you who have received this note in other fora. ] I have updated my BGP monitoring to include ASN analysis. This includes the count of unique ASNs, the count of ASNs that originate at least one prefix, the average path length, the maximum path length, and the bogus ASNs. You will find it all here: http://www.cymru.com/BGP/index.html The bogus ASN page, complete with a colorful graph, can be found here: http://www.cymru.com/BGP/asnbogusrep.html Comments and feedback are always welcome! My thanks to those who donate peering and gear to my monitoring efforts. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); - 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: BGP Private ASes
by Ewen McNeill 11 Sep '02

11 Sep '02

Andy Linton sent me this response, which he tells me he intended for nznog as well. Below is Andy's response, and then my reply to Andy's response. Both are at least as relevant to the list as discussing Klez all day :-) Andy's response: On Wed, 11 Sep 2002, Ewen McNeill wrote: > In message <NABBJDOPDKGCDCNBNEDOCEPKFAAA.ascott(a)cisco.com>, "Arron Scott" writes: > >I get endless number of customers who want to peer with more than one ISP at > >a time, usually with the intention of resiliency at both the institutional > >and upstream provider levels. [... Want Class C, public AS, advertised > >prefix... ] > >Now ... what I was thinking is ... can we do this without the rare (and > >increasingly difficult to obtain) Public AS numbers. There are proposals to increase the size of the AS numbers from 16 to 32 bits but that soesn't solve the immediate difficulties in getting an AS number. > > I'm also in touch with clients that would like to do this -- they don't > especially care about the Class C, or Public AS, etc, but they would like > some resiliency for any disconnections from their provider or routing > issues for their provider, often because they have clients that have > that as a tick-box feature. I've heard some very interesting discussions about flap damping at the RIPE meeting this week. See http://psg.com/~randy/020910.zmao-flap.pdf. The important thing to note is that the thing that is damped is prefixes so dual homing may not give you all you hope for if flap damping is in use. > >Could we have a publically agreed on pool of Private AS numbers that > >enterprises can use to peer with service providers. The pool would > >administered by a "impartial" group (maybe WIX/APE). The AS number > >would then be stripped by both higher-order ISPs and and the IP > >address potentially unsuppressed by the ISP who owns the IP address aggregate. > > If I'm not mistaken about what you mean, this is what WIX (the route > reflectors) are trying to do. Dean Pemberton and I have been talking with Simon about trying to get WIX and APE whois servers running so that people could start registering routes and AS policy for RPSL use in NZ. Using these to allocate locally scoped private ASes for use on the WIX and APE would be a doddle. > The WIX approach seems to work, but: > - it appears some providers do not peer with the WIX route reflectors, > or do so only to advertise their routes, not to allow in extra routes > > - most providers filter "long" prefixes (and most enterprises without > public ASes tend to have only long prefixes). Certainly it's my > impression that pretty much all providers filter anything longer than > /24, and some appear to even filter /24, /23, /22, etc, meaning the > prefixes advertised by enterprises are likely to be filtered. It seems difficult to believe that the relatively small additional number of prefixes being announced by the enterprises on the WIX is significant. The total number of prefixes is around the 250 mark and many of those come from the "providers" anyway. Filtering out the few dozen prefixes that are /25 or greater would seem to have little impact on table size and the kosher ones could easily handled in a prefix-list. > So from an enterprise point of view WIX (the route reflectors) are useful > for picking up direct routes to providers POPs, but this tends to lead to > asymetric routes to/from the providers (and hence no real resiliency). So it would be nice to get the providers to use them. Some of them resist but surely this is an issue that could be driven by their respective customers. E.g. "As my provider I need you to provide a resilient efficient local mesh at WIX and APE. Perhaps I should consider moving to a provider who...." > > And it's useful for enterprise to enterprise peering (indeed one of my > clients connected to the WIX route reflectors soley for the enterprise > to enterprise peering; at the request of the other enterprise). > > The WIX route reflectors (according to the route table on a router > peering with them) appears to have about 50 systems peering with it > at present. > > But without providers willing to (a) peer with the route reflectors, and > (b) accept long prefixes (at least locally), it's probably not going to > be of general use for resiliency. > > To be of much general use providers would have to be willing to at least > accept /24 prefixes locally, even if they're part of a larger supernet > advertised by another provider. Longer prefixes would be desirable, > because otherwise anyone wanting resilency with CIDR space would need > to beg for a class-C sized CIDR chunk. See above --------------------------------------------------------------------------- And my response to Andy: In message <Pine.LNX.4.44.0209111930390.1763-100000(a)wark.lionra.net.nz>, Andy Linton writes: >On Wed, 11 Sep 2002, Ewen McNeill wrote: >> I'm also in touch with clients that would like to do this [advertise >> their blocks to multiple providers for resiliency] > >I've heard some very interesting discussions about flap damping at the >RIPE meeting this week. [...] The important thing to note is that the >thing that is damped is prefixes so dual homing may not give you all >you hope for if flap damping is in use. For both the clients I have in mind most of their benefits would be gained in about the first 5 hops or so (ie, within New Zealand), as that is the main market they're serving. So how important flap damping was to that would largely depend on how soon it was applied. >Dean Pemberton and I have been talking with Simon about trying to get WIX >and APE whois servers running so that people could start registering >routes and AS policy for RPSL use in NZ. Using these to allocate locally >scoped private ASes for use on the WIX and APE would be a doddle. This would definitely be a good thing. RPSL (from your talk at the Uniforum conference) looks like a Good Thing (tm), and a whole lot more sensible than the alternatives (yet more prefix listson nznog!). Scoped private ASes would also solve the immediate problem -- probably for Aaron too (hence my suggestion you mention this on nznog, and/or directly to Aaron). >It seems difficult to believe that the relatively small additional number >of prefixes being announced by the enterprises on the WIX is significant. WIX is worth about 300 prefixes or so on an average day, and "generally" includes the POPs of most NZ providers. For an organisation hosting a lot of content, there's definitely a win for them in sending traffic "directly" to the POPs (and bypassing the ticket counter at their ISP :-) ). If those routes were symmetric, then there'd also be a resiliency win. >The total number of prefixes is around the 250 mark and many of those come >from the "providers" anyway. Filtering out the few dozen prefixes that are >/25 or greater would seem to have little impact on table size and the >kosher ones could easily handled in a prefix-list. Last I spoke to Simon about it, he was starting to put filters in on the expected prefixes from each peer with the WIX route reflectors -- which would make it possible to have a pretty "exact" set of expected prefixes. There are 27 prefixes in WIX (right now) longer than /24. Some of them are as long as /30s, and there's a bunch of /29s. One of the clients I have in mind has a /27 CIDR block. They're starting to run out of public address space (despite using RFC1918 everywhere it can be used, and lots of NAT), and will probably try asking for more space. But even that more space is likely to be only another /28, another /27, or maybe if they're very lucky one /26. My point here is that while there might not be very many prefixes longer than /25 in WIX now, that's sort of a self-fulfilling prohpehcy, because prefixes longer than /24 (or /23, /22, /21, etc -- I haven't managed to find out what's considered "best practice" by NZ providers) are being filtered out already by lots of people. So "what's the point?". If the answer is "everyone use RPSL, and persuade people to accept all properly described RPSL lists" then I'm all for it. If the answer is "only providers get to do peering", then that's tantamount to "only people with public ASes get to do peering". And may well lead to a bunch of people chasing public ASes (and provider independant space for that matter) when they don't otherwise need them. Ewen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

8 13

Re: BGP Private ASes
by Andy Linton 11 Sep '02

11 Sep '02

On Thu, 12 Sep 2002, Ewen McNeill wrote: > In message <Pine.LNX.4.44.0209120130270.2162-100000(a)wark.lionra.net.nz>, Andy Li > nton writes: > >I meant to post to all concerned. Do you want to forward my mail and your > >response to get this rolling again? > > Done. Joe Abley seems to be suggesting that public ASes can be obtained > (at least by providers for their customers) for the purposes that Aaron > is talking about, perhaps along with provider independent space with a > long prefix. But something tells me that won't scale to everyone on > Citylink getting provider independent space and their own AS... I agree with Joe that it is possible to get a public AS and some address space for mulithoming but we'd be talking about a 50% increase in NZ's AS number assignment. (APNIC have currently allocated 89 AS numbers to NZ + some earlier allocations from the US registries and we'd need 42+ private AS replacements for Citylink alone). The policy for AS numbers is effectively described at http://www.apnic.net/docs/drafts/apnic-draft-asn-v002.txt The problem I see with say Citylink customers applying under this schema is that assigning them an AS number does nothing to reduce the size of global address tables and the number will not be used to describe diverse routes in the global routing fabric. So private AS numbers seem like the 'right thing'. Where people really do want to multihome for global connectivity there is a mechanism - see the above and for multihoming IPv4 address space see http://www.apnic.net/info/faq/multihoming_faq.html But people should note - there is a cost in dollars and renumbering effort. - 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: BGP Private ASes
by Ewen McNeill 11 Sep '02

11 Sep '02

In message <NABBJDOPDKGCDCNBNEDOCEPKFAAA.ascott(a)cisco.com>, "Arron Scott" writes: >I get endless number of customers who want to peer with more than one ISP at >a time, usually with the intention of resiliency at both the institutional >and upstream provider levels. [... Want Class C, public AS, advertised >prefix... ] >Now ... what I was thinking is ... can we do this without the rare (and >increasingly difficult to obtain) Public AS numbers. I'm also in touch with clients that would like to do this -- they don't especially care about the Class C, or Public AS, etc, but they would like some resiliency for any disconnections from their provider or routing issues for their provider, often because they have clients that have that as a tick-box feature. >Could we have a publically agreed on pool of Private AS numbers that >enterprises can use to peer with service providers. The pool would >administered by a "impartial" group (maybe WIX/APE). The AS number >would then be stripped by both higher-order ISPs and and the IP >address potentially unsuppressed by the ISP who owns the IP address aggregate. If I'm not mistaken about what you mean, this is what WIX (the route reflectors) are trying to do. Enterprises on Citylink with an appropriate connection, but without public ASes are assigned a private AS, advertise their routes to the WIX route reflectors with that private AS, and the WIX route reflectors then advertises those to all other peers. APE may also have a similar setup, but my impression is that APE is mostly bilaterial peering, and it's mostly treated as a peering point, rather than a multilateral route exchange. The WIX approach seems to work, but: - it appears some providers do not peer with the WIX route reflectors, or do so only to advertise their routes, not to allow in extra routes - most providers filter "long" prefixes (and most enterprises without public ASes tend to have only long prefixes). Certainly it's my impression that pretty much all providers filter anything longer than /24, and some appear to even filter /24, /23, /22, etc, meaning the prefixes advertised by enterprises are likely to be filtered. So from an enterprise point of view WIX (the route reflectors) are useful for picking up direct routes to providers POPs, but this tends to lead to asymetric routes to/from the providers (and hence no real resiliency). And it's useful for enterprise to enterprise peering (indeed one of my clients connected to the WIX route reflectors soley for the enterprise to enterprise peering; at the request of the other enterprise). The WIX route reflectors (according to the route table on a router peering with them) appears to have about 50 systems peering with it at present. But without providers willing to (a) peer with the route reflectors, and (b) accept long prefixes (at least locally), it's probably not going to be of general use for resiliency. To be of much general use providers would have to be willing to at least accept /24 prefixes locally, even if they're part of a larger supernet advertised by another provider. Longer prefixes would be desirable, because otherwise anyone wanting resilency with CIDR space would need to beg for a class-C sized CIDR chunk. Simon Blake (Citylink) could probably speak more about what WIX's route reflectors do, and how well it's worked (or not worked) in practice. Ewen - 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 relaying on the wane?
by Juha Saarinen 11 Sep '02

11 Sep '02

http://www.imc.org/ube-relay.html Didn't Joe Abley do a survey for NZ ages ago? -- Juha Saarinen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

BGP Private ASes
by Arron Scott 11 Sep '02

11 Sep '02

Hi all, I expect this is probably flame bait, but I keep hitting the same question in customer-land almost every week, and wondered if there were at least a different (if not necessarily smarter) way of dealing with the problem. Maybe this is already been done to some extent, and maybe we just need to formalise some of this. Anyway ... I get endless number of customers who want to peer with more than one ISP at a time, usually with the intention of resiliency at both the institutional and upstream provider levels. So what they usually want is a Public AS number and a class C which is advertised as a long prefix to the Internet via two upstreams such as Telecom GGI and TelstraClear, often with an intermediary ISP as their direct peer. Now ... what I was thinking is ... can we do this without the rare (and increasingly difficult to obtain) Public AS numbers. Could we have a publically agreed on pool of Private AS numbers that enterprises can use to peer with service providers. The pool would administered by a "impartial" group (maybe WIX/APE). The AS number would then be stripped by both higher-order ISPs and and the IP address potentially unsuppressed by the ISP who owns the IP address aggregate. One possible hiccup I see is between NZ peers, and whether there would be a problem when for instance the TelstraClear network sees the network as one AS hop direct to the customer, and one AS hop via Telecom (and vice-versa). However, on the otherside I also wondered whether this could be used on the APE and WIX for customer to customer peering, providing more rapid peering relationship growth in NZ. Any thoughts ... or have I, in my two years of vendor-land, turned into a BGP zombie who can no longer fathom the depths of BGPs arcane and sometimes infuriating nuances ? Arron Scott *********************************************************************** Arron Scott (CCIE #4099) Phone: +64-9-3551951 Systems Engineer Mobile: +64-27-4883163 Cisco New Zealand mailto:ascott(a)cisco.com http://www.cisco.com *********************************************************************** - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

RE: So cool a flash,enjoy it
by Donald Neal 10 Sep '02

10 Sep '02

> From: Chris Wedgwood [mailto:cw(a)f00f.org] > Sent: Wednesday, 11 September 2002 15:42 > On Wed, Sep 11, 2002 at 12:15:57PM +1200, Donald Neal wrote: > > > This message was bounced by teletech.co.nz on the ground that it > > contained offensive language. I felt that whoever on the list is > > using this company's mail service should know that. > > *PLEASE* tell me this is a joke and you forgot the smiley? > > > --cw No smiley, no joke. I posted this as a notice to whoever the affected person is. I'm inclined to view further discussion as not appropriate for the list. - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------ - 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: So cool a flash,enjoy it
by Donald Neal 10 Sep '02

10 Sep '02

> -----Original Message----- > From: Joe Abley [mailto:jabley(a)automagic.org] > Sent: Wednesday, 11 September 2002 12:02 [...] > The best AV solution I can think of is for all possible holes and > exploits in Microsoft mail clients to be exploited as soon as > possible, and as violently as possible. Maybe if that happens fewer > people will run stupid Microsoft mail clients, and the whole issue > will just go away. > > By making half-hearted attempts at stripping virus-infected bits > from e-mail, you're just interfering with the natural order of > things and prolonging the life of **** software. > > > Joe > - This message was bounced by teletech.co.nz on the ground that it contained offensive language. I felt that whoever on the list is using this company's mail service should know that. - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------ - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

Re: So cool a flash,enjoy it
by Ewen McNeill 10 Sep '02

10 Sep '02

In message <9146DBDC8503D411B18A204C4F4F50200A65DB(a)172-16-1-2.static-dialup.xtra.co.nz>, James Guidera writes: >>[Joe Abley says: don't strip the viruses, let the natural order prevail] > >There is no point blaming the mail client. No matter who makes the mail >client, if it is popular it will be open to attach. Be it Notes, GroupWise, >Outlook. Whoever is the biggest and most common would be the target. There is every point in blaming the mail client -- it's the "automagically do stuff" behaviour of the mail clients which makes all of these viruses spreading around possible. The "automatically run programs when clicked on" is bad enough (where programs == "anything executable", including "documents" with embedded programming languages and auto execute features); the preview bugs are even worse. There were far far fewer mail viruses in the days when you had to work rather hard to run a program sent to you by mail (eg, cut out encoded section, manually feed to uudecode or unshar it, compile the source, and run it). cat, more, less and other similar mail clients have far fewer security problems. Even telnet has fewer security problems as a mail client (although it does suffer from plain text passwords over the wire). And mail/mailx don't have that many security problems on the _reading_ side (on the sending side they're a bit of a festering pile of security holes). There might be an argument that only mail clients vulnerable to being infected will be popular (the converse of what you're suggesting) -- because they're more point'n'drool. However I'm with Joe: if you let the viruses do their thing, preferably as dramatically as possible, then the natural order will prevail eventually, as people get tired of reinstalling their machine for the third time that week (and/or confidental documents leaking and/or their clients shunning them). To bring it vaguely back on topic: mail scanners at ISPs (eg, the Xtra ones) would do need to either forward on the bones, or bounce the whole message back to the "sender" -- silently dropping things is bad, as it just hides the problem (and can hide more stuff). For messages which appear to be viruses that send their own mail (ie, spreading as worms), I'd personally go for just bouncing the whole message back. (Yes I know Klez, et al, forge the from address too, so you can't usefully bounce it -- but the recipient doesn't want it either. I'm going to get stray Klez as either "sender" or recipient whichever way you go.) Ewen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

Re: So cool a flash,enjoy it
by Simon Byrnand 10 Sep '02

10 Sep '02

At 13:40 10/09/02 +1200, simon wrote: [snip] Normally I wouldn't reply to this sort of thing on list, but I've already received about 10 replies to this message which I did *not* send. Half of them were virus scanner reports, the other half were people saying "huh?", or "who are you?". For those that didn't bother to check the headers, here are the last few: Received: from mta204-rme.xtra.co.nz (mta204-rme.xtra.co.nz [210.86.15.147]) by mailserv.waikato.ac.nz (8.11.3/8.10.2) with ESMTP id g8A1eL732069 for <nznog(a)list.waikato.ac.nz>; Tue, 10 Sep 2002 13:40:21 +1200 Received: from mta2-rme.xtra.co.nz ([210.86.15.140]) by mta204-rme.xtra.co.nz with ESMTP id <20020910014016.CDID5662.mta204-rme.xtra.co.nz(a)mta2-rme.xtra.co.nz> for <nznog(a)list.waikato.ac.nz>; Tue, 10 Sep 2002 13:40:16 +1200 Received: from Anqm ([203.96.107.54]) by mta2-rme.xtra.co.nz with SMTP id <20020910013935.DSEG19105.mta2-rme.xtra.co.nz(a)Anqm> for <nznog(a)list.waikato.ac.nz>; Tue, 10 Sep 2002 13:39:35 +1200 The message clearly comes from an Xtra user, presumably infected with a virus. Which begs an interesting question, why did Xtra's much-touted virus scanner let it through ? :) Regards, Simon Byrnand (The real one :) - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

12 32