home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3855 < prev    next >
Encoding:
Text File  |  1992-07-27  |  3.4 KB  |  62 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!mogul
  3. From: mogul@pa.dec.com (Jeffrey Mogul)
  4. Subject: Re: Firewall usage
  5. Message-ID: <1992Jul28.010344.9414@PA.dec.com>
  6. Sender: news@PA.dec.com (News)
  7. Organization: DEC Western Research
  8. References: <1992Jul23.142026.20112@sci34hub.sci.com> <1992Jul24.161006.12786@practic.com> <JTW.92Jul27142002@pmws.lcs.mit.edu>
  9. Date: Tue, 28 Jul 92 01:03:44 GMT
  10. Lines: 50
  11.  
  12. In article <JTW.92Jul27142002@pmws.lcs.mit.edu> jtw@lcs.mit.edu (John Wroclawski) writes:
  13. >Dave [Clark's] second point is that perhaps it is time to rethink the core
  14. >architecture of the internet (or its follow-on) to specifically
  15. >-include- mechanism to separate organizational policy functions (such
  16. >as authentication, logging, and access control) from the actual
  17. >service functions running on the typical host.
  18.  
  19. Actually, I think this approach was (in embryonic form, at least)
  20. suggested several years ago by Deborah Estrin, who developed the
  21. concept of Visa protocols.  In this model, "border" routers pass
  22. only those packets deemed allowable by an Access Control Server (ACS).
  23. Instead of requiring each packet to pass through an ACS on the way
  24. in or out of an organization, the end hosts get cryptographically-
  25. sealed thingies (visas) to stick onto their packets.  This allows
  26. a distributed implementation, but also allows the ACS to set whatever
  27. policy is desired.  The downside is that the cryptographic stuff could
  28. be rather costly, and the whole model depends on every external-access
  29. host implementing the mechanism.   For details, see
  30.     Deborah Estrin, Jeffrey C. Mogul, and Gene Tsudik.
  31.     Visa Protocols for Controlling Inter-Organization Datagram Flow.
  32.     IEEE Journal on Selected Areas in Communication 7(4):486-498, May, 1989.
  33. I'm sure Dave knows about this stuff; Deborah did her dissertation at MIT.
  34.  
  35. >I suspect Mr. Denninger will disagree, but I find this to be dangerous
  36. >and depressing thinking. A major strength of the Internet is the
  37. >ability for new services to come into existance when they're needed,
  38. >not several years later when a "nice clean requirement" has been
  39. >formulated, written down, approved, standardized, and poked at by a
  40. >layer or two of beaurocracy. In other words, the internet is strong
  41. >because it can evolve.
  42.  
  43. Alas, while parts of the Internet can (and should) continue to follow
  44. the "everything not forbidden is permitted" approach, which allows for
  45. evolution, other parts have to follow the "everything not permitted
  46. is forbidden" rule.  The powers-that-be at a company such as Digital
  47. are not going to permit us to run arbitrary experiments across the
  48. boundary between the nasty wide-open Internet and our soft, naive
  49. internal network.  There's nothing intrinsically wrong with this; the
  50. IETF doesn't require that everyone on the Internet experiment with a new
  51. service before blessing it.  Once a new service is properly understood,
  52. we can (if we so choose) cut a hole for it in the firewall.
  53.  
  54. From time to time, I (hidden behind a firewall) find Digital's policies
  55. to be a major pain; I still don't use services such as WAIS because of
  56. the extra effort involved.  But, I (and my coworkers) no longer spend
  57. a significant part of our time either tracking down intruders, or
  58. explaining to the corporate security types why they shouldn't shut down
  59. our gateway complex.
  60.  
  61. -Jeff [who accepts the blame for a few of the firewalls out there]
  62.