- NANOG - lists.nanog.org

RE: for folks tracking DDOS sources or reading the GRC attack log
by Richard A. Steenbergen 26 Jun '01

26 Jun '01

On Mon, Jun 25, 2001 at 04:54:12PM -0700, Mike Batchelor wrote: > > > 24.0/8 is the "cable block". > > No it's not. Check out 24.132/14 for instance. IANA and ARIN seem to think it is... Check out: http://www.iana.org/assignments/network-24 The "Network 24 - Cable Block" will link to the following text: Internet Assigned Numbers Authority (IANA) Date: May 11, 2001 The IANA has completed the administrative transfer of responsibility for 24.0.0.0 - 24.255.255.255 (Cable Block) to the American Regional Internet Registry (ARIN). Questions or Whois information for this 24/8 block should be directed to ARIN <www.arin.net>. I'm sure a few legacy allocations in 24/8 space will happen to slip through... > > Nearly all the cable operators > > have one slice or another from this block. > > Perhaps this is true in the US. > > > Nearly all North American > > cable modems users have address space in this block. > > No they don't. Well since I don't think you can argue Canadian cable modems follow different patterns, you seem to have contradicted yourself... > > Ran > > rja(a)inet.org > > Didja ever have a bad hair day, when you just felt like being contrary > for the hell of it? You think thats funny, until Extreme switchs starts shipping with your IP null routed by default... :P -- 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

Cisco Routers
by Moe Allen 26 Jun '01

26 Jun '01

Does anyone have any information concerning IP address blocking, as it relates to Cisco routers. I need to start blocking some of this Forged Spam E-mail. It would be nice if this list is current? thanks Morris Allen VidcomNet, Inc.

2 1

Re: Cable Modem [really PPPoE is inferior]
by Fletcher E Kittredge 26 Jun '01

26 Jun '01

On Fri, 22 Jun 2001 11:35:25 -0400 "Drash, Jim [EESUS]" wrote: >At 11:19 AM 6/25/2001 -0400, Fletcher E Kittredge wrote: >>I think we are in violent agreement. I don't like the >>IP->MAC->Customer mapping, it is forgeable, but it is the only one I >>know we have available. I agree with you that it is not the only >>possible mapping. If you can point me to a better existing mechanism, >>I would be grateful. > Since DHCP maps a MAC to and IP address but not to a user, maybe there is a > technology that would provide this missing piece. Low and behold, there is > one: PPP and more specifically PPPoE (Over Ethernet) provides just the > functionality that some people are looking for. A number of broadband > providers are using PPPoE to fill the need of not only assigning an ip > address to a connection but associating that connection with a user. Note the key phrase "better mechanism" in my statement. Many people consider PPPoE an inferior technology. It reduces reliability and usability of the product while raising the cost by increasing complexity and placing unacceptable restrictions on the customer. PPPoE adds an unnecessary layer on the network stack. Thus it consumes extra resources and gives one more component to fail and debug. PPPoE used as an authentication mechanism negates the "aways on" advantage of IPoE networks. I don't like it when vendor engineers impose restrictions on customers to satisfy the engineers design problems. Good engineers design systems that make the network simple, easy to use, secure, cheap and end-to-end. They don't come up with ways to deliberately degrade the value of the network. Personally, I think PPPoE belongs in the "bad idea box" along with IPoATM and MPLS. > I would propose that if DHCP (or any other technology) does not do what you > want, see if there is another that will. If there is not build your own and > don't whine about it. Since the ISC DHCPD is open source, you can change it > as you see fit. If you change it, you should contribute back. However, do > not assume that Ted or anyone else will do this for you or support it if you > contribute back. Hum, you must be thinking of someone else. Properly designed systems based on DHCP do exactly what I want. My complaint is with people who don't design networks properly. Economic, Fast, Secure, Reliable and easy-to-use: If you can't design a network system that is has all five qualities, best copy the system of someone who can. Copying other's work until you reach master level is a good thing. I do so appreciate your suggestions about how open software projects work. Lots of people think that because I have been doing this for so long, I don't need these little reminders. But was one gets older, the details slip out of your mind, like sea water running through the fingers of your cupped hands. Time for a walk on the beach. regards, fletcher -- Fletcher Kittredge Great Works Internet 8 Pomerleau St. Biddeford, Maine

4 4

for folks tracking DDOS sources or reading the GRC attack log
by RJ Atkinson 25 Jun '01

25 Jun '01

24.0/8 is the "cable block". ARIN normally allocates residential cable modem subnets out of this space. Nearly all the cable operators have one slice or another from this block. Nearly all North American cable modems users have address space in this block. Cable modems themselves are nearly always numbered in 10.0/8. For those who have read the GRC web site, note that 216.216.8.x appears not to be a cable modem slice in any event. ARIN reports that this slice has been allocated to @Work, which is the commercial IP lease-line business unit within Excite@Home. Presence of a *.home.net DNS entry does not mean the system is on any cable modem network. There are no 24.0/8 addresses listed in the log at http://grc.com/dos/attacklog.htm so it isn't clear to me that any cable modems were used in that particular attack. Ran rja(a)inet.org

5 6

RE: Exodus Down
by Richard A. Steenbergen 25 Jun '01

25 Jun '01

On Mon, Jun 25, 2001 at 03:18:30PM -0700, Bill Woodcock wrote: > > > maybe there should be a nanog range day :) > > Mmmm... well, there's certainly a history of pre-NANOG field trips, > and the next NANOG is in Oakland... Not to say that Oakland is a > free-fire zone or anything, but it would certainly be easy enough to > arrange for the use of a range the Sunday before the next meeting. > :-) It isn't? For the t-shirt, I was thinking it could show some people wearing nanog badges getting mugged on the street corner while the routers from the beer 'n gear are being wheeled out the back of the hotel... Just a thought. :P -- 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)

1 0

Re: SBC forcing new contract on ISPs
by Bruce Robertson 25 Jun '01

25 Jun '01

> Then mention to them that they must provide you with Reciprocal > Compensation. This probably does not apply, because it isn't actually SBC - it's ASI, which is a wholly owned subsidiary of SBC. ASI is not a telco; it's actually a CLEC. It has its own contracts with the ILEC (Nevada Bell in our case) to access copper. It is not subject to things like Reciprocal Compensation, which we wouldn't qualify for anyway, as an ISP (we are not a CLEC). -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 For PGP key: finger bruce(a)greatbasin.net

1 0

Re:Eliminate Dependency on Telefonica in Brazil?
by rkuhljr＠uol.com.br 25 Jun '01

25 Jun '01

>Company X comes to believe that one of the best things it could do to >achieve reliability >on its circuits in Brazil is to reduce or eliminate its dependency on >Telefonica >for "last mile" support/provisioning. Telefonica circuits are usually very reliable if goes on fiber from end to end; copper-based circuits from them perform poorly. But even on fiber, restore intervals after circuit/equipment failures are not good. > Are there any options available to >such >a Company? If so, which might be best: microwave, satellite, cellular, etc? >Which vendors >might be investigated and considered for these services? Last mile: AT&T LA (www.netstream.com.br) (fiber) Metrored (www.metrored.com.br) (fiber) Diveo (www.diveo.net.br) (microwave radio) Embratel (www.embratel.net.br) (has some fiber/radios, uses the 3 above otherwise) Engeredes (www.engeredes.com.br) (fiber) Pegaus (www.pegasus.net.br) (fiber) > Any difference >between >VPN and point to point circuits? Not on a city or state scale... Telefonica is the incumbent carrier only on Sao Paulo state, in what cities/states do you need circuits ? > If you were goign to build a large scale >web presence >in Brazil...what's your top list of possible circuit providers? The one(s) the backbone(s) you get IP service from prefer. Getting a circuit from Telefonica to connect to Embratel IP backbone will probably give you a headache. >Reliability >is valued >over cost. I guess to put the query in nanog mailing list terms.....who >could I go >with to ensure I'm a good BGP neighbor in Brazil? On IP transit, you should try getting good connection to Embratel (AS 4230), directly from them or from someone who has. Although every other AS in Brazil is trying to change this, current scenario is they have 80% of brazilian web traffic; prices are high, they are a Worldcom company, probably the same song as in US. Also connecting to a peering point bypasses them (and some congested circuits) for going to a number of autonomous systems, so give a look at www.ansp.br/ptt. >I know some may find the above humorous since if you insert Verizon, Not yet represented here. >BellSouth, Owns cellular company(BCP), doesn't provide circuits (although they own a microwave radio network with very good coverage) >etc in place of Telefonica...the hypothetical may not change much. :-) >No offense to the Bells...when I pick up the phone 99.999% of the time >I have dial tone--which I appreciate. :-) But it costs $$$... Lucky you, more than Telefonica can say about their own voice lines. Rubens Kuhl Jr.

1 0

Operational Content, I think...
by Deepak Jain 25 Jun '01

25 Jun '01

This comes up every now and then, and I still haven't seen a good solution, so here is the situation. Every now and then, the graveyard maintenance shift (read: few people) needs to mount a 7' tall or 600 lb piece of equipment we've all come to know and love in a rack. While pad jacks are available to move them around the datacenter floor, equipped with friendly hydraulics and all, there is a piece missing. Is there a common-sense piece of equipment available that 1 person can operate that will support a very bulky, rackmountable piece of equipment so the same, single person can mount/unmount it near the top of a rack? I have seen plenty of solutions for this on warehouse floors, but most datacenters don't have the ceiling height for track-crane. I don't know how people handle the 15' relay racks either now that I am sharing my gap in knowledge. Your advice, suggestions and even jokes are appreciated, but remember, I'm armed. :) Deepak

6 6

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 25 Jun '01

25 Jun '01

Cross posting sucks. However, this is a special case as this discussion really ought to move to NANOG without losing context. Please edit headers to make sure replies go *only* to NANOG. On Tue, 19 Jun 2001 14:55:41 -0700 "Kenneth Porter" wrote: > >P.S. I will be out all day tomorrow testifying to the Public > >Utilities Commission staff and will not be able to respond to any > >further discussion for a few days. > > Testifying on this particular issue? I'd be interested in hearing what > comes of it. Once again it sounds like we're trading a little imagined > security for loss of freedom, and laying the expense on common > carriers. Testifying on an entirely unrelated docket. You make a very important point. I am a believer in strong privacy, and that privacy is constantly under attack. The defense of privacy requires constant vigilance. However, being able to identify which computer is sending traffic does not result in loss of privacy: 1) privacy should come from other, more secure, mechanisms such as encryption of data. 2) Current dial-up IP access provides an even greater ability to identify the user. regards, fletcher

1 0

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 25 Jun '01

25 Jun '01

Cross posting sucks. However, this is a special case as this discussion really ought to move to NANOG without losing context. Please edit headers to make sure replies go *only* to NANOG. On Tue, 19 Jun 2001 14:52:45 -0700 "Richard Barr Hibbs" wrote: > > -----Original Message----- > > *Snip!* > > > There are three reasons that one needs to be able to map an IP->MAC-> > > particular customer: 1) to provide customer support, 2) to provide > > network metrics and monitoring, 3) to provide identification in court > > cases. > > > > If one builds a network that does not provide these three abilities, > > the public will eventually step in -- via the legislature, the courts or > > the marketplace. > > > > If you can explain how you can provide quality customer support > > without a MAC map, provide network metrics and monitoring without a > > MAC map, and satisfy the courts without a MAC map, then I agree with > > you, there are valid different ways to provide this service. > > > > However, if you can't meet the three criteria, then the only valid > > design for a public network is one that can track > > is an invalid way to build a public network. It is wrong. > > > > *Snip!* > > Let me try to rephrase this a bit: to achieve the three goals that you > mention (customer support, network metrics and monitoring, and legal > identification of users) you assert that the way to do so is to have a > mapping between IP address and MAC address. I don't disagree that an > association between IP and MAC can be useful in achieving those goals, but I > do disagree that it is the only one. I think we are in violent agreement. I don't like the IP->MAC->Customer mapping, it is forgeable, but it is the only one I know we have available. I agree with you that it is not the only possible mapping. If you can point me to a better existing mechanism, I would be greatful. My complaint is with people who could collect and use this information, but then throw it away and claim ignorance when their network is used to as a springboard for attacking other systems. > Other perfectly valid associations include a non-volatile system serial > number of some sort, the "universal user identification" proposed by Intel, > or some algorithmic generation of an identifier based on physical system > characteristics in place of the MAC address. > > I've supported very large client populations and would suggest that it would > have been much more useful to have somehow been able to discern a client's > physical address (for example, 1201 Central Avenue, Room 346) than their MAC > address. MAC address is, of course, useful to distinguish among clients at > the same physical address, but then so would be additional information such > as "port 57, switch 3SW1201SNFC43." The DHCP client and IP stack that we > used did not provide us the luxury of that additional identification, > however. Sounds like a large company or organization network. Frankly, not germane to this discussion. If a database was kept of client MACs, and this information was required before access to service was made available, you then have a network of known devices and have made a long step towards towards assigning responsibility. > Any sort of identifier that helps distinguish among different hardware > classes (as the initial octets of a MAC address identify its manufacturer) > can be crucial in developing a repair history or predictor of failures for > stocking spare parts, but I don't quite see how knowledge of the MAC address > is required to monitor network usage or generate performance metrics that > are not tied to hardware type or specific device: IP address is much more > useful for that, in my opinion, especially if additional information about > physical connections (such as port and switch numbers) is available. Please remember we are talking about large IP over Ethernet *public* networks (cable, Etherloop DSL, wireless) which are used by a completely heterogeneous population. The operator must support the connection of arbitrary devices. Many of the customers have very little knowledge of their configuration or networking. The network operator must support arbitrary devices and clueless customers. Some scenarios: 1) When a customer calls and reports a connection problem, many times the problem will occur before an IP is assigned. The MAC address is the only mechanism for debugging these problems. 2) When a customer's device is misbehaving, by slamming a DHCP server with many uncompleted requests, by broadcasting traffic, or by being hijacked for a DDOS, the only current method of identifying the device is through the MAC address. 3) ARIN has sent the strong message that they expect IP over E public network providers to use dynamic IP allocation in order to conserve IPv4 addresses. Public networks are oversold and a fundamental financial/quality requirement is that the rate of oversell can be accurately tracked, or that customers be accurately charged for their bandwidth usage. In gathering these statistics, a MAC address is a key bit of glue allowing one to tie flows to customers. > Finally, I would not want to declare under oath that a MAC address > absolutely and uniquely identified a client host: it's just too easy to > spoof. Total and absolute agreement. There is no question that it is easy for a technical sophisticated customer to spoof a MAC address. This fact should always be kept in mind when analysing any information. However, there are a couple of possibilities for spoofing: 1) An existing, connected and valid MAC is spoofed. In that case, the spoofing becomes apparent pretty quickly; duplicate MACs make themselves known... 2) A non-existing, non-connected and non-valid MAC is spoofed. In that case, someone will have had to put them in the database in order to get service. One can then go to that person and ask why the spoofed > Having said all of this, I want to be sure you don't misunderstand: > supporting customers, whether there are two or 2 million of them, is > extremely important for any service business. Part of that support includes > administering servers and facilities so that all customers can enjoy the > services without interfering with other customers. So are we really in > disagreement? Mostly not. > I just don't know how to make the last part of the 3-way association > IP-->MAC-->client work reliably without significant changes in most > environments. Yes, it is difficult to add this functionality after the fact. However, the original discussion was prompted by a question about the design of a future network. As others have pointed out, if you start from the beginning, it is possible to design in the simple capture and maintenance of IP -> MAC -> customer data. To do otherwise is irresponsible. regards, fletcher

1 0