On Thu, 14 Aug 2003 09:39:59 -0700 "Tony Hain" <[EMAIL PROTECTED]> wrote:
> Mark Smith wrote: > > ... > > > 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. > > The examples show there environments more complex than a simple tool can > deal with. That does not make the tool inadequate for the simple > environments. > Fair enough. Obviously route filtering is not the only tool necessary in complex enviroments, nor the first one that will be used, which is what I though you were initially suggesting. > > ... > > > 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. > > Yes that is a common security request, but it falls flat on its face when > the TCP/UDP ports are masked by IPsec, or simply spoofed by the application > (ie: both ends agree that 80 is a remote file mount). Absolutely. Thats another reason why implementing security at the application end-points, eg., by identifying the user, not the machine they are coming from, will become a far more effective. Various "tunnel over http" and other techniques take advantage of this fact. (http://openvpn.sf.net is the best example I've seen - uses UDP, with a selectable port, SSL for encryption, and uses SSL session IDs for tunnel end point identification ie. the tunnel end point IP addresses can change, and the tunnel still works - nice for flakey dial up links, or ADSL sessions where your ISP insists on occasionally changing your IP address. Under linux, it can emulate an ethernet interface, so IPv6 autoconfiguration just works. I wonder how many firewalls thoroughly check the contents of UDP port 53 a.k.a DNS traffic ...) To your earlier > comment about filtering is free, it really isn't. Yes it is included in the > box, but doing the work requires time (increased app latency), or dedicated > hardware (increased device cost), so it isn't free. > I agree it isn't free. But it is common for the router to have enough excess capacity such that it is effectively free, when compared with e.g., creating a new layer 2 segment, allocating a new prefix, possibly purchasing and implementing a firewall for that segment, developing a new firewall rule set to suit the user(s) and renumbering. After implementing this filtering, I've never come across a user who has complained about performance. > * To some degree this is the deployment model. Not to explicitly allocate an > address to an individual app, but to allocate addresses with the > characteristics of 'local use' and 'global use', then have the apps bind to > the appropriate one. If a local policy is more complex than the simple two > layers, it will need additional (out of scope for this approach) mechanisms > to sort out which app should be bound to which address. > > Tony > > ... Please send a pointer to the Gleitz/Bellovin paper > My pleasure. http://www.research.att.com/~smb/papers/tarp.pdf Regards, Mark. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
