Re: 3 strikes - Interior Department ordered offline again
This is quite something. From Judge Lamberth's order, additional insight into the behavior of a contractor we know well: It is unfortunate, therefore, that Interior proposes that [e]ach bureau or office for which reconnection is intended will take steps to verify its representation that the IT system is secure from Internet access by unauthorized users. Interior Proposal at 7. In support, Interior plans to submit documentation to the Court that will incorporate the data necessary to support a riskbased decision on Internet reconnection. The assessment may include, as appropriate: (1) network mapping and enumeration; (2) SANS/FBI Top 20 Vulnerability List Comparison; (3) vulnerability assessment; and (4) penetration testing. Id. at 7. Interior further offers that the above assessment will be performed by Interior or its contractor. Id. at 7 n.9. Interiors current contractor is Science Applications International Corporation (SAIC). Id. at 8 n.11. As this Court already noted: SAIC is a contractor that is paid by the Interior Department and as such it cannot be considered to be a testing agency that operates independently of the Interior Department. 274 F.Supp.2d at 133. Furthermore, the Court observes that SAICs long history as an Interior contractor in this area and the simple fact that Interiors IT security remains poor makes this Court reticent to rely on their judgment. Allowing Interior or SAIC to provide the verification of representations made by its bureaus on the adequacy of their IT security does not offer this Court any party without a conflict of interest or a track record of incompetency and is an insufficient method of verifying IT security. The Courts desire is simple and specific. The Court wants Interior to propose and the Court to approve 1) an entity with no prior relationship to Interior, 2) that possesses the requisite expertise in IT security, 3) whose only work for Interior will be performing the tasks set forth for it in the preliminary injunction issued this date, and 4) who will report all its findings to the Court. The Court does not mandate that such an entity work for the Court, in fact they can be paid and supervised directly by Interior. In this regard the Court is now making and continues to make every effort to allow the department to manage its own affairs without Court intervention. But the Court must absolutely have an entity not tainted by the history of falsehoods and deceptions that has plagued this litigation, nor otherwise dependent upon Interior for its revenues and livelihood, to provide honest appraisals of the security of individual Indian trust data ... Interior truly brought this on themselves. Accordingly, the Office of Inspector General, the Minerals Management Service, the Bureau of Land Management, the Bureau of Reclamation, the Office of the Special Trustee, Fish and Wildlife, the Bureau of Indian Affairs, the Office of Surface Mining, and the National Business Center must disconnect all of their respective computer systems from the Internet. This includes every single IT system within that bureau whether or not that IT system houses or provides access to individual Indian trust data. In contrast, the National Park Service, the Office of Policy Management and Budget, and the United States Geological Survey do not have to disconnect any currently connected system from the Internet. Lastly, no system essential for the protection against fires or other threats to life or property should be disconnected from the Internet.
Re: AS3561 - lights are on but nobody's home?
Mike Lewinski [3/16/2004 8:17 AM] : I know that CW was supposed to close their US ops, and then it went to re-org and became CW America or something of the sort, but does anyone here have a clue as to their new support info? Because just a week or so ago 800-486-9932 got me to a real human for support, and now it just rings and rings. CW's US ops are being taken over by savvis.net I believe. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: Electrical Fire at 2nd + Federal Street
ok, power is back on. There's a big stinky charred mess in the street, but nothing too horrible. This is in San Francisco for those of you that missed that heh. On Mon, 15 Mar 2004, Tom (UnitedLayer) wrote: Apparently there's some PGE problem, and a possible electrical fire. It appears that 501 2nd street is on Generator, and several other businesses on federal and 2nd streets are out of power. Bryant street appears to have spotty power in the area. Anyone else know anything about this? --- Tom SparksUnitedLayer Office: 415-294-4111 AS23342
Re: who offers cheap (personal) 1U colo?
On Mon, 15 Mar 2004, Eric Brunner-Williams in Portland Maine wrote: Certianly the point central to your arguement is that with the right abuse-desk to customer ratio AND the right customer base, things could be kept clean for smtp/web/ftp/blah 'hosting'. I'll take the right customer base for $50 please Alex. which is NOT the current dsl/cable-modem user, obviously? This is most certainly the case... I look forward to seeing your list of providers and prices :) Rick Adams and Mike O'Dell had an idea in 1987. How is this any different? mumble, mumble giant telephone company mumble mumble... In all seriousness, I'm not sure this is any different. Their idea, if I got it right, was 'ip everywhere'. Perhaps providing smaller scale 'good' colo with strong abuse/support is possible, just don't get greedy and get gigantic. Paul, does your list include those providers that provide the hardware upfront also? or is part of your deal that the equipment comes from the customer so they are more willing to behave?
Replacement for a Extreme Black Diamond 6808
Can anyone suggest a good replacement for an Extreme Black Diamond 6808 switch, we use it for aggregation, however their support is abhorrant and every time we have an issue they require us to unconfigure the switch, reset it to defaults and manually reconfigure it, no matter what the problem is, the resolution is the same. Anyone have any suggestions? -Drew
Re: AS3561 - lights are on but nobody's home?
Burton, Chris wrote: I spoke with their NOC about 3 days ago @800.663.9932. Thanks to everyone for the fast responses... we did finally find a functional number (the above had a recording to call 800-486- which got the goods). Mike
Re: who offers cheap (personal) 1U colo?
Rick Adams and Mike O'Dell had an idea in 1987. How is this any different? actually rick had the idea by himself in 1987. mike came a bit later. Their idea, if I got it right, was 'ip everywhere'. in that most other companies still thought ISO/OSI was going to be the commercial protocol of choice, the idea (which was alternet, not the original 1987 uunet), yes, rick's idea was i'll bet you're all wrong and that IP will be the way commercial data networking actually builds out. Perhaps providing smaller scale 'good' colo with strong abuse/support is possible, just don't get greedy and get gigantic. the greed problems don't come in with customer base size but rather management team experience. once you get folks running the business who don't know the industry or the culture or the customers, they start to think in terms of margin pressure. a modern-uunet-sized abuse desk should cost about $2M a year, but would add nothing to revenue, so they don't have it. there's no reason you couldn't fill out a 20Ksqft colo room with personal 1U boxes, as long as you were willing to spend the same or more money per customer (on customer care issues) as you did when it was a half rack. that means your margin will not grow at the same speed as your revenues, and may actually shrink as a function of revenue growth. that in turn means that the founders will have to run it forever, you will not be able to rent a CEO who graduated business school and simultaneously defend the reputation of the colo and its IP address space. (go figure.) Paul, does your list include those providers that provide the hardware upfront also? or is part of your deal that the equipment comes from the customer so they are more willing to behave? under duress, i'm listing all three kinds (virtual, included, and BYO1U). note that the virtuals have got me quite concerned since there's NO evidence that a deposit is taken. spammers are going to have a field day with them, and i expect to have to drop them from the list, but first, we'll try it and hope for the best. -- Paul Vixie
Re: who offers cheap (personal) 1U colo?
[EMAIL PROTECTED] writes: And then there's the newer high-density rackmount units like http://www.rlx.com/products/serverblades/dense.php. This product puts up to 24 server blades in a 3U chassis which basically means you can put 8 times as many servers in a rack. sadly, the blade vendors don't want you to be able to buy your backplane from source A and your blades from sources B, C, and D. in this niche, people often already have a 1U or have a special way of getting one (like e-bay or office surplus), and they need plug and play at the colo level. when there's a blade standard that integrates power, perhaps cooling (liquid or conduction), network, and serial or other outofband console, then we might see blade servers used for personal colo boxes. until then the smallest standard interface is a 1U w/ DB9, 100baseTX, and 3prong power. And if any of you have played with things like the Zaurus C760/C860 then you know where all this is headed. $50/month today, $25/month in a year or two, and then in about 5 years it will be a free perk if you sign a two-year contract with your broadband provider. given the number of virtual hosters i've heard from, i don't think it'll end like that. ultimately it'll end with something very much like multics was planned to be. in fact this seems more likely than a standard blade interface. -- Paul Vixie
Re: who offers cheap (personal) 1U colo?
On Mon, 15 Mar 2004, John Kristoff wrote: There are certain environments where it would be nice for people to have spent some time. Working at a university would be one good experience for many people, particularly in this field, to have had. I fully agree...This is the one environment where you definately can't trust your users. Unlike most home markets and corporate markets. These kids often forget they are paying for service and thus abuse it. think of one university who requires students to login through a web portal before giving them a routable address. This is such a waste of In most implementations I'm familiar with, the time and effort is mostly spent in the initial deployment of such a system. I'm not referring to the time required to implement. I'm talking about the time it takes for the user. On the user end. Lets do some simple math. Lets say I turn on my laptop before I shower, I power it down during the day while I'm in class and I turn it back on when I get home in the evening. This means two logins per day. Lets say that the login process is very rapid and takes 30 seconds. This is a whole minute per day required to login. Now multiply this by a month and you've wasted 30 minutes of my time. I coulda spent that time watching TV or heaven forbid, doing homework. :) My big thing is that often users are the one who are paying the price and spending the time. I think either system (the mac-ip lookup or the user auth) system could be created in a week using C++ or perl. This week of development is nothing in the long run when compared to the amount of time it now costs the users. Come on, how many users save their mail passwords so they don't have to type it in everytime? What about your dialup password? Too bad I can't automate the web logins. I don't know a single normal (not one of us NANOG folks...) user who has not opted to save their WinXP password so they don't have to type it in everytime they reboot the computer. Andrew --- [EMAIL PROTECTED] http://www.andrewsworld.net/ ICQ: 2895251 Cisco Certified Network Associate Learn from the mistakes of others. You won't live long enough to make all of them yourself.
RE: who offers cheap (personal) 1U colo?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Dorsett Sent: March 15, 2004 11:17 PM To: John Kristoff Cc: [EMAIL PROTECTED] Subject: Re: who offers cheap (personal) 1U colo? I'm not referring to the time required to implement. I'm talking about the time it takes for the user. On the user end. Lets do some simple math. Lets say I turn on my laptop before I shower, I power it down during the day while I'm in class and I turn it back on when I get home in the evening. This means two logins per day. Lets say that the login process is very rapid and takes 30 seconds. This is a whole minute per day required to login. Now multiply this by a month and you've wasted 30 minutes of my time. I coulda spent that time watching TV or heaven forbid, doing homework. :) My big thing is that often users are the one who are paying the price and spending the time. I think either system (the mac-ip lookup or the user auth) system could be created in a week using C++ or perl. This week of development is nothing in the long run when compared to the amount of time it now costs the users. Come on, how many users save their mail passwords so they don't have to type it in everytime? What about your dialup password? Too bad I can't automate the web logins. You must be talking about a different Netreg system that the one everyone else has used. The one we're talking about involves you logging in when you connect with an unknown MAC - once you've used the system to match your MAC to your student number/login/etc, then the DHCP server will give you a real IP the next time you request a lease... Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic Network Services, Inc. http://www.dyndns.org/
RE: who offers cheap (personal) 1U colo?
On Mon, 15 Mar 2004, Vivien M. wrote: You must be talking about a different Netreg system that the one everyone else has used. The one we're talking about involves you logging in when you connect with an unknown MAC - once you've used the system to match your MAC to your student number/login/etc, then the DHCP server will give you a real IP the next time you request a lease... Yes I am... I am referring to a system which an unmentionable university has in place. It requires the user to enter their username and password each time the link state changes before they are allowed outside of the local lan. This is also similar to the new port authentication system on the Extreme Networks switches. It automatically delves out an address to the user so they can access a login portal and then it reissues them a legitimate address once they have been authenticated. This is a pretty slick setup for mobile users who connect in temporarily to public portals but it makes little sense in a fixed network environment of a dorm room or office. Andrew --- [EMAIL PROTECTED] http://www.andrewsworld.net/ ICQ: 2895251 Cisco Certified Network Associate Learn from the mistakes of others. You won't live long enough to make all of them yourself.
Re: iMPLS benefit
Please see inline. Yakov Rekhter wrote: Mark, i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS). ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt See also Mark's talk from the last NANOG http://nanog.org/mtg-0402/townsley.html That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors). The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE. I guess you are *not* aware of the Redback implementation of 2547 over GRE, as this implementation is (a) available today, (b) interoperable with other implementations of 2547 over GRE, and (c) does *not* require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE. And, just for the record, (stating the obvious) I don't work for Redback. Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? (Just guessing as the principal author used to work for Redback). Thanks for the update, I was in fact not aware that companies other than Redback had implemented it. You didn't name those companies, but I will happily stand corrected here. In any case, the point I was trying to make was that there is more than one way to do MPLS over GRE and that they are not all necessarily interoperable as you seemed to imply in your message. You have helped to make that quite clear. The BGP extension defined in the draft below allows iMPLS for 2547 VPN support without requiring any manually provisioned tunnels (and works for mGRE or L2TPv3). http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt The question to ask is whether the extension you mentioned above is truly necessary for supporting 2547 over GRE. The Redback implementation I mentioned above is an existence proof that the extension is *not* necessary for 2547 over GRE that does *not* involve manually provisioned GRE tunnels. Both draft-nalawade-kapoor-tunnel-safi-01.txt and draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt use BGP to advertise capabilities for carrying MPLS-labeled packets over various encapsulation types. Proof of one is essentially proof for the other, though the existence of both definitions highlights an unfortunate interoperability concern (particularly so for GRE, since each identify slightly different ways to advertise MPLS over GRE). If you are not advertising capabilities at all, then you either have to maintain a list of which PEs can and will perform 2547 over GRE (and we are back to manual provisioning of tunnels), or you have to assume that ALL will in precisely the same way (eliminating all native MPLS processing for PEs that are reachable via MPLS directly). Note that mGRE (multipoint GRE) is *not* the same as the point-to-point GRE method that Yakov is referring to. Same header, different usage. Enabling MPLS over any type of IP tunnel changes the security characteristics of your 2547 deployment, in particular with respect to packet spoofing attacks. The L2TPv3 encapsulation used with the extension defined above provides anti-spoofing protection for blind attacks (e.g., the kind that a script kiddie could launch fairly easily) with miniscule operational overhead vs. GRE which relies on IPsec. GRE relies on IPSec in *some*, but *not all* cases. Another alternative is to use packet filtering. Quoting from the 2547 over GRE spec: Protection against spoofed IP packets requires having all the boundary routers perform filtering; either filtering out packets from outside which are addressed to PE routers, or filtering out packets from outside which have source addresses that belong inside and filtering on each PE all packets which have source addresses that belong outside. And the same paragraph goes on to say: The maintenance of these filter lists can be management-intensive, and the their use at all border routers can affect the performance seen by all traffic entering the SP's network. So, 2547 over GRE without IPsec relies upon a valid source/dest IP check for each packet at all boundary points in the network. Rather than rely only on this, the 2547 over L2TPv3 encapsulation defines its own (randomly selected and advertised along with the tunnel capabilities for that PE) 64-bit value to be validated before processing a packet at the router which is actually performing the 2547 VPN service. Both of these methods are filtering on cleartext header information in order to avoid the complexity and overhead of IPsec while inhibiting script-kiddie-like IP spoofing attacks attempting to infiltrate a VPN, but 2547 over L2TPv3 gets around the concerns with
Re: iMPLS benefit
Mark, Please see inline. in-line... i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS). ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-0 1.txt See also Mark's talk from the last NANOG http://nanog.org/mtg-0402/townsley.html That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors). The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE. I guess you are *not* aware of the Redback implementation of 2547 over GRE, as this implementation is (a) available today, (b) interoperable with other implementations of 2547 over GRE, and (c) does *not* require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE. And, just for the record, (stating the obvious) I don't work for Redback. Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? (Just guessing as the principal author used to work for Redback). Thanks for the update, I was in fact not aware that companies other than Redback had implemented it. You didn't name those companies, but I will happily stand corrected here. No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt. Redback's implementation that does not require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE is *purely* an implementation matter, and does *not* require any new communities and/or attributes. In any case, the point I was trying to make was that there is more than one way to do MPLS over GRE and that they are not all necessarily interoperable as you seemed to imply in your message. You have helped to make that quite clear. The BGP extension defined in the draft below allows iMPLS for 2547 VPN support without requiring any manually provisioned tunnels (and works for mGRE or L2TPv3). http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt The question to ask is whether the extension you mentioned above is truly necessary for supporting 2547 over GRE. The Redback implementation I mentioned above is an existence proof that the extension is *not* necessary for 2547 over GRE that does *not* involve manually provisioned GRE tunnels. Both draft-nalawade-kapoor-tunnel-safi-01.txt and draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt use BGP to advertise capabilities for carrying MPLS-labeled packets over various encapsulation types. Proof of And *neither* of these are requires in order to avoid manual provisioning of point-to-point GRE tunnels. Yakov.
Re: iMPLS benefit
Yakov Rekhter wrote: No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt. Redback's implementation that does not require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE is *purely* an implementation matter, and does *not* require any new communities and/or attributes. OK, you made me go out to www.redback.com and read about their implementation. A quote: This means that the ingress router can learn these next-hop addresses through MP-BGP, and then dynamically append the GRE encapsulation and outer IP header to a VPN packet destined for an egress router. In essence, these GRE tunnels can be considered as soft or dynamic because they do not need to be configured. Whether it is implicit from the next-hop address in BGP, or explicit in the next-hop update via draft-nalawade-kapoor-tunnel-safi-01.txt or draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt, we are still talking about MP-BGP as the vehicle for advertising how to reach a PE by GRE. We now have identified three variants for MPLS over GRE in this thread, (outside of manually configured hard GRE tunnels) -- back to my original point that MPLS over GRE can mean a lot of things. IMHO, a PE explicitly identifying that it can receive MPLS over GRE (or MPLS over foo) traffic is a bit safer and more deterministic than implicitly assuming it can from a learned next-hop address. I don't want to speak for another company, but perhaps Redback did too which is why they helped sponser draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt in the first place. Go knock on Rahul's cube now that the two of you work at the same company and ask him ;-) - Mark
Re: iMPLS benefit
Mark, [clipped...] Enabling MPLS over any type of IP tunnel changes the security characteristi cs of your 2547 deployment, in particular with respect to packet spoofing attacks. The L2TPv3 encapsulation used with the extension defined above provides anti-spoofing protection for blind attacks (e.g., the kind that a script kiddie could launch fairly easily) with miniscule operational overhead vs. GRE which relies on IPsec. GRE relies on IPSec in *some*, but *not all* cases. Another alternative is to use packet filtering. Quoting from the 2547 over GRE spec: Protection against spoofed IP packets requires having all the boundary routers perform filtering; either filtering out packets from outside which are addressed to PE routers, or filtering out packets from outside which have source addresses that belong inside and filtering on each PE all packets which have source addresses that belong outside. And the same paragraph goes on to say: The maintenance of these filter lists can be management-intensive, and the their use at all border routers can affect the performance seen by all traffic entering the SP's network. When talking about impact of packet filtering on the performance it is important to keep in mind that this is really an *implementation* issue. Moreover, we have an existence proof (means products on the market) that support packet filtering at line rate, with *no* adverse impact on forwarding performance. And while the maintenance of these filters certainly imposes an additional operational overhead, such filters may be requires for reasons other than protection against spoofing of VPN packets, in which case the *additional* operational overhead of using these filters to protect (among other things) against spoofing of VPN packets may be of no practical significance. Yakov.
