Filtering and Rate Limiting Capabilities for IP Network Infrastructure

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

(Jari Arkko) Discuss

Discuss (2007-08-22)
My Discuss is similar to Lars's Discuss, but I wanted
to point out a few specific examples that need to be

> 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.
Comment (2007-08-22)
No email
send info
Review by Christian Vogt:

Draft-ietf-opsec-filter-caps-09 describes filtering and rate-limitation
capabilities in routers that are required for operators to maintain a desired
level of network security.  The requirements are based on real-life practices
that operators employ today.

The draft matches required router capabilities with current practices.  This
looks technically sound to me, yet there are some editorial opportunities for

- Section 2 provides an overview on filter rules.  It would be nice if this
section stated somewhere that a filter is, basically, a triple of a selection
criterion, an action, and a counter of how many times the selection criterion
was met.  The section never says it this clearly.  It even takes until section
4.5 for the existence of counters to be mentioned.

- Its unclear what is meant by "accounting treatment" in section 2.  This term
is not explained and it gets never mentioned again in the entire draft.

- The use of the term "any interface" in the title of section 3.1 is misleading.
 It could mean "regardless which interface", and hence effectively "all
interfaces".  Maybe rephrase it to "any individual interface".

- Section 4.5 mentions counters, but only section 5 explains what a counter is.

- Section 6 should better be renamed "Requirements" or similar.  This would make
it more obvious that the section is really about prerequisites that a filter
implementation is to fulfill.

- The draft talks about "filtering and rate-limiting" as if it were two separate
techniques, yet it technically defines rate-limiting to be just one type of
filter amongst multiple others.

- The matching between capabilities and practices is presented by listing
practices in one section, and providing pointers to those (and the additional
practices in RFC 4778) in a different section that lists the capabilities.  An
additional table would make it easier for the reader.  But maybe, the limits of
ASCII prevent this to be done in a reasonably attractive manner.

(Lars Eggert) Discuss

Discuss (2007-08-22)
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.
Comment (2007-08-22)
No email
send info
Even going for Informational, I believe this document needs more work. The descriptions of the various capabilities are not very precise, the examples need significant work, and the presentations is lacking. Going Informational with this revision will make me join Sam in abstaining; I hope that the authors will consider revising the document so that I can put in a no-ob.

(Russ Housley) Discuss

Discuss (2007-08-17)
  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
Comment (2007-08-17)
No email
send info
  From the SecDir Review by Stephen Farrell:
  The introduction says that the document will specify the intended
  audience, but the word audience only occurs once.

(Chris Newman) Discuss

Discuss (2007-08-23)
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.

(David Ward) Discuss

Discuss (2007-08-20)
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.

(Ron Bonica) Yes

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

Comment (2007-08-21)
No email
send info
1. While the Abstract mentions that service specific filters as SNMP or Telnet are out of scope, section 3.3 seems to use as examples exactly this kind of applications. 

2. Section 4 - Actions should include the capability of sending notifications in the actions list and describe this accordingly

3. It is not clear why section 7.3 is relevant to this document. While true and maybe something that was missed in RFC 4778 it does not seem to have something to do with filtering and rate limiting capabilitites.

(Sam Hartman) Abstain

Comment (2007-08-21)
No email
send info
I find the examples in this document problematic.  The text proposes
dropping everything except port 25 to a mail server without noting
that doing so would break ICMP path MTU etc.  Even the discussion of
why dropping all ICMP to a destination is problematic seems to lack a
sufficient health warning.

Overall I find the examples in section 3 sufficiently bad that I've chosen to abstain.

(Ross Callon) Recuse

Comment (2007-08-01)
No email
send info
I am recusing as WG co-chair. I think that this is quite a good document (I would have voted "yes" if I didn't need to recuse).

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Martin Duke No Record

(Cullen Jennings) (was No Objection) No Record

Comment (2007-08-16)
No email
send info
The terms defined in the definitions don't seem to be used in the document. 

I think the selection by Protocol Header Fields would be much better if it had more information for implementers. Often when the IP packet has an option field, implementers don't realize this moves the position of fields in the UDP packet. 

In the arbitrary header based selection, how deep into the packet does the the filter need to be able to look. 

There is some problem with the text in section 5.4 "Filter counters are be capable of holding up" ... I think this mean to have MUST instead of "are"

Benjamin Kaduk No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Barry Leiba No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record