RE: FW: Filtering Capabilities for IP Network Infrastructure

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

Hi George,

> 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 ?
The above sounds good. However isn't it good to block the bad packets 
before they enter a provider network.
 
>> 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)

George I think 2.1.4 as a generic case. 2.1.9/10 etc (ability to filter
to device) could all fall under the ability to filter, what I am talking
about is ability to filter scans. Another thing we could state is the 
ability to filter messages on diagnostic ports.

> 2.1.16 Filter Counters are Accurate
I am not sure why we need to state that. Isn't that implied that 
anything that is supported in the router should be correct. I think the 
heading could instead be "Counter size" Packet/Byte counters on high
speed
links should be 64bits.

>> 5. Ability to filer packets with errors, like(MF and DF) bits both 
>> set in the packet.
> Does this do it ?
> Ability to Filter Protocol Header Fields.
I think there is a difference. With what you mention we should be able
to filter the DF/MF settings. However this is a known issue, and for all
known issues we need the filtering capability inbuilt in the device a 
configureable value may not be necessary.

  
>> 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.
George I know of a filtering rules which are doing this currently and I
think it is necessary. 

Besides I think there can be attacks based on manipulation of DSCP 
value.  If a malicious device injects all packets with EF codepoint it 
could create havoc in the network.

>> 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.
The above is just an example. What I meant was ability to configure
ACL's
by default based on an event. So when an interface came up we could
filter
directed broadcast(mind you you only know the directed broadcast when
the
ip address and mask are known)

Thanks,
Vishwas

======================================================================
To: Vishwas Manral <Vishwas@sinett.com> 
Subject: Re: FW: Filtering Capabilities for IP Network Infrastructure 
From: George Jones <eludom@gmail.com> 
Date: Wed, 2 Mar 2005 14:51:56 -0500 
Cc: opsec@ops.ietf.org, chris@uu.net 
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-
version:content-type:content-transfer-encoding:references;
b=h9XwzJDTE5OxmHoMpPa1oeGI6RoHTzUgvqbuIcZXQLQMpCpVSxe5HuLy4Qan7ZIlVzoiDD
zarsK91kWQTi7V4y1DVSmhrLx3zZnp3xe+zeIp1iv1HLOasNVRMjXmqiqFbd3nsOy9CzAyI5
u1g2D2BaofufWMVSEJ/ddotkzZmYE= 
In-reply-to:
<BB6D74C75CC76A419B6D6FA7C38317B2628B7A@sinett-sbs.SiNett.LAN> 
References: <AcUSu58l0sWXLHxfQAO3hIxxwIOVTgBYT+PA>
<BB6D74C75CC76A419B6D6FA7C38317B2628B7A@sinett-sbs.SiNett.LAN> 
Reply-to: gmj@pobox.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