Eliot Lear wrote:
Like it or not, it is accepted
security practice to limit access by filtering on bits in the IP header, and restricting what prefixes are announced in routing protocols.
But that filtering is done EXPLICITLY based on a PARTICULAR device in a PARTICULAR environment. Neither the device nor the firewall can make that decision, and that is what you are claiming. You are OVERLOADING security operations on the IP address, a construct that is poorly suited for the task.
No, I am using a well established construct of limiting access by restricting where prefixes get routed, and limiting access by filtering on header bit patterns. That is not overloading on the IP address any more than current practice does.
But we need no more than we have. You are building an operating assumption around a bunch of bits in the address field that isn't safe. People who use this today understand its limitations. If you look at most of the home "routers", they have more of a notion of "inside" and "outside" interfaces. Even the HOME router doesn't build an assumption along the lines you are discussing. It doesn't look at the bits in the address field, other than to NAT permitted stuff through.
Now let's look at the enterprise case. Unless you claim you are going to do away with the OTHER access-lists, then this is just another bit pattern for an ACL and there is no architectural need, and there is some peril as Michel has described.
In any case, I was not even claiming that any packet filtering was happening in that scenario. The presumption was that the prefix for local use was not being routed outside the home, while the
global one
was. In that case, packet filtering is not required as the origin can't get packets to the destination.
And that is where you are relying on the routing protocol for security, and that too is a bad architectural assumption. It's bad for all the reasons I wrote in the message you claim had "no content".
Then why do network managers every have limitations on routing announcements, both sent and heard? It is because they want to limit access.
Mostly to protect the routing system itself.
Restricted routing is just one component in a comprehensive
security
plan.
Since it doesn't really do the job,
What job? Provide perfect security? If that is the case, what does the job today? If such a product exists, why is route filtering so prevalent?
For all sorts of reasons:
1. Protection of the routing system itself is the big one.
a. unwanted loops
b. unwanted accidental transit
c. malicious tampering with the routing system
2. And indeed people do not want advertised that which they want kept off the Internet. Why invite the attack? But it is as much as not having DNS information for an unreachable host behind a firewall.
and since we are talking about a home system as a use scenario, less is more. Provide a single mechanism that works correctly such that the individual can manipulate it in one place if he/she has to.
There is nothing about providing a local use space that precludes a single point of control. Architecturally requiring a single point of control however precludes distribution and increasing scale.
I am not mandating any such thing. I am saying that you are architecting toward a solution that is best solved elsewhere. AND what we have works without such constructs - with two notable exceptions:
We do need to handle the disconnected and intermittenly connected network carefully and in a reasonable way. Here I don't think we have good answers -- YET. I do not wish to sweep this one under the rug.
And then there is the case of renumbering and managing networks through renumbers. That's where Fred's stuff comes in.
Eliot
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
