September 2001 - NANOG - lists.nanog.org

ATM failure - No the other kind of ATM
by Sean Donelan 08 Sep '01

08 Sep '01

As most US residents are aware, the Citibank ATM/Automatic Teller Machine network failed last night. Citibank is still having problems today. >From Reuters: "The Citibank ATM network and other systems experienced a temporary outage last evening." "While our systems were restored by early Wednesday morning, we have continued to experience difficulties this morning. We're working hard to resolve the issues as quickly as possible." Since there is very little "unique" network equipment in the world now, just about everyone buys equipment from the same vendors. So the question is, Can we learn anything from Citibank's experience. Is there anything about their continuing problems which may be used to improve general network reliability? I tried to find out some information from Citibank's web site about the issue, but I didn't see anything.

9 8

IDS Software
by Leo Bicknell 08 Sep '01

08 Sep '01

I'm starting a project for which I would like some quality IDS software. IMHO this opens up a whole can of worms, and will probably start a great discussion, but that's probably good on the whole. First, the requirements. The IDS system must be: * Free * Run on FreeBSD, and/or maybe Linux. * Allow both 'router' detection (where the host acts as a router) and 'passive' (where the host is simply a sniffer on a lan). * Have a reasonable configuration system to allow common false-positives to be supressed. At this point I know almost nothing about IDS systems, other than that several companies make such products and charge huge fees for them, and that there are a number of open-source products that have no confirmed reputations. Replies to the list are ok, as are private replies. Assuming I get something good I will summarize private replies to the list. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

2 2

The Cidr Report
by CIDR Report 07 Sep '01

07 Sep '01

This is an auto-generated mail on Fri Sep 7 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 07Sep01 0) General Status Table History ------------- Date Prefixes 310801 103087 010901 103176 020901 103157 030901 103037 040901 103055 050901 103130 060901 103134 070901 103166 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11536 Number of ASes announcing only one prefix: 6868 (3907 cidr, 2961 classful) Largest number of cidr routes: 847 announced by AS701 Largest number of classful routes: 1395 announced by AS701 1) Gains by aggregating at the origin AS level --- 07Sep01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1285 971 314 24.4% Telstra Pty Ltd AS701 1395 1186 209 15.0% UUNET Technologies, Inc. AS4151 294 165 129 43.9% USDA AS577 313 192 121 38.7% Bell Advanced Communications Inc. AS6595 173 61 112 64.7% DoD Education Activity Network As AS4293 381 272 109 28.6% Cable & Wireless USA AS16473 177 74 103 58.2% Bell South AS13999 113 11 102 90.3% Mega Cable S.A. de C.V. AS705 245 146 99 40.4% UUNET Technologies, Inc. AS7018 756 660 96 12.7% AT&T AS6429 194 102 92 47.4% AT&T Chile Internet S.A. AS4755 214 127 87 40.7% Videsh Sanchar Nigam Ltd. Autonom AS12302 96 26 70 72.9% MobiFon S.A. AS724 230 162 68 29.6% DLA Systems Automation Center AS4200 142 74 68 47.9% Apex Global Information Services, AS7046 320 254 66 20.6% UUNET Technologies, Inc. AS1239 468 402 66 14.1% Sprint AS6471 127 62 65 51.2% ENTEL CHILE S.A. AS209 301 242 59 19.6% Qwest AS16758 63 6 57 90.5% IKON Office Solutions AS19632 67 11 56 83.6% Metropolis Intercom S.A. AS703 311 256 55 17.7% UUNET Technologies, Inc. AS3464 148 93 55 37.2% Alabama SuperComputer Network AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS226 145 93 52 35.9% Los Nettos AS1 543 491 52 9.6% BBN Planet AS17561 113 62 51 45.1% Internet service provision to Wes AS4323 241 194 47 19.5% Time Warner Communications, Inc. AS15290 238 192 46 19.3% AT&T Canada IES AS5536 55 10 45 81.8% Internet Egypt Network For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: Charles Sprickman [mailto:spork@inch.com] |> Sent: Thursday, September 06, 2001 9:16 PM |> On Thu, 6 Sep 2001, Roeland Meyer wrote: |> > To be honest, even though I've used NAT myself and have |> implemented NAT for |> > friends and clients, I would NEVER represent that a NAT'd |> address has the |> > full connectivity to the Internet that a static address does. |> |> True... neither does a well-firewalled LAN. There is a substantial difference between broken access and controlled access.

15 24

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
by Dickson, Brian 07 Sep '01

07 Sep '01

Leo Bicknell wrote: > On Fri, Sep 07, 2001 at 05:09:43PM -0400, Andy Dills wrote: >> One is content, the other a content-delivery mechanism. Think about the >> post office. It's perfectly acceptable for them to stamp a forwarded >> address on the envelope to ensure it's delivery, but perfectly >> unacceptable to modify the content inside. > But NAT goes further. Consider if the post office opened up your > letter, looked at the return address on it, saw that was wrong and > stuck the new one on it, put it back in the envelope and then sent > it on its way. That's exactly what NAT does with some protocols. Funny story (with a NAT analogy): The US post office will forward mail within the USA for free, but won't redirect mail to outside the USA for free. My roommate moved back to Canada. Rather than re-address (and pay) per-letter, I saved a bunch of his mail up, boxed it, and sent it via the post office. International mail generally gets inspected, which is to say, opened. The package contained a bunch of mail, with valid postmarks and addresses. Somehow, the *contents* got re-injected into the mail system. The mail returned to its original (ie old) address, thus defeating my attempt to bulk-forward it to my ex-roommate. ;-) The moral is, if I wanted my package to survive the broken forwarding mechanism, I should have re-addressed the contents, too. Or, if it absolutely, positively needs to get where you want it to go... don't mail it. (end funny story) IP is the transport layer. While many programs may let us type IP addresses at them, any protocol higher up the stack which involves or relies on IP addresses is, IMHO, badly broken. It would be just as bad to involve MAC addresses. At the very least, it defeats the whole purpose of having a *stack*. smd is correct in his observation of the overloading (network location and ID) being a problem. Generic NAT (1:1 or many:fewer, no special handling of ports or protocols)is incompatible with things that put IP addresses in the payload and expect them to match the headers. If brand X of NAT is messing with the contents, it's probably to work around this incompatibility, or rather to try and fix a broken protocol. (Leo - you are complaining about a NAT box *fixing* a problem for you! Did that occur to you?) Anything that needs to assure identity, even using local knowledge of IP addresses, should at a minimum do so by tunneling, so that the NAT affects on the encasulation, not the encapsulated header+data. (Hello, IPsec.) Or better yet, use some other identity mechansim. Fundamentally, TCP (which is the real issue) is client-server. (E.g.: Syn, syn-ack, ack.) The server must be known; who the client is arbitrary and irrelevant. (Not unlike NANOG. :-) ) It's really this simple: If you need to do non-TCP, server-server stuff, you need a static IP. It doesn't matter whether dynamic IP and port comes from NAT or DHCP - there will always be things you can't do behind those. If you want to do those things, don't go behind one of them. Or implement better protocols that don't break when NAT is used, or place ridulous burdens on ports that need to be opened on firewalls (H.323 ?!?), or better yet, use some kind of 3-way, 3-party handshake to establish peer-peer between NAT'd client-type boxes (for programs that facilitate copyright violations.) And by the way, whatever happened to the notion that the firewall should also be a proxy at the application layer rather than a mere packet-forwarding-and-munging box? Brian Dickson (now at Velocita, but speaking for himself.)

2 1

Looking for contact at HKT.net...
by Bulger, Tim 07 Sep '01

07 Sep '01

Sorry for the spam, but can anyone possibly point me in the direction of a network engineer at HKT.net that understands the concept of local preference? Thanks in advance, Tim Bulger EA.com Network Engineering

1 0

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
by smd＠clock.org 07 Sep '01

07 Sep '01

| has *any* form of identity That IP overloads "who" and "what" into one value is a fatal flaw. NAT forces the IP address to indicate topological _location_ and is therefore good. Anyone who attempts to use a locator as an identifier is wrong-headed and deserves no sympathy on the grounds of, "well our forefathers were wrongheaded too!" and other arguments of that style. Sean.

2 1

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
by smd＠clock.org 07 Sep '01

07 Sep '01

I wrote: | That IP overloads "who" and "what" *Where* and what, or who and where, is what I meant, of course. Sean.

1 0

RE: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: Jon Mansey [mailto:jon_mansey@verestar.com] |> Sent: Friday, September 07, 2001 12:44 PM |> |> At 12:31 PM -0700 9/7/01, Roeland Meyer wrote: |> >|> From: Jon Mansey [mailto:jon_mansey@verestar.com] |> >|> Sent: Friday, September 07, 2001 11:57 AM |> >|> |> >|> I seem to be able to connect to port-forwarded services behind my |> >|> office NAT firewall just fine from my laptop behind my |> >|> home NAT box. |> >|> Whats the problem? |> > |> >Can we talk ... using NetMeeting? |> |> NM, along with IPsec are examples of apps that dont play well here, |> but thats the point, they are apps that have not been written with |> the real world in mind, ie that a good proportion of the edge these |> days is behind NAT. NAT is the first and only method (I won't dignify it by calling it a protocol) that munges the data. Most real protocols only mess with the envelope and leave the data strictly alone. With NAT, its snafu. Now, if we had bi-directional transparency, via a NAT proxyd, it wouldn't hurt so bad. But, such a daemon is impossible to write and, if written, is impossible to deploy. |> Who gives in first here, the app developers (or their marketing |> depts) who decide that supporting NAT is important, or the NAT |> developers who decide they can fix cuseeme or PPTP by re-writing the |> packet data? |> |> I am also playing devil's advocate here somewhat, we all know the |> real solution to lack of IPv4 space, true end2end, and security lies |> with IPv6, right? <grin> 1) Feigned IPv4 addr shortages were ameliorated by recovery of legacy IPv4 allocations (/8s). IMHO, too late to prevent us from doing NAT. 2) Routeing table sizes are a routing architecture problem that won't go away wrt IPv6. They will only get worse there. <personal opinion> Whomever shot down IPv6 imbedded routing, needs to be taken out and shot in turn. The counter-arguments were not convincing, IMHO. I thought it was a great idea. There is nothing inherently wrong with imbedding the routing into the protocol itself and it sure helps (a bunch) to standardize things. </personal opinion>

1 0

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: Jim Shankland [mailto:jas@parker.net] |> Sent: Friday, September 07, 2001 12:35 PM |> |> Roeland Meyer <rmeyer(a)mhsc.com> writes: |> |> > You've just described a NAT proxy daemon. I've spent years |> trying to write |> > one. If you are that good, send code. Or better yet, send it to |> > www.sourceforge.org. The fundimental reason that you can't |> write one is that |> > it requires a whole other protocol that 1) deosn't exist, 2)Isn't |> > implemented, 3)Violates more than one of Dykstra's laws. |> |> Don't mean to nitpick, but I was describing no such thing. I was |> suggesting the development of a protocol. Saying that can't be done |> because the protocol "1) deosn't exist, 2)Isn't implemented" seems |> a little circular :-). Don't know which of Dijkstra's laws |> that might |> violate, either (except maybe "Don't misspell my name" :-)). I'm also dutch and should know better. However, neither can I type, as the quoted portion clearly shows. .. cna't spell, can't type, I must write code <g>. lint will save me. I'm also too terse for my own good, sometimes. Item 2 is looking forward to deployment. Adoption will be supremely difficult and unless universally adopted, it won't fly. It's a flash cut-over scenario with disparate implementors. Success is estimated at around 0.001%, in such cases. The law I am thinking of is the one where the application can't tell where the failure is until it fails. It is fundimentally unpredictable. |> The argument, roughly, is that there is a small set of operations |> (identifying an <ipaddr:port> tuple in a network-portable way, and |> dynamically allocating a new port to an application, are two |> that come |> to my mind) that make NAT and firewalls difficult for games, |> streaming |> audio/video, etc.; and that providing a standard protocol for these |> operations would make building such applications, and having them |> interoperate well with NATs and firewalls, much easier. |> |> I'm not convinced this argument is correct, though it passes the |> first-tier plausibility test in my mind. I just thought I'd float |> the trial balloon. The problem is in how to deal with the legacy. Also, most FW builders don't want to give out any clue to a potential attacker, so they silently discard the packets. In this case, how is a feedback mechanism supposed to work?

1 0