home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3816 < prev    next >
Encoding:
Text File  |  1992-07-25  |  3.7 KB  |  69 lines

  1. Path: sparky!uunet!olivea!decwrl!csus.edu!netcomsv!iscnvx!leadsv!practic!brunner
  2. From: brunner@practic.com (Thomas Eric Brunner)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
  5. Message-ID: <1992Jul24.161006.12786@practic.com>
  6. Date: 24 Jul 92 16:10:06 GMT
  7. References: <BrruC8.FEo@spock.dis.cccd.edu> <BrsM1C.36v@cs.columbia.edu> <1992Jul23.142026.20112@sci34hub.sci.com>
  8. Reply-To: brunner@practic.UUCP (Thomas Eric Brunner)
  9. Organization: Practical Computing Inc., Sunnyvale
  10. Lines: 57
  11.  
  12. In article <1992Jul23.142026.20112@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
  13. >In article <BrsM1C.36v@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
  14. >>In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
  15. >>>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
  16. >>>I receive a "no route to host" error?  ....
  17.  
  18. They are probably doing packet filtering based on ports at one or another of
  19. the routers under their adminstrative control, for reasons of their own.
  20.  
  21. >>The site you are trying to ping is running a firewall gateway, because
  22. >>they're too lazy to beef up their host security and are relying on the
  23. >>firewall to protect themselves against external attacks.
  24.  
  25. Hmm, an ad hominum explination, always a pleasure to read in a technical list.
  26. Having reluctently made a few dollars working for or against host security,
  27. I respectfully note to those not entirely convinced by the offered rational
  28. above, that for reasons of their own, the site in question, or any site,
  29. may have chosen to obtain hosts which meet specific local needs, and don't
  30. as yet meet a narrow subset of features thought of as offering "security"
  31. to ip- (or smtp-, or decnet-, or uucp-) addressable hosts. In short, they
  32. may be heterogeneous with some hosts meeting higher locally-defined needs
  33. than denial of unathorized use -- like computing for instance.
  34.  
  35. >I have to take exception to this remark. Use of a firewall doesn't indicate
  36. >laziness on the part of a site; it most probably means that the persons
  37. >responsible for the Internet connection and security of the sites' net are
  38. >either too understaffed to maintain all the hosts on their site, or they
  39. >don't have control over all the hosts, and are therefore not able to make
  40. >them secure. And there are doubtless many sites that suffer from both 
  41. >problems.
  42.  
  43. They may also have intellectual property, or operational function, which
  44. they value sufficiently to attempt some form of administrative filtering,
  45. in addition to the staffing and competency issues.
  46.  
  47. >>I wish I had a transcript of Dave Clark's talk at the IETF last week.
  48. >>He said some great things about firewall gateways and mailbridges, and
  49. >>how they've essentially destroyed the whole purpose of having an IP
  50. >>internet, and have forced a lot of us to use mail as a transport-level
  51. >>protocol.
  52.  
  53. Dave is usually correct, but as he thinks quite a bit more than many, and
  54. says what he thinks, he is frequently not correct. Send him mail and ask
  55. for a copy, or invite him to write. Perhaps he's been misstated in this
  56. summary of his remarks. In any event, this was not one of the more important
  57. topics on the IETF adgenda, had it been, I'm sure there would have been
  58. other points of view expressed, as well as discussion of technical details
  59. of implementation, which are more to the point.
  60.  
  61. I'm looking forward to John's posting, "Administrative Packet Filtering
  62. Considered Harmfull"... in comp.security.misc, or as an internet-draft...
  63.  
  64. -- 
  65. #include <std/disclaimer.h>
  66. Eric Brunner, Tule Network Services
  67. uunet!practic!brunner or practic!brunner@uunet.uu.net
  68. trying to understand multiprocessing is like having bees live inside your head.
  69.