Network Working Group L. Magnusson Internet-Draft TUPILAQ Arctica Intended status: Informational October 12, 2009 Expires: April 2010 A Security Practitioner's view on Internet Protocols draft-magnusson-secure-practice-00 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Magnusson Expires April 6, 2010 [Page 1] Internet-Draft A Security Practitioner's view Oct 2009 Abstract IETF members is per tradition a focused group, working with all aspects of network interconnectivity and processing. But, as requested by the IETF Security Chair at IETF-75, there is an emerging need of a more formal review of Information Security issues, in relation to the IETF Standard work. During IETF-75, the author noted in several sessions participants voicing a somewhat different view on security issues, compared to what I have experienced as norm and practice within several End-Users organizations. Some key practices, often dependent on rulesets as SOX "Best Practice" framework, seemed to not be to well-known in those discussions I attended. This document intends to, with some simple examples, review and highlight some effects of these gaps and questions they arises. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Role of Information Security in the End-User Environment . 3 3. A Defense Case for NAT . . . . . . . . . . . . . . . . . . . 5 4. Protocol Development vs. Information Security requirements . . 8 5. The Practitioners Approach . . . . . . . . . . . . . . . . . 10 6. A Suggestion to Support Protocol Migration . . . . . . . . . 11 7. Some concluding security reflections . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix - A Full Copyright Statement . . . . . . . . . . . . . . 15 Appendix - B IPS Boilerplate . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Magnusson Expires April 6, 2010 [Page 2] Internet-Draft A Security Practitioner's view Oct 2009 1. Introduction The author had in July 2009, through Swedish Network User Society, SNUS, and ISOC, the possibility to follow the work of the IETF work groups during the IETF-75 meeting in Stockholm. Though having been a less active member of the AntiSpam Research Group [ASRG] since 2003, to follow the plenary work was a new experience. One key observation was the level of knowledge among the IETF members. Another was that most participants seemed either to belong to communication equipment manufacturers, software manufacturers or network providers. For me, then working at a global IT End-User and more traditional Engineering Manufacturer, this was a very different playground. Let's not be shy, the knowledge level was very high and inspiring. But, and being the motivation to this Informational Draft, I noted in several of the sessions I followed, a certain difference in the approach to security related issues, compared to what I experienced as best practice in my daily my environment. I would say, I have found a discrepancy between the "Network World's" view and "Business End-Users" view. This document intends to address some of these differences, to familiarize Internet Network and Protocol developers to a different, but still a very valid set of views, used daily in End-User organizations. Hopefully to create understanding and build support for Information Security Officers and Managers work toward a safer, simpler working environment, than currently being the norm. To connect to this; during my last session, the Tuesday's IPv6 Ops meeting, the Chair read a statement from the IETF Management; a request from the IETF Security Chair to all workgroups to start to be more security conscious in their work. As could be said; todays large scale IT operation environments are like supertankers. Plot a new course is easy, but it takes maybe 3 years before you have a confirmation, course is changing. Therefore, when designing replacements, new networks protocols and functions, we should take consideration to end usage "Best Practices". This Informational Draft intend, from an Information Security Manager's perspective, to address some of my work area's idiosyncrasies, trying to give a perspective I somewhat lacked during my visit to IETF-75. 2. The Role of Information Security in the End-User Environment When reviewing Information Security aspects, we have to acknowledge that the motive of the subject area, which I would like to call End-User Organization Environment, is dissimilar to that of a Network Operator, network designer or a program designer. For the previous, it is to protect the local environment, while the latters have a Magnusson Expires April 6, 2010 [Page 3] Internet-Draft A Security Practitioner's view Oct 2009 focus in protecting delivered services and/or functions, i.e. very different work scenarios. This means that one for the latter group natural or not natural consideration could have the opposite value for the first. To visualize with a simple example, let's use FTP. FTP is agreeably one of the Internet's oldest and most arcane protocols and at the same time, currently all Information Security practitioners' most "hated" protocol; due to its protocol structure, it's lack of security and impact on current "Best Practice" audits rules, like US Sarbanes-Oxley, BaselII and/or other frequent used audit requirements. SOX has been a key component of all large scale remediation work since late 2004. Still, I doubt few larger organizations, if any, have fully succeeded to remediate it's FTP according to SOX's intentions. Why? In the author's experience, remediating FTP in our European operations from spring 2005, it boils down one single issue. We still have no direct drop-in replacement to FTP. Yes, we do have FTPS and SFTP, they do work, but, FTPS has inherited FTP's arcane and, from a firewall and security perspective, completely backward network behavior. SFTP, in its turn, lack several of today mandatory FTP command features. From a network perspective, FTP today is a totally redundant and a un-needed function. But from a business IT operation perspective, having more than a single operative system environment, it is still an absolutely crucial function. We therefore cannot replace FTP completely with either of these two replacements today. If we look at the FTP function specifications; we have the ASCII function, the file concatenation function etc, etc. If all these was included in the SFTP RFC, including a passwd dummy to use when doing batch transfers, at last we would have had that secure drop-in replacement for FTP, lacking for so long. Drop FTPS all together, since its firewall compatibility is as un-flexible as FTP. Imagine how many lost hours that FTPS has generated for firewall operators around the world. In a standardized operation environment, to implement SFTP connection through an NAT:ed firewall is a 2-3 day task, all processes included. FTPS, at an average, still is 15 days. Naturally, we working with these issues, do prefer SFTP. But SFTP doesn't need the ASCII, its 8-bit, so that is nonsense. Well, nearly all mainframe operators, never mind IBM z/OS, AS/400, Tandem Nonstop or Unisys, they use the FTP ASCII function to do on-the-fly conversion between EBCDIC/ASCII. It was never intended to be used that way, but has now become an operational standard for Magnusson Expires April 6, 2010 [Page 4] Internet-Draft A Security Practitioner's view Oct 2009 the operators. When a big site has invested years into an environment, it is hard to change hundreds of transfer script, some even forgotten, but still doing their job. Thus neither the current SFTP nor FTPS are good replacements. Another example; during the IPv6 CPE router session at IETF-75, there was a heated discussion about CPE router filtering, someone questioning a specific product solution as a hidden NAT solution. All involved in it was against NAT; NAT to be "Satan's" work. For an ISP, a router or a program manufacturer, NAT do break things, but for us in End-User Land, it is a huge relief. Most Information Security Managers would say; "Do not touch my NAT". Yes, NAT is a network abnormality and a kludge, but at the same time NAT has given the Security Community something originally not expected, an extra, simple layer of security, e.g. by obscurity, but still a very Occam's Razor type of solution. Yes, a good network protocol analyzer still can identify parts of an End-User organization through leaked information. But how many crackers do use such tools today? NAT is not only a kludge to save IP numbers, it's the key for most "non-IT" organizations to hide their network layout, to protect their key resources and repositories. Leakage of an IP in a user's mail header, OK, no big deal, because that user is not on the same net segment as Product Development's PDM cluster or Manufacturing's PLC equipment. Get my drift? Therefore NAT is today a very usable tool to hide how we organized our internal network and thereby our organizational structure, as well as where we have our data repositories. Externals, connecting via modern B2B sharing mechanisms, cannot directly deduct how we are organized, NAT therefore giving us an extra unexpected proxy layer. From network perspective, NAT is really bad practice, but not for me or my peers. And the best defense case for NAT is maybe something completely different than normally expected. Please evaluate that, before burying NAT in the IPv6 graveyard. 3. A Defense Case for NAT The case; we have the need to connect a number of suppliers and partners to our organization. We have +30 LAN-LAN connections. Some IPSec, others Black Fiber, a number of Leased Line and some ISDN, just for the fun of it. Unfortunately, several of our counterparts use exactly the same 10.x.0.0 or 192.168.x.0 Private IP's. We need to attach them securely, but still in a way that can allow for multiprotocol sessions, for such as PDM and/or production systems. Having multiple lines with same Private IP's, is something not likely to disappear in a near future. Go to IPv6 is on the surface technical Magnusson Expires April 6, 2010 [Page 5] Internet-Draft A Security Practitioner's view Oct 2009 a very viable solution, but again we do have issues with that, it will take years before that actually happens. Internal IP usage is not stressed in the same way as external usage, so we have to expect these ranges to linger on for a very long time. Also, likely in both ends, we have a hardware zoo, like IBM z/OS, Unisys NX2200, maybe Tandem Nonstop, some AS400, OpenVMS, Solaris, HPUX, AIX, Sinix, then some Linuxes, W2K, W2K3, W2K8 and, not yet to forget, embedded NT. We cannot force the exchange of +$20M tools as press lines, just because the embedded computer still is NT, that can't do IPv6. And that stuff seldom is made for upgrading. Let's face it, you do not rip down a 100M long, three stories high press line, to exchange a $1000 embedded (and networked) computer. This is how, not only big, but many affected Manufacturing End-User environments look like. I hope you, reader, to see the issues from our End-User Information Security perspective, it's a veritable Babel's Tower out there. We also can forget to be able to change the counterpart's IP range, we never know what other business functions/relations they have, that is dependent on it and thus can be severed by such demands. Therefore, we never expect a business counterpart to change their internal environment, to accommodate us. If not else, such demands always will hurt our future relations. So how do we solve this mess? It's simple; it's called Network Address Translation, aka NAT. And the case may look like this: Our first concern is the connections. We terminates the IPSec's with an IPSec enabled router on its own DMZ, able via the external firewall to receive IPSec connections only. For simplicity we terminate also the other connections at the same router, to equalize them; all connections looking the same from the inside, independent of their transport media. Doing so, we can note that all lines is defined by having an external router interface termination. That is the base for our solution. 1. All external traffic, independent of media, is terminated in the IPSec router's external interfaces, connections open on a point-to-point basis; only approved counterpart IPs' to connect approved internal hosts. Reachable hosts therefore also kept at a minimum. 2. All allowed external IPs' are NAT:ed to, say, a 172.x.0.0 Private IP serie, each counterpart having their sub range. This way the issue with multiple existents of the same IP Series externally is handled; it's hidden and non-existent from our perspective. 3. We NAT outgoing traffic, to our external Internet range, also for the direct lines. Our hosts then is seen with a unified NAT IP, independent of route or transport media. Magnusson Expires April 6, 2010 [Page 6] Internet-Draft A Security Practitioner's view Oct 2009 4. In the internal firewall DMZ interface, port filtering is done, mapped to approved ports/proxies as per our change documents. 5. Since the 172.x.0.0 addresses is blocked in the divisions' WAN routers, these can only connect to local hosts. If access needed to systems elsewhere in the company, we NAT the allowed IP's to a specific sub series in our internal B-class series at the internal interface of the inner firewall. 6. Connections in the B-class "firewall" sub series is globally known as originating from our firewall. As with the 172.x-series locally, they identifiable, our NiDS can always ID their traffic patterns. 7. Since we do point-to-point connections, we know that no-one at a counterpart can directly reach any for them not defined host. 8. We have no routing issues. Some of our other firewalls do let in external IPs'; needing "manual" mapping of counterparts Private IP's in our routers, creating routing issues when a new partner is not correctly defined in the tables or more than one uses the same Private IP. With some +50 firewalls globally, sometimes mistakes are done. But all our site's external traffic is as part of our site, with flagging the sub series as external. As seen, this is functionality not readily implementable with applications proxies, particular since we do have some complex PDM protocols, not having any firewall proxies. We even have attached a couple of remote offices, just using IPSec, this way. They are a part of our internal network, in our internal B-class series, even having needed Wintel protocol access, though still using the same hardware as our Suppliers, Dealers and Joint/Ventures, i.e. cost efficient. Security of the design? Having operated such a solution for a decade, our global Audit Office has audited the setup several times; both internal as external reviews and penetrations test with no remarks, only positiv comments. Naturally, the solution do has its flaws; but any production environment serving legacy solutions do have such; as having a Unisys, not supporting any kind of network level encryption and probably never will, but still critical for production. So, the intention of the network world can at times be counterproductive in a mixed environment operations at End-User organizations. Therefore, most Information Security Managers would say, "Do not touch my NAT". I admit that the solution sketched above is not very standard; most people introduced to it tends to get surprised by the unusual multi-level protection model it creates; including the easy handling of occurrences' of external Private IP's. But the key issue, that NAT can be a very creative component in network segregation/sectioning, should not be overlooked to lightly. In an increasingly more complex and harder to secure IT environment, those simple and well functional solutions is well needed. I therefore ask the IETF Network Community, to be cautious when counting out NAT, as seen there are other motivated use for it even after a IPv6 transition. Magnusson Expires April 6, 2010 [Page 7] Internet-Draft A Security Practitioner's view Oct 2009 4. Protocol Development vs. Information Security requirements Not surprisingly, another much debated area at the meet, was function protocol designs in regards to the IP protocol. From my perspective, the current generally accepted audit "Best Practices" do have an implication for anyone developing IP services, handling restricted data, as personal data and/or support inter organizational communications, i.e. all non local communications as well as legally regulated information. Already at the initial design phase, security implications need to be identified and addressed; if and how to secure the communication. An interesting case here is SIP. Personally, I have waited for SIP services for remote conferences since I first heard about it, end of 1990:ies. But again, we have a protocol that somewhat falls short due to the current hazardous nature of Internet, demanding firewalls and NAT protection that hinders it. I, for example, need to find an ADSL, if to do an Marratech conference session from work, since it uses SIP. SIP has improved some, but, why not solves it the simple way. Tunnel it, by add tunneling mode to the protocol. Do not change anything, just add an encrypted tunnel, using SSL, SSH or IPSec, to the application. Add something allowing it to traverse those obstacles in a secure way, not opening any more risks. As seen regularly during the last 20 to 15 years, communication elements is the Number One trouble spot for System and Information Security managers. Too often, even if the deficiency is located elsewhere, as in the actual application, such as the far too often occuring cases of buffer overflows, and not at the network connection; a basic security approach, as tunneling with built-in TCPWrapper-like application filter layers and/or encryption can secure applications enough, limiting risks to fully acceptable levels. But to achieve that, the developer do need to review the possible security issues, even before starting the project. 1. Working with inter-process related network communication designs, first question therefore has to be: "We have this great idea, we can implement it by creating such a protocol, but what risks do we introduce in the process?" To developing an application and/or protocols are the fun part, while security is the dreary. But as developers, we have, maybe if not a legal, but at least a moral obligation towards our customers, independent if in Open Source or not. Not to review our design from a security perspective, at least trying to handle the most obvious flaws, is to say; "you as a user do not matter, I do not care if I hurt you through my design". Magnusson Expires April 6, 2010 [Page 8] Internet-Draft A Security Practitioner's view Oct 2009 2. Next question is; "What type of data could a user be thought of to distribute via our application/protocol? Passwords, personal data, economic data, streaming sound from a conference? If so, how do we support the user, not compromising the data over the network?" Here, we as designers need to put up some standard pre-requisites to allow us to fine tune the topics arising from question 1. 3. Question three will be; "We intend to let users at different sites connect. What implication does that have for the protocol, when we traverse a couple of firewalls. We have also to expect that any of them can use NAT. Based on the two first questions, what effect would this have on our protocol? And if we use a multi-port structure, how do we secure it?" As having used Internet since early 80:ies, written a couple of client/servers mail systems and a leaf site Usenet system, my answer is; Make it as simple as ever possible, at least at network level. I have mentioned tunneling, IP-over-IP. Again maybe not a good solution from a pure network perspective, but definitely from a security perspective, if designed with built-in port/destination filtering. As a matter of fact, all the IPv6 sessions I visited at IETF-75, mentioned issues with protocols, requiring changes, as far as I understood, down to the basic IPv6 protocol environment. If so, from an End-User perspective, why change to or adopt IPv6, it must be flawed? Let's make an analogy, if a road passes a house, the house being in the way; either you tear it down or adjust the road; basics. Except where parcel prices may mandate it, who would ever think of raising the house on stilts, to let the road pass under? I realize that the issues debated are not that simple, but if something is failing under IPv6 and is not easily remediable, why not "hide" the offending protocol? Based on my understanding of the discussions, it's the protocol that is at fault, not IPv6. If online gaming protocols is that big an issue, as mentioned, demand that next generation gaming systems encapsulate their existing protocol into one that can pass firewalls and CPEs' safely. They not even need encryption, just an IP-tunnel. Risks of someone using the tunnel to slip something in? Again, no, because the online gaming designer naturally adds a TCPWrapper inspired filter, only allowing their own "sub"-protocols. Only gamer traffic, all other traffic not permitted. As a matter of fact, in the CPE discussions, IP-in-IP piggybacking was a key issue but no one did reflected over that such solution today does need built-in wrappers to filter at application level. Look at SSH Internationals Tectia or AppGates SSH implementations, it's for a reason those products have implemented central server Magnusson Expires April 6, 2010 [Page 9] Internet-Draft A Security Practitioner's view Oct 2009 filters. This should be "Best Practice" for all multiprotocol server designers. At the DKIM work group session, someone, could have been Dave Crocker (if not, my excuse), made an interesting analogy, during a discussion about what functions to keep or drop from the final draft. "We're adding a lot of 'good to have' stuff here. Another standard group has done that before us. It was the OSI, and they now are dead". That is food for thought, the speaker is right; it is very easy to add stuff, and I even have recommended it above regarding SFTP. In the end, Occam's Razor has to be the intention of any design. Less features, less security risks. Encapsulation is from a network perspective in fact a simplification, hiding the complexity, making it less exposed. And a good security rule for any; functions/connections that can be used for information containing data related to data privacy, export control, production control, product development, sales and economy, or "internal" conference functions; that's where we want encryption. Gaming, surfing, streaming media or similar, we just want to have a control over. Yes, our communication departments need access to media, while no, we cannot pay the bandwidth needed/time consumed giving Youtube to all, +100 MBit business access still cost a fair bundle. Then, to return to the IPv6 CPE router session, there were some discussions about CPE firewalls/filtering as a very negative process. As an Information Security practitioner, in an organization with a many employees, that at time works from home or minor offsite offices; I do not like the idea at all, to drop filtering/NAT/firewalling in this type of devices, as suggested by a number of the participants. As the Chair indicated; no, filtering is not ironclad security, far from it. But in a situation of no other control of the local end-point security and often failing patch status of offsite computers or other end-point equipment, used to connect to the work environment, I doubt any Information Security department would accept lack of NAT and filters. Again, a network kludge that has proven valuable for us in the End-User space. 5. The Practitioners Approach To try to quantify some of the previous section; the last 8 years, my site tunneled a multiprotocol connection between us and a manufacturing outsourcing partner, 1000 km away. Via our own global network, we connected to a joint third country FW exchange location, to continue over the partner network to their termination point. With industry level firewalls at both end-points and IPSec in between, the FW managers at the joint exchange point Magnusson Expires April 6, 2010 [Page 10] Internet-Draft A Security Practitioner's view Oct 2009 never need to understand what protocols they allow in/out. They only sees the IPSec tunnel. At times, an auditor, new to the organization, not understanding the setup, do shuts the connection down. At those times, the end-point FW's fails over automatically to Internet. Reason for not permanently using Internet, was the partner's initial Internet capacity. But the key point is; we have used this setup for Just-in-Time manufacturing traffic for 8 years, having people, understanding the end-point environments, doing "in-application" filtering/proxying, while the central network team saw to that we had safe connectivity between the organizations networks. Do the right job at the right location. This is directly analogue to my case for an application network filter. With application filters layers, behaving as TCPWrapper, at server ends, we do increase security. An application not answering to a non-agreed call, is a safe application. And as seen in the previous section, by using the three basic questions, we created a far different development landscape, what from the meet appears to be the network norm today. To handle the security issues, before they reach the users. 6. A Suggestion to Supported Protocol Migration The good developer now will say; "but we cannot adopt such approach, there is too many clients out there, we will break them". Based on the work remediating my +30.000 regional employers FTP, the basic answer is: "Yes, that is a correct statement". But thanks to the built-in resilience into the IP protocols, there do exist a natural way, handling changed/expanded protocols without breaking anything; doing it in a, even for big organizations, controlled process. Simply described and as well known; when connecting to a host, if an incorrect instruction given, the host gives a error message and in most cases put itself into listening mode again, ready for new instructions. Thus, then it is possible for a client to fall back to an older protocol, if the host cannot support the new. The client simply changes method, reconnecting. Let us look at IPSec; I like it a lot. As indicated earlier, we have had a large number of connections over the years. But IPSec has one annoying attribute. It has two methods of setting up connections, using PKI or using pre-shared keys, 3-DES or AES. Yes, 3-DES is not that good, but of some reason it is still the most common method I Magnusson Expires April 6, 2010 [Page 11] Internet-Draft A Security Practitioner's view Oct 2009 get in contact with. We probably should migrate to AES, but for the sake of discussion, here we use 3-DES. For the IPSec tunnels we normally set up, neither PKI nor pre-shared keys is a particular good construct, having a need of "Ad Hoc" tunnels. Personally, a "SSH"-like public key exchange would have been preferrable. But, how to add such a public key facility, not breaking the existing IPSec application? Let us structure an imaginative, but plausible, solution. And please, for the sake of argument, lets ignore any existing support within the IPSec PKI functionality; the case is how to change an existing IP protocol in an controlled way, not to explicitly "fix" IPSec. The overview: a. We add the SSH mechanism for reading and exchanging keys. b. We add a random key generator, with which we can build Ad Hoc 3-DES keys. c. We add a new command, which, if the host is supporting the new key function, does the handshake for a temporary "SSH" tunnel. d. With the public keys, the tunnel is brought up to send the Ad Hoc 3-DES keys to the host for install and then bring up the IPSec tunnel as pre-shared. e. If the host does not support the new function, communication falls back to the old handshake, either using PKI or existing pre-shared keys or fails. f. Give the application manufacturers and users a grace period, to via update cycles to introduces the new functionality (and withdraw old if needed), through their standard updating process. Now, let's look at the imaginary handshake in detail, to clarify: 1. The "client" side IPSec process is brought up to connect to the host. 2. It tries to handshake with the remote server in "SSH" mode. 3. Server acknowledges it is able to communicate in "SSH" mode. Else, if the host signals an error, the client falls back and try to connect with either pre-shared keys or PKI or shutdown. 4. Client starts to negotiating keys and brings up a temporary "SSH" based tunnel. 5. Connection approved, the client generates a random Ad Hoc 3-DES key. 6. The client sends its Ad Hoc 3-DES pre-shared key via the "SSH" tunnel. 7. The host installs the 3-DES keys, notifying the client that it's ready to go "pre-shared". 8. The client disconnects the "SSH" tunnel. 9. The client starts proceedings for the standard pre-shared 3-DES tunnel. As seen, if no support for the new protocol, we fall back to the old protocol, which secures our connectivity. Magnusson Expires April 6, 2010 [Page 12] Internet-Draft A Security Practitioner's view Oct 2009 This approach, if used as standard, also could have solve the most annoying problem in our FTP migration project; how to handle communications, when ONLY one of the sites has migrated. This was, by far, the single largest operational issue in the project. To migrate such an environment you need a drop-in client replacement, supporting both FTP and secure FTP and that the hosts can support both protocols. Server-side we can have separate services, but the client then need to handle re-authentication against the old protocol server. Since today neither SFTP nor FTPS clients can fall back to basic FTP, we need to set up parallel solutions for our communication. Realize, if having major operations in +10 countries, with a hardware zoo, 5 Datacenters, a number of mid-size data installations and +10 factories, all running Just-In-Time, and adding +2.000 regular FTP connections; any form for big bang change is no longer a viable option, while having dual transports is a management nightmare. We tried using both SSH Int. Tectia services, with some of the given functionality, as a multi-protocol FTP migration server; they helped some, but no, it's was far from a golden bullet. Having fallback in a migration situation is crucial, for even to start trying to adopt a new network protocols. A side note; over the years, we have seen many complaints about the resistance to IPv6. Without automatic fallback support in the protocols, like described above, enabling dual operations without extra applications and hardware, no sane End-User Network Manager will try to start a migration. We simply cannot migrate in an easy way. Of cause, my examples is simple from a network designer perspective, but the intention is pedagogic, to show an alternate route to successful migrations, not possible today. 7. Some concluding security reflections There is plenty of literature references about security praxis, but still, the best by far is Occam's Razor, or to use an old classic IT maxim, KISS - Keep It Simple Stupid. In many situations, the best payback is from the simplest solutions. [1] As noted above, adding TCPWrapper-like filters at application level, is a tremendous support in business applications. Yes, it can be implemented in the stack, if Unix or Linux is used, but, again, we End-Users often is a hardware zoo, z/OS, AS/400, Unisys NX2200, Tandem Nonstop, OpenVMS, Solaris, AIX, HPUX, Sinix, Linuxes, Win2000, Win2003, Win2008 and, still, NT. [2] [3] A lot of networks applications exist for most of our OS:es, but TCPWrapper does not. Go Unix/Linux? No, as soon as we talk +5000 employee organizations, an inertia automatically gets introduced, making any simplifying of the IT landscape a very painful experience. System exchange via standard refresh cycles is the most realistic Magnusson Expires April 6, 2010 [Page 13] Internet-Draft A Security Practitioner's view Oct 2009 option for remediating odd equipment. Therefore, application level filtering and network fallback can be simple and functional options to hide the issues meantime. When a new protocol is ready in the client or server, then use it; before that, fallback to the old. No changed command scripts or other complications needed for functions done 15 years ago, programmer/sysadmin long gone. And to be able to keep those unwanted visitors at bay [4], just by defining accepted client IPs'/domain names in host filters and (if multi-protocol) what allowed protocols. Less strain on firewalls and filter routers. It doesn't keep all risks at bay, but at least most script kiddies. We need to remember; the only secure computer is one melted down in a steel furnace. The roll of Information Security is to increase cost of penetration or manipulation so much, that an attack is not worth the effort. That is the primary goal for me and my peers. Often, us being able to standardize to SSL or SSH public/private key based authentication; that is what most of us Information Security Managers expect. Support of SecurID or Yubikey-like onetime password generators is also a proven cracker averter. A number of times we have had visit by SSH crackers; but use of SecurID made the attack only a risk of being a DoS attack; mostly we just reviewed it, notify the originating ISP and continued with other issues. Therefore, to try to understand your application and/or protocol from an End-User perspective, isolating the issues which can affect the user's security, and not only from a network operational point of view, that would a big help. 8. Security Considerations Security principles, particular End-User security in organizational IT environment is discussed throughout this document. 9. IANA Considerations This document has no actions for IANA. 10. Acknowledgments The author would like to thank Swedish Network User Society (SNUS) and ISOC to be able to participate as guest visitors at IETF-75 in Stockholm. Funding for the RFC Editor function is currently provided by the Internet Society. Magnusson Expires April 6, 2010 [Page 14] Internet-Draft A Security Practitioner's view Oct 2009 Informative References [1] Brooks, F., "The Mythical Man-Month", Addison-Wesley; 1975. [2] Cheswick, W.R., Bellowin, S.M., "Firewalls and Internet Security", 1:st Ed., Addison-Wesley; 1994. [3] Hansche, S., "Official (ISC)2 Guide to the CISSP-ISSEP CBK", Auerbach Publications, 2006. [4] Garfinkel, S., Spafford, G., Schwartz, A., "Practical UNIX and Internet Security", O'Reilly, 2003. Author's Address Lars Magnusson TUPILAQ Arctica Furulundsvagen 61 461 44 Trollhattan Sweden tupilaq.arctica@gmail.com Magnusson Expires March 26, 2010 [Page 16]