- NANOG - lists.nanog.org

Re: Network Security Requirements draft
by George Jones 03 Jul '02

03 Jul '02

"sd" == Sean Donelan <sean(a)donelan.com> writes: sd> On 18 Jun 2002, George Jones wrote: >> We (UUNET) have an internal document that we've been using for a few >> years as the basis for tests of security features of equipment to be >> connected to our backbone. We're interested in making it public so >> that it can be improved and so that others can use it. You can view >> the current draft at: sd> Its a nice draft. One issue, not with the draft, but in general on sd> network security is the lack of a transit network security architecture sd> description. The issue of how to deal with IP source routing in this sd> draft is what reminded me of this. sd> Most network security architectures are based on the internal, perimeter, sd> external network model. Bad traffic is blocked by the permiter network sd> and never allowed to pass into the internal network. But in a public sd> service provider network traffic is separated along the data, control, sd> management model. Maintaining the separation between data, control and sd> management under all conditions is the challenge. Right. Thanks. That helps clarify the actual requirement. I was headed there > 2.1.2 Enforce Use Of Management Interfaces > > Requirement It MUST be possible to configure the device such that all > management may only be done via specific management interfaces. This > requirement SHALL NOT be satisfied using a filtering mechanism on > non-management interfaces alone, since filters do not guarantee > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > separation of management and non-management traffic > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ but had not formulated it that cleanly. The actual requirement is separation of data flow and management. OOB is just one way of achieving that (that we happen to use). I'll think it over and reword. sd> Rather than disabling IP Source Route as a global setting, I think you sd> want to scrutinize traffic passing between data and control or management sd> layers. Such as to a routing process or management interface. A source sd> routed packet in the data layer just takes an unusual path through the sd> network, but becomes a security risk if it hops into the control or sd> management layer. It would be nice to enable/block source routing (and sd> strip other IP options) on a per interface basis and drop packets with sd> unexpected options at any control or management interface. I think the general requirement here is ability to accept/reject options per/interface. Once that's in place people can decide for themselves if they want source routing (or other options). I will work on rewording. Since I announced the document here, I've added: 2.3.4 Ability To Control Service Bindings Requirement The device MUST provide a means that allows the user to specify the bindings used for all listening services. It MUST support binding to a list of net-blocks and SHOULD support configuration of binding services to particular interfaces. Justification This greatly reduces the need for complex filters. It reduces the number of ports listening, and thus the number of potential avenues of attack. It insures that only traffic arriving from legitimate addresses and/or on designated interfaces can access services on the device. Implementation The default configuration as displayed by Display All Configuration Settings should list all interfaces and all potential services along with the ports they listen to, the addresses they listen to and the interfaces they bind to. These should all be made configurable. Warnings None This would allow, for instance, SSH to be bound *only* to a loopback interface. Combine this with the ability to disable options and do filtering the loopback and I think we're getting close to an acceptable way to do device management, even in-band. Thanks, -- George M. Jones | Most important ideas are uninteresting. Most interesting CISSP,CCNA,JAPH | ideas are unimportant. Not every problem has a good UUNET | solutions. Every solution have side effects. Network Security | Quoted from Dan Geer george(a)uu.net, 2002 PGP = AB33 0916 F91E E58C B023 C768 351C 57E5 271E 69DC

1 0

Re: European packet loss average increasing
by Michael.Dillon＠radianz.com 03 Jul '02

03 Jul '02

>My non-scientific measurements (i.e. pings to well known european >sites) show an increase in packet loss to about 6%, the 10 day >average previously was less than 1%. That is similar to what the Internet Traffic Report for Europe shows at this URL http://www.internettrafficreport.com/cgi-bin/tr_graphpage.pl?score/7/Europe For those who don't know, Ebone had a policy of zero packet loss on the network 99.5% of the time and we managed to exceed this on almost all of our links. In other words, the graph of packet loss was a horizontal line with the occasional small blip. The major change in the traffic report graphs is that packet loss is six times greater after the Ebone shutdown. There was also a dip in traffic levels that partially corrected itself. Presumably the bottom of the dip represents convergence and the lack of a full recovery is partly due to organizations that were not multihomed and who had not yet found alternate providers. --Michael Dillon ex-Ebone

2 1

Re: Sprint peering policy
by George William Herbert 03 Jul '02

03 Jul '02

Perhaps we need NANOG-OldFarts mailing list? >> I think this is putting the cart before the horse. >> >> We were getting upgraded bandwidth capabilities, >> fiber put in the ground, etc from traditional Telcos >> prior to the rise of the Internet; they were finding cheaper >> ways to run phone service around. > >This is totally incorrect. Ask anyone who had been in this business from the >beginning of nineties, not late nineties. How about people who were in the business or doing engineering on WANs in the late 80s? >Telcos, while upgrading their >systems, happily pointed at the PUC filings and sold you DS1 that went two >blocks for $700 per month, that being inside a city. The local loop situation was, and in many cases remains, a major problem point; at one point, the ISP I was with was paying more for the last mile from C&W facilities in each city to our POPs than for the long haul T-1 lines forming the nationwide backbone. We dropped our total telco costs by about 10% by locating our main NOC in a building housing C&W and AT&T Longlines facilities and calling in a contractor with a concrete drill to run conduit up through our ceiling into the AT&T and C&W machine rooms... All of that said, the long distance lines were already negotiable, and getting very rapidly more so, in 1991 and 1992. >> The rise of the Internet as a telecom bandwidth demand >> driver attracted the attention of investment bankers >> and capital, which then became somewhat of a set of >> complex feedback loops (capital going into all sorts >> of internet industries, infrastructure, etc, partly >> because it appeared to be good business and partly >> because of hype). The result was that speculation >> and hype drove overcapacity. > >This again is incorrect. The rise of content attracted investment bankers. Oh? And here I am wondering why the fiber plant growth started its serious upswing in the late 80s, prior to the invention of HTTP/HTML. >> Before anyone had invested serious money in any of >> the internet infrastructure companies, people were >> building out 10 megabit, T3 backbones and were talking >> to telco gear providers about what it would take to >> do 155 megabit and 622 megabit backbones and so on >> and so on. > >This is again incorrect. The people that you are talking about were UUNET >and MCI, and we are talking 1994. That's years too late. UUNet had some 10 megabit WAN links while I was still in college, using those crazy 10meg-ethernet-into-SONNET custom hardware boxes if I remember right. T3 lines were technically available and priced by 1990; nobody had the money or customer demand to justify getting them. They were being used by telcos to upgrade their POTS services, but people were already asking what we could do with them with pure stream IP data, and looking at the OC-3 and OC-12 protocols as they developed, though that was mostly driven by LAN rather than WAN. >> It was clear to those of us in the late >> 80s and early 90s that if demand kept pulling, we needed >> to keep creating bandwidth. > >There had not been demand in 80. Neither had there been demand in the >beginning of 1990s. Strange. When I started using the Internet, *the* T-1 backbone wasn't all done yet. I got a bad name a couple of times by pulling X11 releases down from MIT at times of day that it caused noticable delay in the rest of the country's coast-to-coast IP traffic. By the time I graduated college, there were three backbones, and T-1 was no longer the hottest WAN technology in use. The demand growth curve goes back a long, long ways, Alex. >> But in no way can you claim that it took a terabuck >> in capital push to make it happen. Demand pull was >> fully operational and working just fine before >> ISPs started being snapped up by phone companies >> and visa versa, and the huge money came into play. > >Yes I can. It did take terrabucks to get this industry rolling. You are mistaking terrabucks invested in capacity push as opposed to responding to demand pull. Demand pull is fine; when there's demand, if the cost model works out, you invest to support it. Capacity push is speculation on a growth curve. We didn't need that, though everyone who likes dark fiber now is acting like a kid in a candy shop since a terabuck or so was wasted on overprovisioning it... >> Hype might have been lower and growth somewhat >> slower, but I can easily see the set of people >> who were building out backbones with T-1s and >> the early fiber links having grown them up to >> networks capable of today's traffic. > >Are you talking about Net99 here? I can't even remember what year Net99 kicked off... Must have been what, 1994? I was chatting with Joe Stroup by cellphone from my inlaws place during their pre-launch nationwide tour, and the inlaws moved in there in 1994. Yes... Cook report 3.07 summary, Sept/Oct 94, seems to confirm that timing. Announced late 94, rolled out early 95. [Side note: Gordon, for historical purposes, would it be unreasonable if we asked you to make the full reports freely available if they're older than say 5 years? 3 years? Or are you still making money off the archaic gathering dust ones ... 8-) ] 1995 is not going back nearly far enough. I'm talking about pre-CIX (remember that?). Pre-NAPs. Pre-any-telcos-routing-IP. Man, 1992-4 were busy years, though. -george william herbert gherbert(a)retro.com

2 1

Re: Sprint peering policy
by Vijay Gill 02 Jul '02

02 Jul '02

Mike Leber <mleber(a)he.net> writes: > Sprint's peers aren't equal to Sprint or each other when considered by > revenue, profitability, number of customers, or geographical coverage. A good proxy for the above is to ask the question: Do X and Y feel they derive equal value (for some value of equal) by interconnecting with each other? If they think they do, then an interconnection is set up between X and Y. However, if one party feels that they do NOT derive equal value by interconnecting with the other, than that party usually balks. X states that they would only feel equal value is derived by both parties if traffic between X and the other party is n mb/s with a ratio of p:q. Y disagrees. They do not interconnect. This causes pain. Usually the pain for one party is greater than the pain for the other, unless they are really peers of each other, in which case settlement free interconnections happen. However, if there isn't equal amounts of pain being felt on both sides, then normally the party with the more hurt tries to redress the issue. Usually this imbalance in perceived value is redressed by one of the parties offering to make up the difference by some form of a transfer of money. > This is ridiculous elitism. see above. > to make sense of their peering policy, just accept the fact that each > company has policies that they believe to be in their best interests and > omit the pretense of justifying this by the movement of heavenly bodies in > the spheres. I think we are in agreement here. /vijay

20 36

Determining the ingress interfaces
by Rajesh Talpade 02 Jul '02

02 Jul '02

Hi I asked the following question here a few weeks back, and got suggestions to use "traceroute -g," traffic filters, and assume bi-directional paths are same. How do we determine the appropriate peer AS, and hence ingress interface(s) at an ISP's border routers, for traffic arriving _from_ IP address blocks not allocated to the ISP, and destined _to_ specific IP address(es) within the ISP's network ? In other words, how do we create a mapping between non-ISP-owned address blocks and the ISP's peer ASs, such that given a non-ISP-owned address block, we can determine the peer AS thru which traffic from the address block enters the ISP's network? So do you BGP-gurus think that the following approach answers the question? I would greatly appreciate your feedback. Approach: Use data from BGP tables of as many ASs as possible. One candidate that can provide such data is the routeviews project at Univ of Oregon run by Dave Meyer. The routeviews server maintains eBGP sessions with about 63 BGP speakers, and dumps "sh ip bgp" every 2 hours. Filter out all entries from latest routeviews data with destination IP address(es) that we care about listed as "Network." May need to include larger address blocks belonging to ISP as well, since destination IP address(es) may have been aggregated into them by some ASs. For each address block filtered above, determine all ASs that are peers with the ISP's AS. This can done by creating a set of all ASs that appear immediately to left of ISP's AS for each path listed to address block, making sure there are no repetitions of ASs in the set. For each peer AS, create many-to-one mapping from source ASs to peer AS. (source ASs are all ASs on each AS path, except peer AS and ISP's AS; check that no source AS maps to multiple peer AS). Associate IP address blocks with each source AS (partly using routeviews data, partly thru ARIN d/b, etc), thus creating mapping from non-ISP-owned IP address blocks to peer ASs. Use network topology info for ISP's network to determine mapping between peer AS and ingress interface(s). Example usage of approach: Determine mapping of source ASs to peer ASs for destination IP address 4.2.101.20 on Genuity's network. (Genuity only used as an example here) Relevant data from routeviews oix-full-snapshot-2002-06-23-1000.dat in "sh ip bgp" format: Network Next Hop Path * 4.0.0.0 193.0.0.56 3333 9057 3356 1 i .... (some lines deleted) * 217.75.96.60 16150 8434 286 1 1 .... (some lines deleted) * 141.142.12.1 1224 38 10514 3356 1 i .... (some lines deleted) * 4.2.101.0/24 141.142.12.1 1224 38 6325 1 i * 202.249.2.86 7500 2497 1 i * 203.194.0.5 9942 1 i * 66.203.205.62 852 1 i * 167.142.3.6 5056 1 e * 206.220.240.95 10764 1 i * 157.130.182.254 19092 1 i * 203.62.252.26 1221 4637 1 i * 202.232.1.91 2497 1 i *> 4.0.4.90 1 i Destination IP address: 4.2.101.20 Destination AS: 1 Relevant IP address blocks: 4.0.0.0, 4.2.101.0/24 Peer ASs: 3356, 286, 6325, 2497, 9942, 852, 5056, 10764, 19092, 1221, 2497 Source ASs: 3333, 9057, 16150, 8434, 1224, 38, 10514, 7500, 1221 Mapping from source ASs to peer ASs: Peer AS Source AS 3356 3333, 9057, 10514 286 16150, 8434 6325 1224, 38 2497 7500 4637 1221 The approach is based on the observation that each AS only advertises to its peers the "best" route it knows to a specific destination network. So given an AS path to a destination network in the routeviews data, the "best" path that traffic from each of the source ASs on the path would take to the destination network can be determined. e.g. * 4.0.0.0 141.142.12.1 0 1224 38 10514 3356 1 i The "best" path for local traffic of 1224 to 4.0.0.0 is 38-10514-3356-1; "best" path for local traffic of 38 is 10514-3356-1; "best" path for local traffic of 10514 is 3356-1; Hence the peer AS to use for getting to destination network can be determined for local and transit traffic of each source AS. (Is this true?) The effectiveness of the approach is dependent on the number of views captured in the "sh IP bgp" data. i.e. the more paths that are listed for a destination network, the more mappings from source ASs to peer ASs can be determined. Thanks. Rajesh.

1 0

RE: AOL mail netblocks
by Martin Hannigan 02 Jul '02

02 Jul '02

On Tue, 2 Jul 2002 jlewis(a)lewis.org wrote: > On Tue, 2 Jul 2002, Martin Hannigan wrote: > > > I was hoping someone was going to say that "AOL already does this > > themselves". In the 'old' days, there was a list of what to allow > > under .ipt.aol.com. It's pretty easy for them to do it, and I'm > > guessing that they do actually filter this outbound, or their > > managed modem providers may, I'm just looking for a confirmation. > > I don't think they do filter outbound SMTP. I've gotten complaints from > AOL dial-up users that AOL does not filter outbound SMTP, and that they > don't provide outgoig SMTP servers (hard to believe), so we should not > block AOL dial-up addresses, because these people have to run their own > SMTP servers. My thought/feeling on this is "BS and apathy". The vast > vast majority of AOL dial-ups have no business doing direct-to-MX email. > The handful that think they do can find workarounds or a more appropriate > provider. Ok then, is there a place where I can bath myself in AOL dialup identified netblocks? I'm not trying to start a spam discussion here on the Operations list <g> just get some operational information. -M

2 1

OT: Total Traffic. Was: Sprint peering policy
by Rowland, Alan D 02 Jul '02

02 Jul '02

Richard, I know a few news server admins who might disagree with you. Or at least it seems that way at times. ;) I typically have a 251Kbps (broadband) stream from www.thebasement.com.au running in the background when on line. The stream is coming out of Australia (don't think it's been Akakamized yet. Did I spell that right?) so that stream is on a US backbone. That's in addition to anything else I may be doing. This is only a single point of data but single points eventually add up to a bucket. Additional thoughts. Wonder what that peak traffic would be if individual sites and services weren't as rate limited as most are by pipe size, hardware or software? Or how about a 6Gbps HDTV video conference stream (UCLA (?)- MIT on Internet2). Just my 2¢. The delete key is your friend. -Al Rowland -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Monday, July 01, 2002 6:07 PM To: Stephen J. Wilcox Cc: Deepak Jain; Miquel van Smoorenburg; nanog(a)merit.edu Subject: Re: Sprint peering policy On Tue, Jul 02, 2002 at 12:47:36AM +0100, Stephen J. Wilcox wrote: > > I'm curious about all these comments on bandwidth, "few Mbs is > nothing", "dropping OC48 to IXs". > > Theres an imbalance somewhere, everyone on this list claims to be > switching many gigs of data per second and yet where is it all going? > Not on the IX graphs anyway.... > > Did someone mention large bandwidths and everyone else felt they > needed to use similar figures or is everyone really switching that > amount but just hiding it well in private peerings? I know theres some > big networks on this list but theres a lot more small ones.. It's all so much posturing, just like the people who claim they need OC768 now or any time in the near future, or the people who sell 1Mbps customers on the fact that their OC192 links are important. If there is more than ~150Gbps of traffic total (counting the traffic only once through the system) going through the US backbones I'd be very surprised. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 2

performance testing/monitoring
by brett watson 02 Jul '02

02 Jul '02

hate to break up the peering thread but i'm wondering if anyone has experience/knowledge of Empirix tools? i worked with them back when they were known as midnight networks but they focused on protocol conformance testing at the time (mid-90s). they're "corporate history" has no mention of midnight though. they do seem to have some network simulation tools which i'm also interested in. heck, i think someone might have even asked about that in the last few days so maybe this is a relevant/appropriate topic. will take replies off-list if not. -b

1 0

Re: Sprint peering policy
by Paul Vixie 02 Jul '02

02 Jul '02

> What is the connection between unregulated peering and the financial > difficulties we have seen? > > The problems have been caused by: > > - Bad business models > - Greed > - Corporate officers who have shirked their fudiciary responsibilities to > the stockholders > > If you can somehow tie peering into this, please be my guest, but it would > be a bit of a stretch. you've asked and answered your own question, though. remember, wcom tried to buy sprint and it was only the EU's antitrust folks who stopped them. when peering was an engineering issue rather than a sales/equity/PR issue, there was a lot of it, and there were fewer single points of failure at ISO-L8 than we see today. i completely understand that acquisition is a common and valid means to grow a business. however, with closed peering as a way of life for our industry, a lot of deals are done which only make money for the investment bankers and don't actually "grow business". closed peering is all about greed and not about service levels, competitive pricing, or overall sector health. closed peering is a bad business model. it shirks fiduciary duty to long-term equity holders in order to give periodic "quick hits" to short-term holders. closed peering proceeds from a Highlander-like premise "there can be only one" when in fact there could be many, and if there were many then the industry overall would be healthier.

7 6

Re: Opnet, Wandl, etc.
by Michael.Dillon＠radianz.com 02 Jul '02

02 Jul '02

>We are looking into using a full or partial mesh MPLS overlay for traffic >characterization on our network and need a tool to model utilization and >simulate failures. At first we won't be doing any real TE. The MPLS network simulator perhaps? http://flower.ce.cnu.ac.kr/~fog1/mns/ There's something called Deriveit that you can get on a 30 day trial which might be sufficient for some people. --Michael Dillon

1 0