August 1997 - Test - lists.nanog.org

Re: Trans-Atlantic Traffic
by Sean M. Doran 22 Aug '97

22 Aug '97

Simon Leinen <simon(a)limmat.switch.ch> writes: > There are many of these small links over the pond. One of the reasons there are so many trans-oceanic links between Europe and North America is that the cost of a trans-oceanic full-circuit is almost infinitely cheaper than inter-country circuits at PNO tariffs, thanks to inexpensive U.S. half-circuits. This is changing, largely due to E.U. telecomms liberalization. > I'd be interested > in whether (and if so: how) different providers manage to save costs > by sharing fast transcontinental lines among themselves. Hm, I wonder if I can put enough value into answering this question to have people forgive me for talking about my (European) employer on an ostensibly North American mailing list? :-) Ebone is a customer-owned trans-continental backbone provider that functions as a buyers' cooperative with respect to inter-country (and in some cases intra-country) capacity. The not-marketing-person designed web page describing this can be found at http://www.ebone.net/structure/objectives.html This largely works in part because of the origins of Ebone and the people who have worked with it since then, and because Ebone focuses principally on large ISPs. That leads to the assumption that customers aggregate enough traffic that they will use all the capacity they pay for at all times, which also leads to Ebone's no-overbooking design, and consequently to Ebone's rather large cost-based prices relative to its competitors which target vastly different markets, or do massive loss-leading, or do massive cross-subsidy, or all three. One way of looking at the Ebone backbone is as a large TDM network, much as one could build with ATM and CBR VCs, only without the drawbacks of ATM or a big VC mesh (and with the drawbacks of a complicated router-based network). There are of course several other pan-European providers such as Unisource's UBN, BT's CIP, UUNET, EUNET, Compuserve, Global -1, and IBM Advantis, each of which appears to function much like their counterparts or analogues in the U.S.A. This, however, is not exactly "line sharing" per se. Finally, there may be people sharing lines bilaterally or multilaterally among a small group of organizations. Some alternative capacity providers are offering decent rates on STM-1s among large cities; pulling VC3s or VC4s out of an STM-1 and paying proportionately has some economic attraction, particularly in cases where competition among providers doing this isn't quite as cutthroat as it is in North America. A "how" diagram following a model other than something closely mirroring the Ebone approacj would be: City A City B provider 1-----\ /-------provider 1 | | provider 2-----ADM===========ADM------provider 2 | | provider 3-----/ \-------provider 3 Where the single-stroke lines represent 45Mbps or 34Mbps circuits, whether through a local bandwidth provider (like the PNO) or using cables or something across a colocation facility like Telehouse, and the double-stroke line represents an international STM-1 provided by a bandwidth carrier. This kind of thing tends to bring the per-bit-per-second-per-month price down quite a bit compared to three individual E3s or DS3s, assuming that pricing is done relative to ordinary PNO tariffs. There are cost and complexity issues for all largeish ISPs to consider when choosing among various approaches for moving traffic around, obviously, so there is certainly on One True Approach to sharing really expensive bandwidth. One observation, however, is that aggregating providers appear to be popular choices when dealing with very expensive lines or high levels of complexity, and unpopular choices when they don't actually solve either problem (like when a large ISP can't use much of its flat-rate paid-for bandwidth because of massive overbooking or other design issues, or when routing and other things break alot). Finally, returning to the question of how many small pipes there are and how much trans-oceanic bandwidth there is, it is worth noting that a large number (but not most) of Ebone's customers have their own circuits across the Atlantic ocean, in spite of Ebone's pricing discounts on people who use Ebone'e trans-atlantic capacity. (Our trans-atlantic capacity is vastly less expensive than our trans-European capacity, and across a full customer pipe, a customer who is receiving U.S.-sourced traffic (or sending U.S.-bound traffic) through Ebone typically uses enough traffic that the cost incurred by meeting that customer's traffic needs is less than the cost incurred if the pipe was full of only European-to-European traffic). In essence, the reason there are lots of trans-Atlantic pipes is that in order to have sufficient capacity one would have to connect with a relatively large pipe to a trans-Atlantic traffic aggregator, which tends to be alot more expensive than a smaller pipe within Europe and a separate pipe across the ocean. This will probably remain the case, price-wise, until intra-European bandwidth prices fall to less than inter-continental prices, or to the point where the cost of connecting to a provider (or multiple providers) within Europe is perceived as less than the cost of maintaining a more complicated network. Sean.

4 4

Re: Asymetrical Routing
by Vern Paxson 21 Aug '97

21 Aug '97

> My question is: How bad is this? Is it terminaly bad or simply not > so great? Asymmetric routing by itself has virtually no impact on performance. It does present a measurement headache, though. This is discussed in a paper of mine available from ftp://ftp.ee.lbl.gov/papers/routing.SIGCOMM.ps.Z a revised version of which will be appearing in IEEE/ACM TON later this year. > Out of order TCP packets are bad, but can simply be reassembled. Asymmetry doesn't lead to out-of-order delivery, so this isn't a problem. Routes that *change* often, on the other hand, can indeed lead to performance problems. Vern

1 0

Re: ICMP Attacks???????
by Danny McPherson 21 Aug '97

21 Aug '97

> That's helpful, but even as an RFC people still have to be aware that > the problem exists before they do anything about it. A typical person > that I deal with would be a small networking integrator that is selling > Bay routers to school districts. This is not somebody who reads > RFCs, and most of them don't have any idea what issues face the > Internet today. I'm not sure what we can do, but this is one of the > types of people that severely need the education. I guess it probably > falls back on the vendors here to educate their resellers and customers. Ideally, ingress filtering would be applied as close to the edges as possible. This, for obvious reasons (one of which you pointed out above), isn't feasible. What is feasible is that all providers that possess some amount of cluefulness (this should cover *most* at the public exchanges), deploy ingress filtering on their customer connections. IMO, vendors should only be accountable for providing mechanisms to put these policies in place, most of which already exist. It's the responsibility of the participants of groups such as this to see that those policies are deployed. -danny

1 0

Internet Route Filtering
by Robert Malally 21 Aug '97

21 Aug '97

Hello, Does any one truely know what the current route filtering polices are for Sprint and MCI. The following rules are some that I have heard : Sprint currently filters announcements from its non-customers as follows: RFC 1597 reserved space: accept nothing (**) In the classical "A" space: accept nothing longer than /8 In the classical "B" space: accept nothing longer than /16 in 24/8 space: accept nothing longer than /19 (*) in 195/8: accept nothing longer than /19 in 206/8 - 223/8: accept nothing longer than /19 in 192/8 - 205/8: accept nothing longer than /24 (*) in-line with the IP registries allocation (**) RFC 1597> Private Address Space RFC 1597> The Internet Assigned Numbers Authority (IANA) has reserved RFC 1597> the following three blocks of the IP address space for private RFC 1597> networks: RFC 1597> 10.0.0.0 - 10.255.255.255 RFC 1597> 172.16.0.0 - 172.31.255.255 RFC 1597> 192.168.0.0 - 192.168.255.255 How are MCI and Sprint going to adjust their routing polices when the reclaimed class A's are given out. Thanks Robert Malally

1 0

RE: Trans-Atlantic Traffic
by Thomas P. Koltai 20 Aug '97

20 Aug '97

--- On Wed, 13 Aug 1997 23:46:56 +1000 Stuart Bryant <stuartb(a)ourworld.net> wrote: >Hi, > Does anyone know the kind/amount of data currently being moved either >way over the Atlantic links ? About 11,520,000,000 bit per hour. Tom -------------------------------------------------- Thomas P. Koltai Mobile: +61-419-333331 187 Liverpool Street, Sydney NSW Australia 2000 --------------------------------------------------

5 4

THENET update
by sob＠academ.com 20 Aug '97

20 Aug '97

It appears things have returned to normal with THENET. I am seeing their service machines and UT Austin from the major peering points now. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

THENET outage
by sob＠academ.com 20 Aug '97

20 Aug '97

FYI, I understand that there has been a significant power problem at UT Austin that has affected THENET connectivity. I observe that the MAEs don't have routes to either UT-AUSTIN or the THENET service machines. I don't know much more than this about it. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

[NON-Operational Issue]: Paul Vixie is a Vigilante?
by Chris A. Icide 19 Aug '97

19 Aug '97

List, First, sorry for the non-operational issue. They said it, I read it.... Here it is. http://www4.zdnet.com/anchordesk/story/story_1170.html Comments concerning a spam "black hole" list maintained by Paul that makes the spammers "disappear".... Chris

2 1

Re: ICMP Attacks???????
by Vadim Antonov 18 Aug '97

18 Aug '97

Just for the record -- the first description of such mechanism is in Sep 95 draft for TRAP ICMP: "Trace Back messages allow to locate the source of a stream of packets even if they carry incorrect or forged source address. Trace Back message causes a gateway to install a "trap" route to the specified desti- nation, to catch the incoming packet to that destination. Once the packet is received, the gateway reports it to the trace initiator, removes the trap, and sends the Trace Back message to the neighbour gateway the message came from. A trap expires (thus terminating the trace) if no packet addressed to the destination is received." --vadim "Alex.Bligh" writes: > > The other nice solution would be an inverse traceroute that went > back to each router in turn, passing it a bit of BPF saying "where > are you getting packets like this from please?". If such a protocol > existed...

2 1

Re: ICMP Attacks???????
by Danny McPherson 17 Aug '97

17 Aug '97

[ Note: To those that (strongly) dislike Cisco, admittedly or not, you don't have to read the non-intuitive examples included below, really ;-)] > It would be nice, but for now logging the hardware addresses along > with the ip addresses would be cool. After speaking with some Cisco folks, I've found that you can already do this on Ciscos .. as I believe someone mentioned here before. I tried it on our MAE-East router (w/RSP2) and found that no significant amount of CPU was wasted logging the packets. Given, I didn't leave the ACL applied to our NAP FDDI interface for any substantial amount of time, but there was really no need to, per all I wanted was enough data to verify the source router/network of the attack. Consider the following: Someone, somewhere, is using smurf.c (or any spoofing-type-program, for that matter) to launch a DoS attack on one of your customers. All you know is that the attacker is "pinging" the broadcast address of a few of the public exchanges, with a source IP address of a customer's server(s). Finding the destination IP address isn't that difficult (at least for your customer ;-), it's the "real" source that's the problem. You can build an ACL on your NAP router that logs all ICMP-type (or whatever) traffic bound to the IP address of the customer's server, as such (assuming you're customer's server ip address is 1.1.1.1): access-list 199 permit icmp host 1.1.1.1 any log-input access-list 199 permit ip any any You then apply the access-list inbound to the NAP interface. Then, assuming matches occur, you should receive something similar to: Aug 15 20:04:45.087 MST: %SEC-6-IPACCESSLOGDP: list 199 permitted icmp 1.1.1.1 (Fddi6/0 0060.7017.a188) -> 192.41.177.255 (0/0), 1 packet The MAC address listed after the interface identifier is that of the router's interface on the ring from which you received the spoofed packet. You can then match the MAC address to the IP address of the interface (via "sh arp", or other ways) .. and you've just identified the router/network from which the attack is being sourced. Now comes the fun part, cooridinating with the Operations/Security folks from the corresponding network(s) to track the attack, hop-by-hop, through their network. If the attacker is using multiple public exchange subnets to source the echo replies, you may consider identifying the source router/network at another exchange as well, before pointing fingers. Hope I haven't overlooked something obvious here .. but I'm sure that if a did someone will "enlighten" me ;-) Of course, the one obvious thing I didn't mention is that if everyone were to deploy ingress filtering, this would be much, much easier to control. -danny

6 5