home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3841 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.7 KB

  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!mintaka!jtw
  2. From: jtw@lcs.mit.edu (John Wroclawski)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Firewall usage
  5. Message-ID: <JTW.92Jul27142002@pmws.lcs.mit.edu>
  6. Date: 27 Jul 92 19:20:02 GMT
  7. References: <BrruC8.FEo@spock.dis.cccd.edu> <BrsM1C.36v@cs.columbia.edu>
  8.     <1992Jul23.142026.20112@sci34hub.sci.com>
  9.     <1992Jul24.161006.12786@practic.com>
  10. Sender: news@mintaka.lcs.mit.edu
  11. Organization: MIT Home for Wayward Triumphs
  12. Lines: 65
  13. In-Reply-To: brunner@practic.com's message of 24 Jul 92 16:10:06 GMT
  14.  
  15.  
  16. In article <1992Jul24.161006.12786@practic.com> brunner@practic.com (Thomas Eric Brunner) writes:
  17.  
  18.    >>I wish I had a transcript of Dave Clark's talk at the IETF last week.
  19.    >>He said some great things about firewall gateways and mailbridges, and
  20.    >>how they've essentially destroyed the whole purpose of having an IP
  21.    >>internet, and have forced a lot of us to use mail as a transport-level
  22.    >>protocol.
  23.  
  24.    Dave is usually correct, but as he thinks quite a bit more than many, and
  25.    says what he thinks, he is frequently not correct. Send him mail and ask
  26.    for a copy, or invite him to write. Perhaps he's been misstated in this
  27.    summary of his remarks.
  28.  
  29. Dave made two points. The first was that the architecture of the
  30. current internet is end-to-end, and does not have any notion of
  31. firewalls. He argued that because of this, firewalls make some things,
  32. such as introducing new services, much more difficult than they should
  33. be, and as a result people resort to odd things like using mail as a
  34. transport.
  35.  
  36. Dave's second point is that perhaps it is time to rethink the core
  37. architecture of the internet (or its follow-on) to specifically
  38. -include- mechanism to separate organizational policy functions (such
  39. as authentication, logging, and access control) from the actual
  40. service functions running on the typical host.
  41.  
  42. His key observation is that if we can provide these "checkpoint"
  43. functions at administrative boundaries as part of a well-designed
  44. architecture, rather than in an ad-hoc manner, we might be able to
  45. achieve two goals at once - provide a network which can -better- meet
  46. the security and usage requirements of a wide range of people, and at
  47. the same time preserve some of the open access which has driven the
  48. incredible growth of the internet so far.
  49.  
  50. Implicit in this observation is the belief that if we -don't- succeed
  51. in doing something like this, the continuing rapid spread of firewalls
  52. is inevitable, for the simple reason that many people feel they simply
  53. have no choice.
  54.  
  55. Responding to the same quote, karl@ddsw1.mcs.com (Karl Denninger) writes:
  56.  
  57.    Hogwash.  If it is that important to an organization, the firewall can 
  58.    provide proxy service for it.  It is >not< that big a deal to provide a
  59.    proxy connection for these kinds of things, >provided< that you have a nice
  60.    clean requirement.  The generic "anyone can do anything" doesn't cut it in
  61.    Corporate America anyway.
  62.  
  63. I suspect Mr. Denninger will disagree, but I find this to be dangerous
  64. and depressing thinking. A major strength of the Internet is the
  65. ability for new services to come into existance when they're needed,
  66. not several years later when a "nice clean requirement" has been
  67. formulated, written down, approved, standardized, and poked at by a
  68. layer or two of beaurocracy. In other words, the internet is strong
  69. because it can evolve.
  70.  
  71. Existing firewalls threaten this evolution because they mix up the
  72. notion of enforcing security with the notion of limiting
  73. functionality. This -is- a serious threat. Dave's core argument, that
  74. we should work to develop an architecture which can separate these
  75. functions, seems to offer a useful way out.
  76.  
  77. John Wroclawski
  78. MIT Lab for Computer Science
  79. jtw@lcs.mit.edu
  80.