Filtering and Rate Limiting Capabilities for IP Network Infrastructure
draft-ietf-opsec-filter-caps-09

This text needs to be fixed:

      Examples of this may include filtering all traffic save SMTP
      (tcp/25) destined to a mail server.

In particular it contradicts draft-hutzler-spamops-08.txt, in addition
to the issues Sam raised in his abstain.  A mail server might provide
many services in addition to SMTP/25, such as SUBMIT/587, POP, IMAP,
LMTP, MTQP, ManageSieve, HTTP for webmail/management, etc.  In
addition it's likely to need access to LDAP for identity lookups, NTP
for clock synchronization and possibly NFS for support files.

I also agree with others that this document would be better as
informational, although I do not feel strongly enough to block
forward progress on that basis.

I understand what the document is trying to explain and agree with the desires. I find the document a bit difficult to read as it is organized and misleading.

I. The definition of the filter is selection criteria and actions. Then later under selection, the concept of selection of packets on interfaces is introduced.

What they are really trying to get across is that there are three steps (but, they took a short cut which lead to terminology and architectural contradictions):

     0) match criteria - conditions
     1) associate actions to match criteria - rules
     2) attach actions to interfaces or other entities (e.g. subscribers or sessions)- services


What becomes confusing and incorrect is that section 3 "Packet Selection Criteria" is really discussing attachment to interfaces vs match criteria or in some cases, blending the two. The two steps need to be clearly separated and treated accordingly.

The limitation of the current doc to be related only to interfaces doesn't meet the current state of the art with respect to what security attachment points are in use on the internet. Making this more generic seems appropriate.


II. The discussion of transit traffic is very light and week and should be considered removing it from the doc or explaining (referencing) that it is in fact an attempt at "control filtering" for a different scenario (your neighbor) vs the local router. The rules (using my terminology above) should be clearly laid out as they are going to be configured differently than rules for the local router. The match criteria may be the same, the interfaces they are attached to may be the same but, the rules will be (and are seen in the internet) to be dramatically different.

III. In section 3.6:

Differentiate unicast and multicast
Differentiate V4 vs V6 vs just src/dest
Differentiate known (aka configured) relationships vs unknown. 
     What I am getting at here is that you have different match criteria if you expect to hear from
     a peer vs one that is "out of the blue."
Differentiate between sessions established vs session requests
    What I am getting at here is that I want to be able to have different matches if I have 
    established an http/snmp/ssh/whatever session vs a request. The authors allude to
    this (although don't go far enough) wrt TCP packets but, it should be made more generic.
Allow ranges for relevant variables (addrs, ports, etc)

IV. Policies
This section covers actions of permit|deny|reject and some policer actions. What is missing is shaping, packet marking, redirection, burst specification and assignment to internal prioritized queues.

Logging and counting appear to be the only recommended action. This seems incomplete and traps/informs would need to be generated. In the section on what should be displayed, there needs to be a statement that they need to be organized by match, policy or attachment point (or any combination of the three) and that all variables that were used to match or set policy along with some "default" items need to be visualized.


In general, this document is begging the question of BCP (for which I think it is incomplete or inaccurate), Informational (things to think about) or leading to a set of PS docs (complete specification of match, policy, attach rules and appropriate management/ops docs ... aka MIB). The latter set is what is needed.

My Discuss is similar to Lars's Discuss, but I wanted
to point out a few specific examples that need to be
corrected:

> Some denial of service attacks are based on the ability to flood
> the victim with ICMP traffic.  One quick way to mitigate the
> effects of such attacks is to drop all ICMP traffic headed toward
> the victim.  It should be noted ([RFC2923]) that one possibly
> negative implication of filtering all ICMP traffic towards a
> victim is that legitimate functions which rely upon successful
> delivery of ICMP messages to the victim (e.g., ICMP unreachables,
> Type-3 messages) will not be received by the victim.

Please be more explicit about the implications. E.g., 
the formulation about "possibly negative" should be changed.
Also, for IPv6 the situation is quite different, and you
should refer to RFC 4890.

> Supporting arbitrary offset/length/value selection allows
> filtering of unknown (possibly new) protocols, e.g. filtering RTP
> even when the device itself does not support RTP.

Really? I thought RTP runs on dynamic ports, and does not have
a lot of fixed data items that you could use to determine
whether you really have an RTP packet. Some algorithms from
Appendix A of RFC 3550 may be used perhaps to guess whether
you have a packet, but its far from a deterministic process.

This document should not be a BCP, for two reasons.

First, it is unclear what the current practice is that is attempts to recommend. What it does contain is a not very well organized and described set of filtering and rate-limiting capabilities that would be needed to support RFC4778. (That RFC, by the way, is Informational.) It doesn't describe any best current practices.

Second, I agree with Sam that the examples in this document are problematic. Nearly all of the example policies have well-known side effects that make them unsuitable for indiscriminate use. The document touches upon this only very lightly for the one filter in Section 4.1, where it mentions that silently dropping traffic is problematic and points to RFC3360 (which, by the way, is on TCP resets, which is something entirely different.) Making this document a BCP could be understood as recommending the example policies it contains, which must be avoided.

  On the IETF Mail List, Barry Greene and Chris L. Morrow (one of the
  document authors) stated that they thought Informational RFC was more
  appropriate than BCP for this document.  No one offered a rationale
  for BCP.  I do not think the IESG should approve this as a BCP unless
  that discussion takes place.

  From the Gen-ART Review by Mark Allman:

  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.