Filtering and Rate Limiting Capabilities for IP Network Infrastructure

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    opsec mailing list <>, 
    opsec chair <>
Subject: Protocol Action: 'Filtering and Rate Limiting 
         Capabilities for IP Network Infrastructure' to BCP 

The IESG has approved the following document:

- 'Filtering and Rate Limiting Capabilities for IP Network Infrastructure '
   <draft-ietf-opsec-filter-caps-09.txt> as a BCP

This document is the product of the Operational Security Capabilities for 
IP Network Infrastructure Working Group. 

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet-Draft is:

Document Shepherd Write-Up

(1.a)  Who is the Document Shepherd for this document?  Has the
       Document Shepherd personally reviewed this version of the
       document and, in particular, does he or she believe this
       version is ready for forwarding to the IESG for publication?
		Pat Cain, OPSEC, co-chair is the document shepherd, and
		that this draft has received adequate review and is ready
		forwarding to the IESG for review ad publication.

(1.b)  Has the document had adequate review both from key WG members
       and from key non-WG members?  Does the Document Shepherd have
       any concerns about the depth or breadth of the reviews that
       have been performed?

		The document has had adequate review from the WG, other 
		IETF areas, and non-IETF operator forums.

(1.c)  Does the Document Shepherd have concerns that the document
       needs more review from a particular or broader perspective,
       e.g., security, operational complexity, someone familiar with
       AAA, internationalization or XML?


(1.d)  Does the Document Shepherd have any specific concerns or
       issues with this document that the Responsible Area Director
       and/or the IESG should be aware of?  For example, perhaps he
       or she is uncomfortable with certain parts of the document, or
       has concerns whether there really is a need for it.  In any
       event, if the WG has discussed those issues and has indicated
       that it still wishes to advance the document, detail those
       concerns here.  Has an IPR disclosure related to this document
       been filed?  If so, please include a reference to the
       disclosure and summarize the WG discussion and conclusion on
       this issue.

		Since this document is not a protocol, there was significant
		discussion in the WG on the intended status of this
		The WG believes that this is really a BCP and wishes to 
		forward this document as a candidate BCP.

(1.e)  How solid is the WG consensus behind this document?  Does it
       represent the strong concurrence of a few individuals, with
       others being silent, or does the WG as a whole understand and
       agree with it?
		A large number of WG members lively reviewed versions 
		of this draft.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
       discontent?  If so, please summarise the areas of conflict in
       separate email messages to the Responsible Area Director.  (It
       should be in a separate email because this questionnaire is
       entered into the ID Tracker.)

		Not that the shepherd is aware of.

(1.g)  Has the Document Shepherd personally verified that the
       document satisfies all ID nits?  (See and  Boilerplate checks are
       not enough; this check needs to be thorough.  Has the document
       met all formal review criteria it needs to, such as the MIB
       Doctor, media type and URI type reviews?

		The document successfully completed v.2.04.03 of the idnit

(1.h)  Has the document split its references into normative and
       informative?  Are there normative references to documents that
       are not ready for advancement or are otherwise in an unclear
       state?  If such normative references exist, what is the
       strategy for their completion?  Are there normative references
       that are downward references, as described in [RFC3967]?  If
       so, list these downward references to support the Area
       Director in the Last Call procedure for them [RFC3967].

		The references in the document are all non-normative as far 
		as we can tell. As such they are not differentiated.

(1.i)  Has the Document Shepherd verified that the document IANA
       consideration section exists and is consistent with the body
       of the document?  If the document specifies protocol
       extensions, are reservations requested in appropriate IANA
       registries?  Are the IANA registries clearly identified?  If
       the document creates a new registry, does it define the
       proposed initial contents of the registry and an allocation
       procedure for future registrations?  Does it suggest a
       reasonable name for the new registry?  See [RFC2434].  If the
       document describes an Expert Review process has Shepherd
       conferred with the Responsible Area Director so that the IESG
       can appoint the needed Expert during the IESG Evaluation?

		Yes (This was the change from -05 to -06.)

(1.j)  Has the Document Shepherd verified that sections of the
       document that are written in a formal language, such as XML
       code, BNF rules, MIB definitions, etc., validate correctly in
       an automated checker?
		Yes, we have no such sections.

(1.k)  The IESG approval announcement includes a Document
       Announcement Write-Up.  Please provide such a Document
       Announcement Write-Up?  Recent examples can be found in the
       "Action" announcements for approved documents.  The approval
       announcement contains the following sections:

       Technical Summary
		Operational Security Current Practices in Internet 
		Service Provider Environments [RFC4778] lists operator
		related to securing networks.  The OPSEC working group
developed a
 		series of documents identifying device capabilities to
		those practices. This document lists filtering 
		and rate limiting capabilities needed to support those
		Capabilities are limited to filtering and rate limiting
		as they enter or leave the device.  Route filters and
		specific filters (e.g.  SNMP, telnet) are covered in other

   		Note that Capabilities are defined without reference to
		technologies.  This is done to leave room for deployment of
		technologies that implement the capability.  Each capability

		cites the practices it supports.  Current implementations
		support the capability are cited.  Special considerations
		discussed as appropriate listing operational and resource
		limitations of current implementations, trade-offs, etc.

        Working Group Summary
          	The WG consulted with many operators and vendors to come to 
		consensus with the capability documents.

       Document Quality
		The document defines capabilities, many already included 
		within network devices.

          Who is the Document Shepherd for this document?  Who is the
          Responsible Area Director?

		DS == Pat Cain
		rAD == Ron Bonica

RFC Editor:

Please add the following text to the security considerations section:

   For a general threat analysis of 6to4, especially the additional risk
   of address spoofing in 2002::/16, see [RFC3964].

   Section 4 notes that the local site administrator could take
   appropriate access control measures to prevent clients inside a 6to4
   site performing unauthorized changes to the delegation details.  This
   may be in the form of a firewall configuration regarding control of
   access to the service from the interior of 6to4 site, or a similar
   mechanism that enforces local access policies.