tsudik@pollux.usc.edu (Gene Tsudik) (06/02/90)
The inadequacies of the gateway-based filtering have been discussed in a number of recent messages. To sum things up, it was pointed out (by Phil Karn) that "..there is no substitute for each individual taking the responsibility for his own local domain...". It is hard to disagree with this point of view. However, the argument was in the context of end-system protection. It is both inadequate and inappropriate for a gateway to protect hosts that are subject to the outside exposure. Instead, these hosts should be able to protect themselves. However, another important issue is the protection of network resources other than the end-systems. This includes internal gateways, bridges and links. It is obviously undesirable to have unauthorized external traffic interfere with local traffic. This is why internal network resources should be protected from unauthorized use. Note that simply detecting bad packets at the end-systems is inadequate since by the time unauthorized traffic reaches an end-system, it has already consumed internal network resources. So, if protection of network resources is desired, border GWs need to check incoming packets for i) authenticity, ii) data integrity, and iii) replay. Furthermore, when an organization connects to an internet, more often then not, only a small number of select end-systems are exposed. Should all other strictly-internal end-systems be expected to implement adequate security measures? The answer is dependent on one's "religion". If one subscribes to Phil Karn's point of view, there should be no such things as "unprotected " end-systems in the first place. Alternatively, if there is a need to preclude any kind of external access to strictly-internal end-systems, border gateway-based mechanisms can be employed to restrict incoming traffic to only exposed end-systems. This can be done with complete transparency to the internal (unprotected) end-systems. Note, that an intruder can still use the exposed end-systems as a conduit for accessing the internal systems. However, using Phil Karn's argument above, the exposed end-systems should ensure that this doesn't happen. In summary, end-system controls are inadequate for protecting internal network resources. To control access to such resources, border gateways need to implement appropriate security mechanisms. Gene Tsudik and Deborah Estrin Computer Networks and Distributed Systems Laboratory Computer Science Department University of Southern California Los Angeles, Ca
karn@ka9q.bellcore.com (Phil Karn) (06/03/90)
In article <25040@usc.edu> tsudik@pollux.usc.edu (Gene Tsudik) writes: >In summary, end-system controls are inadequate for protecting internal network >resources. To control access to such resources, border gateways need to >implement appropriate security mechanisms. Yes, your conclusion does follow from your premise. The question, though, is whether this is a real problem. Most private corporate or campus networks are "stubs" off the main Internet, so what can anyone gain by sending traffic into such a network without access to a host on that network? Sabotage of the private network itself is of course a possibility, but this can be handled by turning on a gateway filter to block the offending traffic. I don't oppose filtering gateways per se. I just think they're like police roadblocks: appropriate during emergencies, but too disruptive for routine operations. Phil
kwe@bu-it.bu.edu (Kent England) (06/04/90)
In article <25040@usc.edu>, tsudik@pollux.usc.edu (Gene Tsudik) writes: > > The inadequacies of the gateway-based filtering have been discussed in a number > of recent messages. ... > > Phil Karn's point of view, there should be no such things as "unprotected " > end-systems in the first place. Alternatively, if there is a need to preclude > any kind of external access to strictly-internal end-systems, border > gateway-based mechanisms can be employed to restrict incoming traffic to > only exposed end-systems. This can be done with complete transparency to > the internal (unprotected) end-systems. > What is the essential difference between "routing" (including policy- based routing) and "access control lists"? Might the boundary be slightly fuzzy? It seems so to me, at least as far as ip-address is concerned. For example, if there is a stub domain connected to some transit routing domain, and the stub advertises routes for nets A and B to the transit net (and the transit accepts), should the transit network filter source addresses to exclude all sources except nets A and B? Source address filtering is currently considered to be part of "access control" and not of "routing" (at least it seems so to me from current implementations and Requirements RFCs). If the transit domain does not include source addresses in the routing decision, then the transit domain's routing policy can be overridden by the stub domain, through back-doors and side-doors. This is, of course, a current problem in the Internet. If one were to say that source address filtering at borders should be done, then I think we may have redefined a part of "access control lists" into "routing". Perhaps today's access control list feature is tomorrow's Router Requirement? (And so Gene and Phil are both right.) --Kent England Boston University