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 |