The TOS/AUP for most residential broadband connections already allows the ISP to shut off service or do anything they want to the customer without prior notice. It has been this way for at least 3 or 4 years, since the advent of @Home. Take a look at the TOS/AUP for Comcast, Shaw Cable, MSN DSL or similar...
Second, in the acceptable use policy for high speed connections, require a "licence" of some kind. We have licenses/permits for our cars, our dogs, our burglar alarms, for going fishing,..... Why not for broadband. Actually I can see many reasons both to do it and not to do it, so this is clearly an area where debate is reasonable.
I know they CAN, but the issue is do they have the mechanisms and operational capabilities of actually doing so? I would like to see my cable provider making it hard to do some of the things I do. Not because I should not be doing them, but those same holes that I exploit (hopefully in a benign fashion) can be used with malicious intent. By saying, "If you want to use our service then you must deply this kind of modem/router" at least makes their insistence explicit. Currently there is more arm waving than actual adherence to security policy. Thus we have many poorly configured Windows boxes accessing the internet (and the WWW) in manners which are to the detriment of everyone else.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Eric Kuhnke Sent: Friday, October 10, 2003 7:06 PM To: nanog@merit.edu Subject: RE: Block all servers?
The TOS/AUP for most residential broadband connections already allows the ISP to shut off service or do anything they want to the customer without prior notice. It has been this way for at least 3 or 4 years, since the advent of @Home. Take a look at the TOS/AUP for Comcast, Shaw Cable, MSN DSL or similar...
Second, in the acceptable use policy for high speed connections, require a "licence" of some kind. We have licenses/permits for our cars, our dogs, our burglar alarms, for going fishing,..... Why not for broadband. Actually I can see many reasons both to do it and not to do it, so this is clearly an area where debate is reasonable.
IMHO, all consumer network access should be behind NAT. However, the real solutions is (and unfortunately to the detriment of many 3rd party software companies) for operating system companies such as Microsoft to realize a system level firewall is no longer something to be "added on" or configured later. Systems need to be shipped completely locked down (incoming *and* outgoing IP ports), and there should be an API for applications to request permission to access a particular port or listen on a particular port (invoking a user dialog). As for plug-in "workgroup" networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC. Currently Windows 2000 can be configured to be extremely secure without any additional software. Unfortunately you must have a *lot* of clue to configure the Machine and IP security policies it provides. Adam
On Fri, 10 Oct 2003, Adam Selene wrote:
IMHO, all consumer network access should be behind NAT.
Unfortuantely there are enough protocols and applications which don't work well behind a NAT that deploying this on a large scale is not practical. Most gamers require incoming connections. These are people who willing to pay for bandwidth so attempting to put them in the "nat only" box will not work. Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation?
However, the real solutions is (and unfortunately to the detriment of many 3rd party software companies) for operating system companies such as Microsoft to realize a system level firewall is no longer something to be "added on" or configured later. Systems need to be shipped completely locked down (incoming *and* outgoing IP ports), and there should be an API for applications to request permission to access a particular port or listen on a particular port (invoking a user dialog).
Unfortunately something like this would make the PC close to useless which is not the intent of the software provider. Thus you see everything open, security be damned.
As for plug-in "workgroup" networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC.
And joe user will understand this because.....
Currently Windows 2000 can be configured to be extremely secure without any additional software. Unfortunately you must have a *lot* of clue to configure the Machine and IP security policies it provides.
And there lies your problem (among other places).... bye, ken emery
In message <Pine.LNX.4.44.0310110741350.20543-100000@s1.yuriev.com>, Alex Yurie v writes:
Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation?
IPSEC works over NATs just fine.
Not in the general case, no. See draft-aboba-nat-ipsec-04.txt if you can find a copy. --Steve Bellovin, http://www.research.att.com/~smb
On Sat, 11 Oct 2003, Steven M. Bellovin wrote:
In message <Pine.LNX.4.44.0310110741350.20543-100000@s1.yuriev.com>, Alex Yurie v writes:
Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation?
IPSEC works over NATs just fine.
Not in the general case, no. See draft-aboba-nat-ipsec-04.txt if you can find a copy.
This internet draft is available at: http://quimby.gnus.org/internet-drafts/draft-aboba-nat-ipsec-04.txt I can't figure out if anything happened with this draft (I'm guessing nothing went on). The draft expired on December 1, 2001. bye, ken emery
This internet draft is available at: http://quimby.gnus.org/internet-drafts/draft-aboba-nat-ipsec-04.txt
Ken Emery wrote:
I can't figure out if anything happened with this draft (I'm guessing nothing went on). The draft expired on December 1, 2001.
IPSec NAT Traversal is still being standardized, but has already been implemented in a good number of products. Current drafts: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-05.txt Jon Lewis wrote:
But why all this talk of NAT? Even if we all universally deployed it on monday, it wouldn't solve the problem. All it would do is keep the spammer/hackers from turning grandma's PC into a web server/proxy.
As well as preventing infection from worms like Blaster, and so forth. It's hard to imagine one solution solving the entire laundry list of problems. One step at a time. That being said, NAT does break stuff and as has been mentioned, filtering is certainly possible without having to bring NAT into the mix. Microsoft assures us that the Windows firewall will be enabled by default starting with WinXP patches early next year. How easy will it be to turn it off? Will a virus be able to do it for you? -Terry
Terry Baranski wrote:
That being said, NAT does break stuff and as has been mentioned, filtering is certainly possible without having to bring NAT into the mix. Microsoft assures us that the Windows firewall will be enabled by default starting with WinXP patches early next year. How easy will it be to turn it off? Will a virus be able to do it for you?
I would expect most new sophisticated trojans to include this functionality. Most home users run their WinXP with "Local Administrator" rights anyway because othervise many activities would be more complicated to accomplish. Many turn off AV products already. I would also expect the sophisticated trojans to include NATPT like funcitionality when it becomes neccessary to accumulate the needed number of zombies for effective DDoS and other distruptive activities. We already see them utilizing the local SMTP configuration on the machine to use the relays the user is supposed to. The Road Ahead is to make DDoS and abuse mitigation more efficient and put some real security into the application architechtures without making them unusable. Pete Pete
Unfortuantely there are enough protocols and applications which don't work well behind a NAT that deploying this on a large scale is not practical.
It already is deployed upon a large scale. When I had @Home in Seattle (one of the first subscribers), I had a 10.x address. Here in Costa Rica, broadband (cable modem) connections for the entire country are behind NAT.
Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation?
I use IPSEC and it works fine behind NAT.
Unfortunately something like this would make the PC close to useless which is not the intent of the software provider. Thus you see everything open, security be damned.
No. You default open the common and popular internet ports for outbound, and 90% of users never use anything else.
As for plug-in "workgroup" networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC.
And joe user will understand this because.....
That's the point, he doesn't have to. A "workgroup" becomes a name + a key/phassphrase instead of just a name. What that accomplishes is completely hidden. Adam
On Sat, 11 Oct 2003, Adam Selene wrote:
Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation?
I use IPSEC and it works fine behind NAT.
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance. bye, ken emery
On Sat, Oct 11, 2003 at 08:28:11AM -0700, ken emery wrote:
I use IPSEC and it works fine behind NAT.
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance.
why not? We use it here, works fine (with certificates for auth). tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA
Stefan Mink wrote:
On Sat, Oct 11, 2003 at 08:28:11AM -0700, ken emery wrote:
I use IPSEC and it works fine behind NAT.
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance.
why not? We use it here, works fine (with certificates for auth).
OK, let's do this one more time. Many-to-one NAT of a many-to-one ESP VPN does not work. (Period) Why? There is no way for the NAT device to map the ESP packets to the nodes it "hides." You say, "The SPI field is perfect for maintaining a translation table!" It would be accept for one very big problem. IPsec is a peer-to-peer protocol. Either side may renegotiate the SAs at any time. While using IKE[0], the SPI passes the NAT device in the _encrypted_ payloads. The NAT device never sees the SPI until the ESP starts flowing. Also, keep in mind the SPI is _not_ symmetric. So, now we have two machines behind a NAT device, and both want to have an ESP VPN to the same machine. What does the NAT device do when it receives an ESP packet from the exterior end of the ESP VPN tunnel? How does it decide which of the internal ends to send it to? The SPI has nothing to do with the outgoing SPIs (if it even has seen any outgoing ESP yet). It cannot pull the SPI out of the IKE. You can try timing, if it's a new SPI, try sending it to the last one that had a IKE conversation, but that is a guess, what happens if two happen to negotiate at once? And if you guess wrong, things do not fail and recover for the VPN players. So, you cannot NAT ESP in the general case. Thus we have all of the rather grotesque kludges of wrapping the ESP in another transport layer of UDP or TCP so that the NAT devices have some port numbers to play with. If your IPsec VPN works through NAT, the NATer is making some assumptions (usually it only will support a single IPsec end point behind it which solves the "who do I send the ESP to" problem) or your VPN software has a Draft or vendor kludge to wrap the IPsec in something more NAT friendly. Note again that "NAT" above implies "many-to-one NAT." This problem disappears in a one-to-one NAT configuration where only authentication and integrity issues, which can be dealt with within IPsec, come into play. If someone has figured out a way around this, I would love to hear about it. [0] The fact you don't need to use IKE to set up SAs makes the problem even more intractable. A NAT device would have to know of every possible way to configure SPIs. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On Tue, Oct 14, 2003 at 10:07:45AM -0700, Crist Clark wrote:
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance.
why not? We use it here, works fine (with certificates for auth).
OK, let's do this one more time. Many-to-one NAT of a many-to-one ESP VPN does not work. (Period)
I'm doing a shortcut here: I didn't want to say I'm using "pure standard IPsec" (2401/2409) here. For me extensions like NAT-T or DPD are part of IPsec too although they are still in the draft state. They just make IPsec more usable as in this case here... I know the additional encapsulation isn't a nice thing with NAT-T but at least it works :] (don't look at L2TP via IPsec if you don't like additional encapsulations - nevertheless it seems to be the future of Windows-VPNs :( ). tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA
At 6:30 PM +0200 10/14/03, Stefan Mink wrote:
On Sat, Oct 11, 2003 at 08:28:11AM -0700, ken emery wrote:
I use IPSEC and it works fine behind NAT.
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance.
why not? We use it here, works fine (with certificates for auth).
From what I've seen it depends on whether the NAT has specific support for IPSEC, and if that support includes support for multiple clients. The NAT box has to keep track of the mapping. I've seen NATs priced based on how many VPN clients they support at a time. See http://www.dslreports.com/faq/4638 -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Kee Hinckley wrote:
At 6:30 PM +0200 10/14/03, Stefan Mink wrote:
On Sat, Oct 11, 2003 at 08:28:11AM -0700, ken emery wrote:
I use IPSEC and it works fine behind NAT.
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance.
why not? We use it here, works fine (with certificates for auth).
From what I've seen it depends on whether the NAT has specific support for IPSEC, and if that support includes support for multiple clients. The NAT box has to keep track of the mapping. I've seen NATs priced based on how many VPN clients they support at a time.
Quoting from that, Some routers permit multiple IPSec connections through NAT by uniquely identifying tunnels via the pair of SPI numbers snagged from an IKE exchange. These identifying numbers are stored in IPSec NAT table entries to allow correct routing of inbound ESP traffic. Last time I looked, the SPIs are exchanged in an encrypted payload in IKE. Am I mistaken? The router would have to mount a successful MIM attack to do this. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
In message <3F8C57B5.6F4F2C50@globalstar.com>, Crist Clark writes:
Kee Hinckley wrote:
At 6:30 PM +0200 10/14/03, Stefan Mink wrote:
On Sat, Oct 11, 2003 at 08:28:11AM -0700, ken emery wrote:
I use IPSEC and it works fine behind NAT.
Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance.
why not? We use it here, works fine (with certificates for auth).
From what I've seen it depends on whether the NAT has specific support for IPSEC, and if that support includes support for multiple clients. The NAT box has to keep track of the mapping. I've seen NATs priced based on how many VPN clients they support at a time.
Quoting from that,
Some routers permit multiple IPSec connections through NAT by uniquely identifying tunnels via the pair of SPI numbers snagged from an IKE exchange. These identifying numbers are stored in IPSec NAT table entries to allow correct routing of inbound ESP traffic.
Last time I looked, the SPIs are exchanged in an encrypted payload in IKE. Am I mistaken? The router would have to mount a successful MIM attack to do this.
You're completely correct. NATs can only handle this by heuristics; they can't handle the situation where more than one host behind it is communication via IPsec with the same destination. --Steve Bellovin, http://www.research.att.com/~smb
On Fri, Oct 10, 2003 at 08:07:05PM -0600, Adam Selene wrote:
IMHO, all consumer network access should be behind NAT. -snip- As for plug-in "workgroup" networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC.
These two requirements are mutually exclusive outside of a LAN environment, and if you're on a LAN, why require IPSEC? Filtering or NAT do not protect you from bad implementation or bad protocol design. Penalizing users that need (and will pay) for reasonably accessible two way communication is not the answer, and never will be. --msa
Penalizing users that need (and will pay) for reasonably accessible two way communication is not the answer, and never will be.
By all means, make a non-NAT IP address a optional premium service, and hope those that request it are sophisticated enought to secure their machine. Adam
Adam Selene wrote:
By all means, make a non-NAT IP address a optional premium service, and hope those that request it are sophisticated enought to secure their machine.
NAT is more expensive to produce, so it should be an optional premium service, and that seems to be more and more the case. Pete
NAT is more expensive to produce, so it should be an optional premium service, and that seems to be more and more the case.
Not necessarily when you consider the cost (in bandwidth, network reliability and support staff) imposed by worms and kiddies from other networks scanning your IP space for unsecured machines. That's not even to mention the cost imposed by compromised systems. Even if NAT only reduces compromised systems by 20%, that's a cost savings. Given that most edge hardware supports NAT, the additional cost is nominal. Getting IP space allocation is not without cost either. Adam PS. Is this off-topic for NANOG? If so, I apologize. Given my networks are repeatedly the victim of distributed DoS attacks from compromised machines on other networks, it seemed relevant to me.
Adam Selene wrote:
NAT is more expensive to produce, so it should be an optional premium service, and that seems to be more and more the case.
Not necessarily when you consider the cost (in bandwidth, network reliability and support staff) imposed by worms and kiddies from other networks scanning your IP space for unsecured machines.
NAT boxes are quite unreliable, specially large ones. If you say "put 100000 small ones instead", that really sounds a support nightmare. And you can filter without having NAT. (a long time ago NAT was thought to be a security mechanism, that has fortunately mostly died out)
That's not even to mention the cost imposed by compromised systems. Even if NAT only reduces compromised systems by 20%, that's a cost savings.
For the price of a large NAT box, you can buy better security mitigation products which would allow you to get the wilful spammers, trojaned machines, etc. which are not saved by your magic box.
Given that most edge hardware supports NAT, the additional cost is nominal.
My operational experience tells quite a different story.
Getting IP space allocation is not without cost either.
That´s nothing compared to the people complaining about their applications not working because you want to break their packets. Pete
Adam Selene wrote:
IMHO, all consumer network access should be behind NAT.
First of all, this would block way too many uses that currently actually sell the consumer network connections. "I recommend my competition to do this" Secondly, it´s very hard, if impossible to come up with a NAT device which could translate a significant amount of bandwidth. Coming up with one to put just a single large DSLAM behind is tricky. (OC-12 level of bandwidth) NAT devices which do OC12 or near don´t come cheap either. This is (fortunately) not a cost you can sink to the customer as added value. "Because we lack clue and technology, we just block you for anything and make you pay for it".
However, the real solutions is (and unfortunately to the detriment of many 3rd party software companies) for operating system companies such as Microsoft to realize a system level firewall is no longer something to be "added on" or configured later. Systems need to be shipped completely locked down (incoming *and* outgoing IP ports), and there should be an API for applications to request permission to access a particular port or listen on a particular port (invoking a user dialog).
Don´t underestimate the painfully slow rate of change in widely deployed systems. There is a lot of software out there which dates back 15 years or more. Can you afford to wait even five? Hardly any of the issues we see today would go away if such an API would be enforced on the applications because the issues are due to the legitimate applications legitimately talking to the network with permission.
As for plug-in "workgroup" networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC.
This is not a bad idea at all. Make sure to save a copy of this message in case somebody tried to patent this.
Currently Windows 2000 can be configured to be extremely secure without any additional software. Unfortunately you must have a *lot* of clue to configure the Machine and IP security policies it provides.
The box should have a sticker "needs a resident computer mechanic" :) Pete
NAT at the end of OC12 sounds hideous indeed. That's why I would prefer to see it as part of the modem in the house/business. I am sure (by guesswork and not by statistics) that a very large number of users would need relatively simple and secure systems. I guess this because of the way I see a lot of equipment being used in the groups I talk to. Does that mean that "one size fits all?" No of course not. Just in the same way that one car type fits all. If it did, wouldn't Skodas be looking great right about now?! Of course from an ISP or other provider's point of view, uniformity/standardization allows costs to be driven downwards. So in order to keep costs handled, a non-customizable service is the order of the day. By making the NAT router a part of the cable modem at least there is a lesser chance that a large number of people who want a simple network connection will have any trouble at all. Perhaps posting a security bond would be an interesting way of overcoming some behaviors. General society appears to have strong financial motivations ("look what I can get for free (theft) by downloading music", etc.) Well make the standard service cheap, and add the premium features by control of the NAT router inside the modem from the support center. Remember that access is a privilege not a right. Of course as soon as you attempt to control a box from outside, that is throwing down the gauntlet to the malcommunity. So the NATRouter/Modem combo would have to be a bit clever. That of course may drive cost up...... As people who inhabit the network space, I think we do have some responsibilities to encourage the directions that service provider choose. If this isn't a good idea, what is? If we assume the following then we are forced to think broadly: Most PCs that people buy are configured too broadly with too many services open and are thus vulnerable. Most people do not want to mess with keeping their systems safe (for a variety of reasons). Most people have become accustomed to relatively inexpensive access Most people have "brothers-in-law" who know a bit about computers and can royally screw things up! Most people know a "really bright 12 year old" who can do "very clever things with the computer that I can't understand" Many people assume facility with some terminology and fast typing to be indicators of knowledge and responsibility. Many people do the computing equivalent of throwing trash out of the car window - i.e. not taking any responsibility for polluting the environment. These sociological phenomena demand that those who provide the services provide them responsibly or face the consequences. Sadly the consequences are societal in impact and don't just affect the providers. How much benefit would we get if we were to reduce the number of computers that could possibly be infected with something by 50%, 75%? How much benefit could we get by knowing which networks were potentially vulnerable - because they chose to open things up. I realize that we have a long way to go to get security. It is a bit like when cars first came out - we could/would drive anywhere. Eventually we agreed that we, in a given country, would drive on a particular side of the road. There is no obviously good reason why it should be one side or the other (as successful drivers in the UK and the US would agree!), but pick one. Once that happened, then some of the chaos disappeared. There is a (possibly true) story that when telephone adoption rates were analyzed in the 1930s, predictions were that every person in the US would have to be a telephone operator to keep up with the manual connecting of calls through plug-switchboards. The expected cross-over was sometime in the 1950s. Well, with the advent of Subscriber Trunk Dialing we are all telephone operators today! I see the same things happening in the computing world, we are all going to have to be network operators and sesames at some point! Sadly those interfaces are not as easy and standard as the familiar phone keypad! Chris
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Petri Helenius Sent: Saturday, October 11, 2003 1:47 AM To: nanog@merit.edu Subject: Re: Block all servers?
Adam Selene wrote:
IMHO, all consumer network access should be behind NAT.
First of all, this would block way too many uses that currently actually sell the consumer network connections. "I recommend my competition to do this"
Secondly, it´s very hard, if impossible to come up with a NAT device which could translate a significant amount of bandwidth. Coming up with one to put just a single large DSLAM behind is tricky. (OC-12 level of bandwidth)
NAT devices which do OC12 or near don´t come cheap either. This is (fortunately) not a cost you can sink to the customer as added value. "Because we lack clue and technology, we just block you for anything and make you pay for it".
However, the real solutions is (and unfortunately to the detriment of many 3rd party software companies) for operating system companies such as Microsoft to realize a system level firewall is no longer something to be "added on" or configured later. Systems need to be shipped completely locked down (incoming *and* outgoing IP ports), and there should be an API for applications to request permission to access a particular port or listen on a particular port (invoking a user dialog).
Don´t underestimate the painfully slow rate of change in widely deployed systems. There is a lot of software out there which dates back 15 years or more. Can you afford to wait even five?
Hardly any of the issues we see today would go away if such an API would be enforced on the applications because the issues are due to the legitimate applications legitimately talking to the network with permission.
As for plug-in "workgroup" networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC.
This is not a bad idea at all. Make sure to save a copy of this message in case somebody tried to patent this.
Currently Windows 2000 can be configured to be extremely secure without any additional software. Unfortunately you must have a *lot* of clue to configure the Machine and IP security policies it provides.
The box should have a sticker "needs a resident computer mechanic" :)
Pete
Didn't susan ask for this topic to move off-list? Anybody (no...not Merit) care to step up and create a nanog-issues list where such discussions can continue unmolested when the nanog topic police declare an important topic off-topic? I can understand how some operators might not want to hang out with the masses in spam-l or spam-tools, or waste their time with the noise and kooks in nanae. But these are some pretty serious problems and if we can't come up with solutions soon, the internet is pretty much totally screwed. See more below.... On Sat, 11 Oct 2003, Petri Helenius wrote:
Secondly, it´s very hard, if impossible to come up with a NAT device which could translate a significant amount of bandwidth. Coming up with one to put just a single large DSLAM behind is tricky. (OC-12 level of bandwidth)
So do the NAT closer to the edge. If you're providing DSL, do many of your customers use DSL modems plugged into their PCs (USB, PCI)?, or are you selling/leasing them DSL routers? In the very beginning, we either sold or gave PCI or USB DSL modems to our customers, but those were usually a PITA to support due to problems with windows, driver issues, hardware becoming unsupported when customers upgraded to the next version of windows, etc. Now, we only hook up DSL customers using DSL routers, and all the DSL routers we've ever used can do NAT, so there'd be no need to try to do NAT at the DSL agg router. I suspect we could selectively do NAT or not for dial-up customers on our access-servers...though I'm not sure how the very large (like AS5400, AS5800) units would fare trying to do NAT for several hundred dial-up sessions. But why all this talk of NAT? Even if we all universally deployed it on monday, it wouldn't solve the problem. All it would do is keep the spammer/hackers from turning grandma's PC into a web server/proxy. She can still catch tuesday's email virus which will cause her PC to hang out in some IRC channel or monitor some web page, and be remotely controlled for the purpose of sending spam, participating in DDoS floods...and now things just got much harder to track down. When you get complaints that a.b.c.d is participating in some kind of attack, how do you tell which of the dozens or hundreds of customers NAT'd to that IP is responsible/infected? ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
participants (13)
-
Adam Selene -
Alex Yuriev -
Christopher Bird -
Crist Clark -
Eric Kuhnke -
jlewis＠lewis.org -
Kee Hinckley -
ken emery -
Majdi S. Abbas -
Petri Helenius -
Stefan Mink -
Steven M. Bellovin -
Terry Baranski