Re: FW: Filtering Capabilities for IP Network Infrastructure

[George Jones <eludom@gmail.com>]

On Wed, 16 Feb 2005 03:45:06 -0800, Vishwas Manral <Vishwas@sinett.com> wrote:
> Hi folks,
> 
> I forgot to forward this to the mailing list.;-))

Beta late than never....

> 
> 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.;-))

Context ?

> 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.

Intrusions @ the customer end are not as much in scope as DoS
attacks....the main focus
here is on keeping the provider network running (availability).    The
goal is not to turn
the provider into net-police ("please block all bad packets for me"). 
 Intrusions in
the provider network, esp. on the devices in scope (core, edge) would
be of interest.

Chris ?


>  
> 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.


I blieve that that is address in 2.1.4 (ability to specify filter actions)

>  
> 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).

2.1.7  Ability to Filter To the Device - Ability to Filter Protocols

   Capability.

      The device provides a means to filter traffic based on the value
      of the protocol field in the IP header.


>  
> 4. Actions could be to send packet for deeper processing to a device which does deep packet processing.

We currently have:


2.1.4  Ability to Filter To the Device - Specify Filter Actions

   Capability.

      The device provides a mechanism to allow the specification of the
      action to be taken when a filter rule matches.  Actions include
      "permit" (allow the traffic), "reject" (drop with appropriate
      notification to sender), and "drop" (drop with no notification to
      sender).

What would you add/change ?

>  
> 5. Ability to filer packets with errors, like(MF and DF) bits both set in the packet.

Does this do it ?

2.1.9  Ability to Filter To the Device - Ability to Filter Protocol
      Header Fields

   Capability.

      The filtering mechanism supports filtering based on the value(s)
      of any portion of the protocol headers for IP, ICMP, UDP and TCP.
      It supports filtering of all other protocols supported at layer 3
      and 4.  It supports filtering based on the headers of higher level
      protocols.  It is possible to specify fields by name (e.g.,
      "protocol = ICMP") rather than bit- offset/length/numeric value
      (e.g., 72:8 = 1).



>  
> 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).

Hmm.   Manipulating the packet.   Not something I'd considered.  Chris
 ?  Others ?
Initial reaction is that that is somewhat out of scope of things
needed to protect the
network and availability to customers....also something that may work in smaller
nets ("you have this device, you put it on your connection (singular)
to the Internet"),
but not necessicarily in larger, higher speed nets.

>  
> 7. We also have filtering mechanisms like rate limiting TCP SYN to prevent attacks.

Hmmm.   Good catch.   That was supposed to be in here.

>  
> 8. Also some ACL's are put by default like not allowing directed broadcast by default unless explicitly configured.

That was in earlier drafts of RFC3871 but dropped because (I think) 
another RFC, 2644
which is also a BCP addressed it.

>  
> 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.

Yes.   As things currently sit, that  is to be addressed under inband
management.
Different draft.   Still looking for active authors on that one (plug).

>  
> 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.

Yes.

Two answers there.   One: see the syslog working group.  Two: logging
is handled
in a seperate to-be-produced draft. 

>  
> 11. Ability to filter on reserved fields. Again for TCP we have firewalls that do that.

See 2.1.9, above.

>  
> 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?

Indeed.    Start with the rest of the points.    We'll be quicker this time.  

Thanks,
---George Jones