RE: Referenceing 3704 in OPSEC filtering document ?

["Christopher L. Morrow" <christopher.morrow@mci.com>]

On Thu, 10 Mar 2005, Barry Raveendran Greene wrote:

>
>
> > I think Chris' filtering capabilities draft should be
> > modified to include the process of how the filtering rules
> > are configured. 3704 would then be a reference to an implementation.
> >
> > Regards,
> > Fred Budd
> >
> > -----Original Message-----
> > From: George Jones [mailto:eludom@gmail.com]
> > > There are three possibilities that come to mind immediately:
> > > - manual configuration (implementation being static ACLs)
> > > - dynamic based on something known (implementation being uRPF)
> > > - triggered by external source/API (implementation being shunning,
> > > quarantine, VOIP midcom pinholes)
>
> In that case, all three of these are configured the same on hardware
> implementations. The supporting CPU converts a classification/action policy
> to microcode and loads the rule on the ASIC/NP/FPGA.

but in any case of implementation the 'feature' needs to exist... So the
filtering capabilities doc says: "must be able to filter incoming traffic
with invalid source addreses" (or something probably much better worded).

How the implementation per equipment/vendor/combo is done isn't really
relevant. Operators and vendors will come to an understanding that
standing on your head, typing with your toes and completing a sonet from
shakespere to get 'urpf' done on each interface is not suitable... but in
the end, 'urpf' is still required.

>
> Classification/Action rules are distributed to the box via CLI, routing
> protocols, configuraiton/provisioning protocols, service control protocols,
> and in the future specific security reation protocols. The only different
> between these are the transport of the policy and the security to insure the
> transport is trusted/secure.
>

I don't think that the filtercaps doc should have 'implementation' in it,
that makes describing this rough, but ...

> So there is something that can be worked with for either document (current
> practices or future requirements). I'm not sure it is what you were
> thinking.
>

Yes, Fredd, could you expound a little? Keeping in mind the scope of the 2
documents?