Re: The status of consumer rate limiting?
Since some p2p programs now use well known port numbers allocated to other things eg port 80, is it even possible to block/rate limit them? And have folks attempts at blocking caused this move to use such port numbers which imho is not a good thing.. As long as there are some bits in the stream that give away the ultimate application of that stream it´s possible. Using SSL / IPSEC / some proprietary protocol will degrade the detection to look for elephant flows but still allows for some bandwidth regulation when neccessary. To look beyond the packet you either need more sophisticated hardware or reasonable speeds, like in the gigabit range, not 10G/40G. Pete
Re: Cisco vulnerability and dangerous filtering techniques
Just a handful of traceroutes would give it enough information to start at a major backbone and work back towards itself. I guess all folks with Ph.D. at Akamai really are paid for nothing if a virus could calculate that with a few traceroutes. Akamai is a business and has customers paying for its service, therefore they must attempt to get the best answer every time. But a virus can live with sub-optimal results as long as it does well enough to keep propagating and keep wreaking havoc. In fact, the virus writer might prefer that it does not shut down the entire Internet in one grand orgy of destruction because if that happens, there is too much incentive for police to identify the individuals concerned. The fact is that the idea has now been expressed in public. This almost guarantees that there are now multiple teams of virus writers working on incorporating these ideas into their creations. P.S. The only sure way of eradicating this Cisco bug from the Internet is to convert the Internet to IPv6. The bug doesn't affect Cisco's IPv6 code and older routers whose IOS cannot be upgraded also cannot do IPv6 so they cannot be used in an IPv6 Internet. Food for thought... --Michael Dillon
re: rfc1918 ignorant
I agree... The only problem is if you filter all inbound RFC 1918 and inadvertently block ICMP messages from their routers on rfc1918 space. That could potentially cause issues with network connectivity related to MTU, etc... At 08:59 AM 7/23/2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. --- Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium -- David Temkin Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
re: rfc1918 ignorant
On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html Rich
RE: rfc1918 ignorant
Good point on the PMTU, you're correct and I wasn't thinking about that (though generally that would have come from the inside router, unless one of those routers was where the MTU limitation was). Engineered *correctly *I don't see an issue. I never implied that people should remove filters for 1918, that's silly. On Wed, 23 Jul 2003, Ben Buxton wrote: Uhhh...PMTU-d can break as routers will send back icmp cant-frag packets from those link addresses and rpf, filtering, etc will bring tcp connections to a standstill. Don't filter rfc1918? umm good luck convincing the rest of the net to eliminiate their filters. The basic premise of building public networks is that you have to work around other peoples policies. If it's corporate nets, then sure you can control it all, but not here. Though the PMTU-d point is arguable (what are your internal links doing with crummy MTU, for example). BB Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. --- Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium -- David Temkin
Re: Cisco vulnerability and dangerous filtering techniques
P.S. The only sure way of eradicating this Cisco bug from the Internet is to convert the Internet to IPv6. The bug doesn't affect Cisco's IPv6 code and older routers whose IOS cannot be upgraded also cannot do IPv6 so they cannot be used in an IPv6 Internet. Food for thought... Quick solution to this bug, as well as any future bug(s) replace all routers with PCs running Zebra. James Roten Ninjas are sooo sweet that I want to crap my pants. I can't believe it sometimes, but I feel it inside my heart. These guys are totally awesome and that's a fact. Ninjas are fast, smooth, cool, strong, powerful, and sweet. I can't wait to start yoga next year. I love ninjas with all of my body (including my pee pee).
RE: Cisco vulnerability and dangerous filtering techniques
Quick solution to this bug, as well as any future bug(s) replace all routers with PCs running Zebra. That is good until Zebra get's a bug and then someone will say go to XYZ... Jim
source filtering (Re: rfc1918 ignorant)
On Wed, Jul 23, 2003 at 02:10:17PM +0100, [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html I think you'll see more and more networks slowly over time move closer to bcp38. I believe that ATT is the only tier-1 provider that is in full compliance with this. I'm sure some of the smaller providers are as well. I've been looking at the unicast-rpf loose drops at our edges of our network the past month off and on and am still surprised at the bitrate of packets that can not be returned to their sources. I think it's a simple thing to do that will insure that you are not carrying all this extra junk traffic on your network. Another perspective here: A number of people refuse to answer calls that show up on their phones as out of area or private. Why would you answer or trust IP packets from hosts that are not in the routing table. While there is no PKI or similar to check if the packets are authenticated/signed for most of the network traffic, this does seem like a simple thing to do. Don't trust packets if you can't possibly figure out where they are coming from. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Cisco vulnerability and dangerous filtering techniques
Like I said, it's not going to be perfect, but it is better than blindly spewing out evil packets. Between me and you, ospf packets or bad stp packets are a lot more dangerous than the whack a cisco router. Just try it. Alex
Re: Cisco vulnerability and dangerous filtering techniques
Another argument for OSPF authentication it seems. However we are still out of luck in the STP announcements unless you configure all the neat little *guard features (bpdu,root etc) from Cisco et al. On Wednesday, July 23, 2003, at 12:34 PM, [EMAIL PROTECTED] wrote: Like I said, it's not going to be perfect, but it is better than blindly spewing out evil packets. Between me and you, ospf packets or bad stp packets are a lot more dangerous than the whack a cisco router. Just try it. Alex
second call for an unbundled portable /24
We have attempted in the past tried to deal with Arin on this issue and they as usual deny anything that could potentially be useful, in thwarting these attacks. There have been some people with good idea's, however when you have a 1 gig bi-directional pipe and you have 2Gb/s incoming these idea's then only look good on paper with nice graphic's to match. I think all the oc48 shelves need to be checked and the passwords changed. Henry R. Linneweh
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
RE: rfc1918 ignorant
Ahhh...but this all comes down to how one defines enterprise and it's network scope. IANALBPSB (I am not a lawyer but probably shoud be) Daryl PGP Key: http://www.introspect.net/pgp [...] That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use [...]
Re: rfc1918 ignorant
Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
RE: rfc1918 ignorant
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 6:10 AM To: Dave Temkin Cc: [EMAIL PROTECTED] Subject: re: rfc1918 ignorant On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html They're not complying with RFC1918 either: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. and Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. It's pretty clear that devices with network layer connectivity outside the etnerprise are not private and thus can't be numbered inside private IP space. DS
RE: rfc1918 ignorant
Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. -- David Temkin On Wed, 23 Jul 2003, David Schwartz wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 6:10 AM To: Dave Temkin Cc: [EMAIL PROTECTED] Subject: re: rfc1918 ignorant On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html They're not complying with RFC1918 either: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. and Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. It's pretty clear that devices with network layer connectivity outside the etnerprise are not private and thus can't be numbered inside private IP space. DS
Re: rfc1918 ignorant
On 23.07 10:07, Kevin Oberman wrote: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) You read this correctly. We also wrote: It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. I consider this quite explicit. I also consider this still very valid. Imho the PMTU argument is moot. This should not be an issue at all other than on the edges these days. Should it nonetheless be an issue it can be done in the boundary routers which have interfaces numbered public address space. I do not know all the details here, so if I am wrong in detail, please tell me. Daniel
Re: rfc1918 ignorant
On Wednesday, July 23, 2003, at 11:40 AM, Dave Temkin wrote: Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. When the router needs to send an ICMP packet back to the source it becomes an originator. --lyndon
Re: rfc1918 ignorant
On Wed, 23 Jul 2003 13:40:03 EDT, Dave Temkin said: If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. If it shows up on a traceroute, it originated an ICMP packet. 10 * * * 11 * * * 12 * * * would be proper behavior if it was *purely* transit-only. pgp0.pgp Description: PGP signature
Re: rfc1918 ignorant
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. -- David Temkin On Wed, 23 Jul 2003, Lyndon Nerenberg wrote: On Wednesday, July 23, 2003, at 11:40 AM, Dave Temkin wrote: Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. When the router needs to send an ICMP packet back to the source it becomes an originator. --lyndon
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 13:40:03 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. And what are the ICMP packets doing on the net? They seem to be originating from 1918 space. Nothing in the RFC says that ICMP does not count. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: rfc1918 ignorant
On Wednesday, July 23, 2003, at 11:50 AM, Dave Temkin wrote: Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. True enough, but my view of networks that blindly block all ICMP is about the same as those that misuse 1918 addresses. And if they're blocking ICMP specifically to hide their misuse of 1918, well ... There are direct costs associated with dealing with networks that are configured as described above. If you can't see inside to diagnose problems, you can't call horsepucky when their support people start feeding you a line. The cost of downtime and local support staff quickly adds up. I've cancelled contracts in the past for this very reason. --lyndon
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: rfc1918 ignorant
Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. -- David Temkin On Wed, 23 Jul 2003, Kevin Oberman wrote: Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call.
RE: rfc1918 ignorant (fwd)
-- Forwarded message -- Date: Wed, 23 Jul 2003 07:53:26 -1000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant There's a common misconception reflected here that I wanted to correct. I don't have nanog-post, so I apologize if its not appropriate to reply directly. You may repost my comments if you'd like. [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. In fact, Comcast and others _do_ need a huge amount of private IP space because of this. We didn't blithely ignore the RFC, but didn't have a choice in implementation. Perhaps Cisco will improve their implementation for the next round of CMTS development... Filtering of RFC 1918 space by cable ISPs is of course another topic. -Doug- [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.)
Re: rfc1918 ignorant (fwd)
So this, as many other discussions in the past, ends with the conclusion that ARIN did their share of breaking RFC´s and the Internet ? Pete - Original Message - From: Dave Temkin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 9:11 PM Subject: RE: rfc1918 ignorant (fwd) -- Forwarded message -- Date: Wed, 23 Jul 2003 07:53:26 -1000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant There's a common misconception reflected here that I wanted to correct. I don't have nanog-post, so I apologize if its not appropriate to reply directly. You may repost my comments if you'd like. [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. In fact, Comcast and others _do_ need a huge amount of private IP space because of this. We didn't blithely ignore the RFC, but didn't have a choice in implementation. Perhaps Cisco will improve their implementation for the next round of CMTS development... Filtering of RFC 1918 space by cable ISPs is of course another topic. -Doug- [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.)
Re: rfc1918 ignorant
Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. Sure, but people blocking all ICMP haven´t usually heard that there are different types and codes in ICMP. It´s surprising how many large www sites do not work if your MTU is less than 1500. Even if you do PMTU. (because the packets vanish somewhere before or at the server). Pete -- David Temkin On Wed, 23 Jul 2003, Kevin Oberman wrote: Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call.
RE: rfc1918 ignorant (fwd)
ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. this would be really amazing, as it would have required a time machine. the cable build was before arin existed. randy
Re: rfc1918 ignorant
On Wed, Jul 23, 2003 at 01:49:37PM -0400, [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2003 13:40:03 EDT, Dave Temkin said: If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. If it shows up on a traceroute, it originated an ICMP packet. 10 * * * 11 * * * 12 * * * would be proper behavior if it was *purely* transit-only. Perhaps it should send back the icmp packet from a loopback interface that has a publically routed ip on it. that would allow p-mtu to work as well as you'd get the packet saying frag-needed and you can still get a general idea of what route the packets are taking (although not the specific interface). it would allow people involved to look at their lsp routes or forwarding tables to determine where the fault is without revelaing information they would rather not about their infrastructure. ip icmp response-interface loopback0 junipers already do this if you traceroute directly to them (ie: they're the last hop in the traceroute) and send back the packet from their lo interface if you have 'default-address-selection' configured. (i think that's the keyword) - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: rfc1918 ignorant
When the RFC's are broken, then what do you do? RFC's are to be followed if one can operate one's network under those constraints. Often times, RFC's don't take into account real world considerations. For instance: The rule that there should be only one root server network does not provide a solution to the problem of a corrupt monopoly gaining control over that one root server network (as is the case now). - Original Message - From: Petri Helenius [EMAIL PROTECTED] To: Dave Temkin [EMAIL PROTECTED]; Kevin Oberman [EMAIL PROTECTED] Cc: Lyndon Nerenberg [EMAIL PROTECTED]; David Schwartz [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 13:19 Subject: Re: rfc1918 ignorant Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. Sure, but people blocking all ICMP haven´t usually heard that there are different types and codes in ICMP. It´s surprising how many large www sites do not work if your MTU is less than 1500. Even if you do PMTU. (because the packets vanish somewhere before or at the server). Pete -- David Temkin On Wed, 23 Jul 2003, Kevin Oberman wrote: Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call.
rfc1918 ignorant
I have been busy today and not monitoring the list. I hate it when I miss the start of an rfc1918 rant. It feels like old news when you have to go back and read the email string and miss out on the name calling and ranting in real time. -Ron
Re: rfc1918 ignorant
When the RFC's are broken, then what do you do? If negotiations fail, you revolt and overthrow the corrupt governing body. If applicable, add overseas occupation forces :) RFC's are to be followed if one can operate one's network under those constraints. Often times, RFC's don't take into account real world considerations. Unfortunately putting the non-rfc-compliant out of business would require distributing clue to the buyers, which has been tried and usually fails. For instance: The rule that there should be only one root server network does not provide a solution to the problem of a corrupt monopoly gaining control over that one root server network (as is the case now). You sure have filed drafts how this should be corrected, specially those which do not specify two roots, yours and theirs? Pete
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 14:06:09 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. And where do the ICMPs come from if the DF bit results in a failure? Surely not an RFC1918 address. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Cisco Vulnerability (updated?)
Apparently protocol 103 does not need to have a ttl of 0 or 1 when it hits the interface in order to cause the DoS ... Cisco has updated their advisory to reflect this (Version 1.9 now).. Just wanted to alert everyone... This makes the thought of some sort of virus causing this even more realistic.. no need to check ttl's, just fire away with protocol 103... Yikes... -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: rfc1918 ignorant
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. RFC1918: Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not - using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. By virtue of using RFC1918 addresses on packet-passing interfaces (those which generate ICMP error messages) it is a violation of RFC1918. One could, in turn, disable those messages, or filter them, but as others point out, that breaks such things as PMTU-D. Also, those who think their RFC1918-numbered device is not directly reachable solely due to being RFC1918 numbered, are deluded.
Re: rfc1918 ignorant
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. -- David Temkin Wholesale blocking of ICMP is another sign of incompetence. Either way a network using RFC1918 inappropriately, filtering all icmp, or both is a clueless network.
RE: rfc1918 ignorant (fwd)
At 02:11 PM 7/23/2003, Dave Temkin wrote: -- Forwarded message -- Date: Wed, 23 Jul 2003 07:53:26 -1000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant There's a common misconception reflected here that I wanted to correct. I don't have nanog-post, so I apologize if its not appropriate to reply directly. You may repost my comments if you'd like. [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. In fact, Comcast and others _do_ need a huge amount of private IP space because of this. We didn't blithely ignore the RFC, but didn't have a choice in implementation. Perhaps Cisco will improve their implementation for the next round of CMTS development... Perhaps Comcast and others should INSIST that Cisco fix their bug, rather than just wish for a fix. Cable companies are buying lots of gear from them. Why not use that purchasing muscle to get this issue resolved? Or are the cable companies really interested in selling Internet service, or an online service like AOL? At some point, if you're going to sell Internet Service, it'd be nice if Internet standards and requirements are met. Filtering of RFC 1918 space by cable ISPs is of course another topic. -Doug- [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.)
Re: rfc1918 ignorant (fwd)
On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote: At 02:11 PM 7/23/2003, Dave Temkin wrote: 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. That's exactly what happened. The Lancity equipment were bridges, so you never saw them in traceroutes. The head-end bridges were aggregated into switches which were connected to routers. The Cisco uBR is a router, so you see the cable interface (which is typically rfc1918 space) showing up in traceroutes from the CPE out. Note that you don't see it on traceroutes towards the CPE since you see the 'internet facing' interface on the uBR. -j
root.rwhois.net broken
Domain Name: RWHOIS.NET Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS1.VERISIGNLABS.COM Name Server: NS2.VERISIGNLABS.COM Status: REGISTRAR-HOLD Updated Date: 15-jul-2003 Creation Date: 10-jul-1996 Expiration Date: 09-jul-2004 Registrar-hold? Nice. ETA for fix? $ host root.rwhois.net Host root.rwhois.net. not found: 3(NXDOMAIN) Can anyone from Network Solutions push this fix along? Or possibly let me know the IP of root.rwhois.net so we can look up things in the interim? bill
Re: rfc1918 ignorant (fwd)
Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not just reverse the way its configured? Put RFC1918 as secondary, and put the routable addr as primary. Either way, it should work w/o issues, right? I know quite a few people who purposely put a non-routable IP (whether it be 1918 or RIR-registered block) as primary on their interface, and use routable IP as secondary. Their reason for doing this is to somewhat hide their router's real interface IP from showing up in traceroute.. Well, it wouldn't completely 'hide' it, but to a certain level of degree, it probably does... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 07:21:25PM -0400, Jeff Wasilko wrote: On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote: At 02:11 PM 7/23/2003, Dave Temkin wrote: 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. That's exactly what happened. The Lancity equipment were bridges, so you never saw them in traceroutes. The head-end bridges were aggregated into switches which were connected to routers. The Cisco uBR is a router, so you see the cable interface (which is typically rfc1918 space) showing up in traceroutes from the CPE out. Note that you don't see it on traceroutes towards the CPE since you see the 'internet facing' interface on the uBR. -j
Re: rfc1918 ignorant
RFC1918 is a wonderful document. It probably added 10-15 years to the lifespan of the IPv4 address space, made IP addressing much simpler for internal applications, and it's prevented a large number of problems like people randomly making up addresses for boxes they know that they'll never need to connect to the outside. But it's not perfect, and it makes a couple of assumptions that aren't correct, which lead to the kind of edge cases driving this discussion. 1 - RFC1918 refers to hosts having IP addresses. They don't. Hosts have interfaces, and interfaces have IP addresses. In some cases, hosts have multiple interfaces with different communication needs - firewalls and routers being prominent examples. (You could argue that the definition of host excludes routers, but one of the problems here is that routers not only have routing parts, they have host parts, e.g. the configuration and control and monitoring functions that may deny public access for security and anti-DOS reasons.) And some software isn't all that bright about picking which interface address to use for its responses. 2 - RFC1918 assumes that communication is bidirectional, and that communication needs are bidirectional. They're not always, particularly at the network layer as opposed to the transport layer. Sometimes you need to send but don't want to receive, and sometimes you want to accept packets from machines that you don't want to send packets to. Routers often need to send ICMP packets about ___ failed to destinations that they don't need to accept packets from, such as traceroute and PMTU discovery responses - the source doesn't always need to be a routable address, though you could use a registered address and null-route any incoming packets to it if you wanted to help traceroute a bit. As a customer of an ISP, it's nice to be able to look at a traceroute and ask the help desk people why my packets from San Jose to San Francisco are going by way of Orlando, and to complain that the traceroute shows that orlando.routers.example.net is 250ms from San Jose, but I've also found that orlando.routers.example.net isn't always in Orlando, and that traceroute response times aren't always what they seem, and maybe that the 250ms doesn't mean either that Example.Net has a really slow route to Orlando or that the Orlando router is in Singapore; it may just be that they're using a Vendor X router which isn't good at pings when the CPU is busy (that's especially a problem for little DSL routers.) It's probably critical for connections between ISPs to have registered addresses that are used for traceroute responses, but I'm not convinced that routers internal to an ISP need to have globally unique addresses, as long as the ISP's operations folks can tell what interfaces are on what machines. Using RFC1918 space does mean that traceroutes either need to report numerical addresses or use the ISP's DNS server to resolve them, which isn't always practical, but that's not a big limitation. PathMTU Discovery is less of a perceived problem that traceroute, since usually anything that's broken will be broken on an edge router or tunnelling device of some sort rather than a core router, and core routers tend to all have the same values, but that still shouldn't force you to use registered address space.
RE: Cisco vulnerability and dangerous filtering techniques
On Wed, 23 Jul 2003, McBurnett, Jim wrote: Quick solution to this bug, as well as any future bug(s) replace all routers with PCs running Zebra. That is good until Zebra get's a bug and then someone will say go to XYZ... Macintosh running Zebra. Macs are as powerful as supercomputers, and they are inherently secure. Plus, who wouldn't give up the CLI for a candy-based interface that smiles at you? Pete.
RE: Cisco vulnerability and dangerous filtering techniques
On Wed, 23 Jul 2003, Pete Kruckenberg wrote: Plus, who wouldn't give up the CLI for a candy-based interface that smiles at you? Perhaps the guy sitting next to me who has had two seperate devices in the last couple of weeks that in order to be configured required Latest Java and Internet Exployer on Microsoft Windows to be running on his computer and *still* wern't stable.. -- Simon Lyall.| Newsmaster | Work: [EMAIL PROTECTED] Senior Network/System Admin | Postmaster | Home: [EMAIL PROTECTED] Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
