FW: Filtering Capabilities for IP Network Infrastructure

["Vishwas Manral" <Vishwas@sinett.com>]

Hi folks,

I forgot to forward this to the mailing list.;-))

Thanks,
Vishwas

________________________________________
From: Vishwas Manral 
Sent: Tuesday, February 15, 2005 12:01 AM
To: chris@uu.net; gmjones@mitre.org
Subject: Filtering Capabilities for IP Network Infrastructure

Hi Chris/ George,
 
Nice to see the draft as I have been working on and looking for exactly the same thing.;-)) I just went through things briefly. On the top level, the things missing seem to be: -
 
1. I think we are talking about active attacks as well as intrusions, however the word intrusion has not been mentioned.
 
2. Besides a lot of filtering rules for TCP are against scanning(to get information which port is up), example a mashine could send a packet with SYN or ACK field not set, if the port is up it ignores the packet, if a port is not up it sends a reset. Getting a RST means the port is not up and not getting it means the port is up.
 
3. Section 2.1.1 -       Many devices currently implement access control lists or filters
      that allow filtering based on protocol and/or source/destination
      address and or source/destination port and allow these filters to
      be applied to interfaces.

Generally when we use the port we actually have a 5-tuple based check, including the protocol used(UDP/TCP).
 
4. Actions could be to send packet for deeper processing to a device which does deep packet processing.
 
5. Ability to filer packets with errors, like(MF and DF) bits both set in the packet. 
 
6. I think we should have a  list of generic considerations from filtering/ACL, like getting the line rate, being able to manipulate the packet(like setting DSCP/ ECN fields).
 
7. We also have filtering mechanisms like rate limiting TCP SYN to prevent attacks.
 
8. Also some ACL's are put by default like not allowing directed broadcast by default unless explicitly configured.
 
9. Prioritizing important packets is another way to get over attacks. So a packet/ request which tells a port to shut an interface is given prioprity over a packet to be routed.
 
10. Also if any action to be taken as a result of log, we should make sure that the logging mechanism itself is not thew week link. So if the logs are communicated unencrypted/unauthenticated we could have a lot of attacks.
 
11. Ability to filter on reserved fields. Again for TCP we have firewalls that do that.
 
I have many more points, but its late in the night here. Do let me know if you want me to help you out with the document?
 
Thanks,
Vishwas