Mark, a few comments back...
On Thu, 28 Jun 2007, Mark Allman wrote:
>
> MORE-THAN-NITS
> --------------
>
> Sec 5.1: The "Capability" description is not at all clear to me. I
> keep re-reading this one and just cannot understand what it says.
> Please re-write this in a more clear fashion--perhaps with an
> example.
>
that section is:
--------------- section -----------------
5.1. Filter Counters Displayed Per Application
Capability.
If it is possible for a filter to be applied more than once at the
same time, then the device provides a mechanism to display filter counters
per filter application.
Supported Practices.
* Profile Current Traffic (Section 7.1 (Profile Current
Traffic))
* Respond to Incidents Based on Accurate Data (Section 7.4
(Respond to Incidents Based on Accurate Data))
Current Implementations.
One way to implement this capability would be to have the counter
display mechanism show the interface (or other entity) to which the filter
has been applied, along with the name (or other designator) for the
filter. For example if a filter named "desktop_outbound" applied two
different interfaces, say, "ethernet0" and "ethernet1", the display should
indicate something like "matches of filter 'desktop_outbound' on ethernet0
..." and "matches of filter 'desktop_outbound' on ethernet1 ..."
Considerations.
It may make sense to apply the same filter definition
simultaneously more than one time (to different interfaces, etc.). If so,
it would be much more useful to know which instance of a filter is
matching than to know that some instance was matching somewhere.
------------- end section ---------------
There are some english-language problems (missing a few words 'is' in
'...desktop_outbound" IS applied...'. I'll grab the
english-language-mixups, but I think based on my experience using
traffic filters and trying to figure out what came-in/went-out a set of
interfaces the implementation discussed seems to be clear. Basically in
cisco-ese:
morrow-gw>show access-list 150
Extended IP access list 150
permit tcp host 199.172.128.4 eq 6346 any
permit tcp host 208.218.124.220 eq 22 host 64.151.66.228 gt 1023 (127466
matches)
should really be something like:
morrow-gw>show access-list 150
Extended IP access list 150 - F0/1.100
permit tcp host 199.172.128.4 eq 6346 any
permit tcp host 208.218.124.220 eq 22 host 64.151.66.228 gt 1023 (1466
matches)
Extended IP access list 150 - F0/2.300
permit tcp host 199.172.128.4 eq 6346 any
permit tcp host 208.218.124.220 eq 22 host 64.151.66.228 gt 1023 (202012
matches)
So, show me all interfaces this is applied to and total matches per
interface. If the access-list were to be used (again in cisco-ese) as a
route filter (distribution list or route-map match condition) it would be
nice to know where the x-bazillion matches came from (some from neighbor
1, some from neighbor 2, and the rest from poorly constructed route-map
17)
Does that make the capability more clear? I hestitate to change the text
as it is today since it makes sense to me (and george and vishwas
atleast). If it's still unclear we can take a whack at fixing it. I
suppose one reason for confusion could be the overload of 'application',
not 'ms word' but 'application of filter in the configuration, interface1,
interface2, interface3, route-map-17 4 different 'applications' of the
filter.
>
>
> NITS
> ----
>
> Sec 1.2: "threat model of this document" --> "threat model assumed
> in this document"
done
>
> Sec 3.1 (and others): "and or" --> "and/or" (do a search & replace,
> as this happens quite a few times in text that looks like it was cut
> & pasted)
>
done
> Sec 3.5: "It allows invalid or malicious traffic" --> "It allows
> traffic judged to be invalid or malicious"
>
done
> Sec 3.6: I'd suggest a reference to the PMTUD blackhole RFC (2923)
> where you mention the negatives of dropping ICMPs.
>
I think I did this right :) George did most of the referencing out
parts...
> Sec 4.1 (and others): "TCP Resets." --> "TCP Resets, for instance."
>
done
> Sec 4.1: "(e.g., syslog" --> "(e.g., via syslog"
>
done
> Sec 5.1: "applied two" --> "applied to two"
>
done
> Sec 7.2: Seems weird to me that you say we could define malicious
> traffic using layer 3 or 4 information when it is pretty common to
> use actual payload contents to detect malicious traffic. Or, are
You can use payload to do this, if you can see the payload... or if you
want to incur the extra cycles to get to the payload. If you see a packet
sourced from a 'bad' address (rfc1918 for instance, or your self in
another instance) or to an unused port you can classify at L3 or L4 (in
these 2 examples) the traffic as 'bad' or 'malicious'.
> you trying to say that after detection we can use some handy
> identifiers from layers 3 & 4 to take action? This could be more
> clear, I think.
>
I'll see if I can clarify the section which is:
-------------- section -----------------
7.2. Block Malicious Packets
Blocking or limiting traffic deemed to be malicious is a key component of
application of any security policy's implementation. Clearly it is
critical to be able to implement a security policy on a network.
Malicious packets could potentially be defined by any part of the layer-3
or layer-4 headers of the IP packet. The ability to classify or select
traffic based on these criteria and take some action based on that
classification is critical to operations of a network.
------------ end section ---------------
Perhaps:
"Malicious packets could potentially be defined by any part of, atleast,
the layer-3 or layer-4 headers of the IP packet."
You certainly could go deeper (higher?) in the packet and see payload
problems (http/1.23 vs 1.1) or you could go lower in the stack too (bad
framing or implausible/spoofed MAC addr) as well, so limiting the
discussion to just L3/L4 seems premature... Is that clearer? (the
'atleast' was added, fyi...)
a new version of the doc is at:
html - http://docs.as701.net/RFC/draft-ietf-opsec-filter-caps-08.html
rfc - http://docs.as701.net/RFC/draft-ietf-opsec-filter-caps-08.txt
(side note: vi/vim needs a 'make all lines XX chars long on word breaks'
feature, or I need to find said feature...)
Thanks for the comments,
Chris
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
