PathControl vs. Internap(hardware)
Has anyone done any comparisons recently? I know that RouteScience changed their model of not providing the hardware anymore, but I was overall satisfied with their product when I had it before. Has anyone stacked the Internap (former NetVMG/Sockeye) soft against the PathControl software? What were your impressions if so? Thanks, -Dave
Philadelphia MCI/UU PoP?
Does anyone know the address of the Philadelphia MCI/UU (legacy?) POP? Replies off list are fine. Thanks, -Dave
RouteScience PathControl vs. Radware Linkproof
Looking for anyone who's done a direct comparison of the two (I understand the way they fundamentally work is completely different, however they both try to achieve the same thing). I'm doing my own bake-off here and I'd like to hear others' opinions. Direct replies are OK Thanks, -Dave
Re: Misplaced flamewar... WAS: RE: in case nobody else noticed it, there was a mail worm released today
On Wednesday 28 January 2004 08:37, Dave Temkin wrote: So? Had the virii been an application compiled for RedHat and everyone ran RedHat instead of Windows and they downloaded it using Evolution and double clicked on it, it would suddenly be RH's fault instead of MIcrosoft's? If RedHat, by default had you running as root rather than an unprivledged user, it sure would be. Most Windows boxes are running with administrative privledges. That makes Windows a willing accomplice. The issue isn't that people click on attachments, but that there are no built in safeguards from what happens next. -- Robin Lynn Frank | Director of Operations | Paradigm-Omega, LLC Cry havoc, and let slip the dogs of war! Email acceptance policy: http://paradigm-omega.com/email_policy.php You're the second person to say that and it's still wrong. The virii, once resident, opens a connection to port 25 on an open SMTP server, whether it be the user's ISP relay or local server. Sure, it can't install itself into /etc/init.d, but it sure can launch itself bg instead of fg and be running until the user either kills it or reboots the box. Also, for reference to other people - the preview pane does *not* allow the execution of attachments unless they're double-clicked on and acknowledged. Again - we're not talking about another OS or Outlook exploit, only a stupid user exploit. -- David Temkin
Re: Misplaced flamewar... WAS: RE: in case nobody else noticed it, there was a mail worm released today
: Also, for reference to other people - the preview pane does *not* allow : the execution of attachments unless they're double-clicked on and : acknowledged. Again - we're not talking about another OS or Outlook : exploit, only a stupid user exploit. The feature has been fixed but it **did** at one point run apps. James Edwards Routing and Security Administrator [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965 Right, and at multiple points bind and sendmail allowed the execution of code from remote systems without the system owner interacting at all. What's that got to do with today? -- David Temkin
Re: Misplaced flamewar... WAS: RE: in case nobody else noticed it, there was a mail worm released today
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of james Sent: Wednesday, January 28, 2004 4:02 PM To: [EMAIL PROTECTED] Subject: Re: Misplaced flamewar... WAS: RE: in case nobody else noticed it, there was a mail worm released today : What's that got to do with today? I might be reaching here, but I understand some people never upgrade or patch. True, but that happens regardless of the OS. I'm sure if we looked really hard we could find some ancient versions of bind or sendmail (complete with open relays (speak of old bad defaults...)
Contact from Google urgently needed
If anyone on the list is employed by Google please contact me ASAP. I've sent emails to [EMAIL PROTECTED] and haven't gotten a response. There's nothing on the NOC list for Google. Thanks, -Dave
Re: AOL rejecting mail from IP's w/o reverse DNS?
You mean like Level3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Wednesday, December 03, 2003 2:27 PM To: Matthew Crocker Cc: Christopher X. Candreva; [EMAIL PROTECTED] Subject: Re: AOL rejecting mail from IP's w/o reverse DNS ? In message [EMAIL PROTECTED], Matthew Crocker AOL says the PTR record needs to be assigned. It doesn't specify it has to match the @domain.com in the MAIL FROM: header. Wouldn't it be enough to make sure every IP address you announce has a PTR and matching A record? Hasn't this been a requirement for MANY services for MANY years? Right -- and then folks will start creating wildcard PTR records... --Steve Bellovin, http://www.research.att.com/~smb -- David Temkin
Google-jacking?
Has anyone seen a situation on their internal networks where going to a (non-Google) page Hijacks them and they end up with either the Google front page or a broken link page? This happens on machines both with the toolbar and without, and we've seen it on machines on different networks/running different OS's. Just curious. Thanks, -Dave
Re: Google-jacking?
FWIW, it's not a virus, it's something infrastructure related. All of the systems that I've seen this on have all the latest DAT's and the proxy servers it sits behind are virus scanning as well (for both email and web) and use alternate vendors On Mon, 1 Dec 2003, Dave Temkin wrote: Has anyone seen a situation on their internal networks where going to a (non-Google) page Hijacks them and they end up with either the Google front page or a broken link page? This happens on machines both with the toolbar and without, and we've seen it on machines on different networks/running different OS's. Just curious. Thanks, -Dave
US LEC?
Does anyone have any experience in dealing with US Lec? I'm working with a FastNet customer who's been sold to them in FSST's bankruptcy. We have other connectivity in the meantime. Thx, -Dave
Re: Carriers using CES in the wild?
Actually I was moreso looking to see if any of the major carriers were doing it on the sly, ie, selling it as point-to-point TDM but instead it was CES Thanks, -- David Temkin On Thu, 24 Jul 2003, Jared Mauch wrote: On Thu, Jul 24, 2003 at 09:50:30PM -0400, Dave Temkin wrote: Is anyone aware of any carriers that are using CES as a transport method as private line and aren't necessarily selling it as such? (ie, I've ordered a DS-3 from point A to point B, and instead of the carrier dropping it as standard TDM it's CES through their network...) What you are speaking of is most likely what juniper calls CCC. L2 transport over their network. Not too dificult to set up but as usual the complications come in the realm of redundancy and network reconvergence. I'd pay close attention to the SLA offered, but it is probally similar to what is seen in a TDM network if they employ mpls fast reroute .. and if you're doing IP over this circuit, you will probally be less likely to notice any problems. - Jared
Carriers using CES in the wild?
Is anyone aware of any carriers that are using CES as a transport method as private line and aren't necessarily selling it as such? (ie, I've ordered a DS-3 from point A to point B, and instead of the carrier dropping it as standard TDM it's CES through their network...) Thanks, -- David Temkin
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: 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
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
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.)
