Hi Tony, On Wed, 13 Aug 2003 10:43:58 -0700 "Tony Hain" <[EMAIL PROTECTED]> wrote:
> Mark Smith wrote: > > True, but in my experience in a large, multi-departmental > > govenment network, is it fairly common that end user security > > / access requirements don't fall neatly along route / prefix > > boundaries. Typically this is because security has crept into > > the network, triggered by attachement to the Internet. > > This is inconsistent with your statement later about prefixes mapping to > broadcast domains. > My point was that users who are members of a single prefix commonly have different security access requirements. Far more often than route filtering a prefix to deny or permit access, I have : (1) Applied access permissions to an individual "user" (obviously really a device), based on their IPv4 address, and the application (TCP/UDP ports) they are granted or denied access to. (2) Applied access permissions to an individual "user", based on their IPv4 address. (3) One or the other of the previous two methods, but to a subset of the prefix members eg., a /29 group within a /24 prefix. Sometimes multiple, different size subsets within the same prefix. IPv4 addressing in the a number of cases in the past wasn't deployed along security boundaries, because security wasn't or wasn't much of a concern. Functionality was. Some customers won't mind restructuring their network to meet their changed or newly recognised security requirements, but others know that packet filtering functionality usually comes for free with a router, and they want you to use it. As a note on (3), after a while you start to realise that using network layer addressing for security isn't really that effective. If a user doesn't like the security access they have from their workstation, they will go and use somebody else's who has more access. While this could be classed as a physical security issue, it would be better if security could be applied at or nearer to the application layer, irrespective of network addressing or location. It is people we do or don't trust, not machines. I'm hoping that some of the "uglyness" of IPv6 addresses, including EUI-64 addressing for nodes, will encourage application security to be moved up the stack closer to the the users. Then I will have far less packet filtering to do, with all the associated "how does this application actually work at the transport layer" learning I have to do, on a per application basis. (Hmm, the inside of a network security person's head might be as ugly as a NAT code base ... ) > > > > In government networks, route filtering is a useful tool to > > have, but mostly it is a "nice to use", because it is too > > blunt to facilitate the security / access requirements of the > > end users. > > So is this a statement that the approach is not useful in government > networks, or a statement that the tool is inadequate because it does not > solve the government network problems? > I think it is inadequate, because it doesn't provide the resolution necessary to implement a number of customers' security access requirements. My examples above hopefully show that. > > > > Typically, the order of use of available network / transport > > layer security tools to meet common end-user requirements is : > > > > (1) "application" level - ie. filter on TCP / UDP ports, > > possibly in combination with IPv4 source and / or destination address. > > (2) network layer - filter IPv4 source and / or destination > > IPv4 adress. > > (3) route filtering > > > > Service providers, OTOH, protect their end-users by > > protecting the network itself. Route filtering is one of the > > primary tools for doing that, so (3) on my enterprise list is > > one of the (1)s on the service provider list. > > SP's aren't protecting their end-users by route filtering, they are > protecting their resources from other SP's. > I'm using the word "protect" in this case in the context of protecting their end-users by providing availability. > > > > Since IPv6 prefixes are going to be mapped along the same > > boundaries as IPv4 prefixes ie., layer 2 broadcast domains, > > IPv6 route filtering in an government network will be just as > > dull a tool as it is in IPv4. > > This shows IPv4 thinking, where the network has a single prefix / L2. While > I agree the initial deployments will likely mirror the IPv4 network, there > is no reason to preclude having additional prefixes / L2, where the > reachability characteristics are different. > I agree. But unless we are going to be able to allocate IPv6 addresses to applications*, I don't think route filtering is ever going to be as effective as packet filtering on individual network layer addresses and / or TCP / UDP ports. And that is a very common security request. Regards, Mark. * Peter M. Gleitz and Steve Bellovin have written a paper called "Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 and Multiple Addresses per Host", which seems to suggest doing this. I've only had a chance to briefly read the abstract, so I don't know how feasible or practical it would be to deploy this idea. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
