Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from opsec-chairs@ietf.org, chris@uu.net, gmj3871@pobox.com, vishwas@ipinfusion.com to vishwas@ipinfusion.com, gmj3871@pobox.com, chris@uu.net
2008-03-10
09 (System) State Changes to Dead from AD is watching by system
2008-03-10
09 (System) Document has expired
2008-02-28
09 Ron Bonica State Changes to AD is watching from IESG Evaluation::Revised ID Needed by Ron Bonica
2007-08-23
09 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-08-23
09 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings
2007-08-23
09 Ron Bonica State Change Notice email list have been change to opsec-chairs@tools.ietf.org, chris@uu.net, gmj3871@pobox.com, vishwas@ipinfusion.com from opsec-chairs@tools.ietf.org
2007-08-23
09 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-08-23
09 Chris Newman
[Ballot discuss]
This text needs to be fixed:

      Examples of this may include filtering all traffic save SMTP
      (tcp/25) …
[Ballot discuss]
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.
2007-08-23
09 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2007-08-22
09 Jari Arkko
[Ballot discuss]
My Discuss is similar to Lars's Discuss, but I wanted
to point out a few specific examples that need to be
corrected:

> …
[Ballot discuss]
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.
2007-08-22
09 Jari Arkko
[Ballot discuss]
My Discuss is similar to Lars's Discuss, but I wanted
to point out a few specific examples that need to be
corrected:

> …
[Ballot discuss]
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.
2007-08-22
09 Jari Arkko
[Ballot comment]
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 …
[Ballot comment]
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
improvement.

- 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.
2007-08-22
09 Jari Arkko
[Ballot discuss]
My Discuss is similar to Lars's Discuss, but I wanted
to point out a few specific examples that need to be
corrected:

> …
[Ballot discuss]
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.
2007-08-22
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2007-08-22
09 Lars Eggert
[Ballot comment]
Even going for Informational, I believe this document needs more work. The descriptions of the various capabilities are not very precise, the examples …
[Ballot comment]
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.
2007-08-22
09 Lars Eggert
[Ballot discuss]
This document should not be a BCP, for two reasons.

First, it is unclear what the current practice is that is attempts to …
[Ballot discuss]
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.
2007-08-22
09 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2007-08-21
09 Sam Hartman
[Ballot comment]
I find the examples in this document problematic.  The text proposes
dropping everything except port 25 to a mail server without noting
that …
[Ballot comment]
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.
2007-08-21
09 Sam Hartman [Ballot Position Update] New position, Abstain, has been recorded by Sam Hartman
2007-08-21
09 Dan Romascanu
[Ballot comment]
1. While the Abstract mentions that service specific filters as SNMP or Telnet are out of scope, section 3.3 seems to use as …
[Ballot comment]
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.
2007-08-21
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-08-20
09 David Ward
[Ballot discuss]
I understand what the document is trying to explain and agree with the desires. I find the document a bit difficult to read …
[Ballot discuss]
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.
2007-08-20
09 David Ward
[Ballot discuss]
I understand what the document is trying to explain and agree with the desires. I find the document a bit difficult to read …
[Ballot discuss]
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.



Just to sum, the doc should be split in
2007-08-20
09 David Ward [Ballot Position Update] New position, Discuss, has been recorded by David Ward
2007-08-17
09 Russ Housley
[Ballot comment]
From the SecDir Review by Stephen Farrell:
 
  The introduction says that the document will specify the intended
  audience, but the …
[Ballot comment]
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.
2007-08-17
09 Russ Housley
[Ballot comment]
From the SecDir Review by Stephen Farrell:
 
  The introduction says that the document will specify the intended
  audience, but the …
[Ballot comment]
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.

  From the Gen-ART Review by Mark Allman:

  Sec 1.2: "threat model of this document" -->
  "threat model assumed in this document"

  Sec 3.1 (and others places too): "and or" --> "and/or"

  Sec 3.5: "It allows invalid or malicious traffic" -->
  "It allows traffic judged to be invalid or malicious"

  Sec 3.6: I'd suggest a reference to the PMTUD blackhole RFC (2923)
  where you mention the negatives of dropping ICMPs.

  Sec 4.1 (and others places too): "TCP Resets." -->
  "TCP Resets, for instance."

  Sec 4.1: "(e.g., syslog" --> "(e.g., via syslog"

  Sec 5.1: "applied two" --> "applied to two"

  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 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.
2007-08-17
09 Russ Housley
[Ballot discuss]
On the IETF Mail List, Barry Greene and Chris L. Morrow (one of the
  document authors) stated that they thought Informational RFC …
[Ballot discuss]
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.
2007-08-17
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-08-16
09 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-08-16
09 Cullen Jennings
[Ballot comment]
The terms defined in the definitions don't seem to be used in the document.

I think the selection by Protocol Header Fields would …
[Ballot comment]
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"
2007-08-15
09 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2007-08-10
09 (System) Removed from agenda for telechat - 2007-08-09
2007-08-01
09 Ross Callon
[Ballot comment]
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 …
[Ballot comment]
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).
2007-08-01
09 Ross Callon [Ballot Position Update] New position, Recuse, has been recorded by Ross Callon
2007-07-27
09 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2007-07-27
09 Ron Bonica Ballot has been issued by Ron Bonica
2007-07-27
09 Ron Bonica Created "Approve" ballot
2007-07-27
09 Ron Bonica Placed on agenda for telechat - 2007-08-09 by Ron Bonica
2007-07-27
09 Ron Bonica State Changes to IESG Evaluation from Waiting for Writeup by Ron Bonica
2007-07-13
09 (System) New version available: draft-ietf-opsec-filter-caps-09.txt
2007-07-06
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Stephen Farrell.
2007-06-25
09 (System) State has been changed to Waiting for Writeup from In Last Call by system
2007-06-15
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Farrell
2007-06-15
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Farrell
2007-06-13
09 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2007-06-11
09 Nora Duhig Last call sent
2007-06-11
09 Nora Duhig State Changes to In Last Call from Last Call Requested by Nora Duhig
2007-06-11
09 Ron Bonica Last Call was requested by Ron Bonica
2007-06-11
09 (System) Ballot writeup text was added
2007-06-11
09 (System) Last call text was added
2007-06-11
09 (System) Ballot approval text was added
2007-06-11
09 Ron Bonica State Changes to Last Call Requested from AD Evaluation by Ron Bonica
2007-06-11
09 Ron Bonica State Changes to AD Evaluation from Publication Requested by Ron Bonica
2007-06-11
09 Ron Bonica Draft Added by Ron Bonica in state Publication Requested
2007-06-01
08 (System) New version available: draft-ietf-opsec-filter-caps-08.txt
2007-05-29
07 (System) New version available: draft-ietf-opsec-filter-caps-07.txt
2007-04-03
06 (System) New version available: draft-ietf-opsec-filter-caps-06.txt
2007-03-01
05 (System) New version available: draft-ietf-opsec-filter-caps-05.txt
2006-09-20
04 (System) New version available: draft-ietf-opsec-filter-caps-04.txt
2006-09-07
03 (System) New version available: draft-ietf-opsec-filter-caps-03.txt
2006-07-17
02 (System) New version available: draft-ietf-opsec-filter-caps-02.txt
2006-05-12
01 (System) New version available: draft-ietf-opsec-filter-caps-01.txt
2005-10-18
00 (System) New version available: draft-ietf-opsec-filter-caps-00.txt