[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Referenceing 3704 in OPSEC filtering document ?
Several weeks late, but comments to various items are below.
GJ: George Jones
BG: Barry Raveendran Greene
CM: Christopher L. Morrow
GJ> Process (doing something) is more in line with Merike's document (practices).
GJ> Chris's is aout having the tools needed to do the process.
Process was probably the wrong word for the context. I was thinking mechanism/tool.
BG> In that case, all three of these are configured the same on hardware
BG> implementations. The supporting CPU converts a classification/action policy
BG> to microcode and loads the rule on the ASIC/NP/FPGA.
Look at it from a higher level operations perspective. In each case the operator would theoretically configure filtering using one of any number of methods. Some filtering mechanisms (ACLs, firewall filters, whatever) will for the most part be static until the operator takes some manual action. Others (uRPF, pinholes, etc) automagically update based on signaling with no need for operator involvement after the initial configuration. Being able to autoupdate without me doing anything qualifies as a feature in my mind (meaning, it would be something I would explicitly put in an RFx).
CM> but in any case of implementation the 'feature' needs to exist... So the
CM> filtering capabilities doc says: "must be able to filter incoming traffic
CM> with invalid source addreses" (or something probably much better worded).
My thought was that simply stating the feature as "being able to filter by foo" ignores the technical mechanism for maintaining/updating foo.
CM> How the implementation per equipment/vendor/combo is done isn't really
CM> relevant. Operators and vendors will come to an understanding that
CM> standing on your head, typing with your toes and completing a sonet from
CM> shakespere to get 'urpf' done on each interface is not suitable... but in
CM> the end, 'urpf' is still required.
Although at the end of a long day, I would certainly pay to see some of my fellow coworkers try to complete a sonet while standing on their head...
BG> Classification/Action rules are distributed to the box via CLI, routing
BG> protocols, configuraiton/provisioning protocols, service control protocols,
BG> and in the future specific security reation protocols. The only different
BG> between these are the transport of the policy and the security to insure the
BG> transport is trusted/secure.
Again, my focus was more on operator involvement/distribution initiator rather than the specific method.
BG> So there is something that can be worked with for either document (current
BG> practices or future requirements). I'm not sure it is what you were
CM> Yes, Fredd, could you expound a little? Keeping in mind the scope of the 2
For the filtering cap doc, perhaps add a functional capability such as "Ability to Dynamically Update Filter Parameters - The device provides a mechanism to update filter criteria in real time based on control/signaling information, without need to change the stored configuration." (using better wording of course) Then either point out static vs dynamic implementations under the various filter by foo implementation sections (where appropriate) or list a few examples under the dynamic update capability.
Suppose the Merike's practices doc could explicitly call out when/where static or dynamic filtering is applied, although I think it's touched on already.