Filtering and Rate Limiting Capabilities for IP Network Infrastructure
draft-ietf-opsec-filter-caps-09
Approval announcement
Draft of message to be sent after approval:
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
opsec mailing list <opsec@ietf.org>,
opsec chair <opsec-chairs@tools.ietf.org>
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:
http://www.ietf.org/internet-drafts/draft-ietf-opsec-filter-caps-09.txt
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
believes
that this draft has received adequate review and is ready
for
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?
No.
(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
document.
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
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). 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
tool.
(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
practices
related to securing networks. The OPSEC working group
developed a
series of documents identifying device capabilities to
support
those practices. This document lists filtering
and rate limiting capabilities needed to support those
practices.
Capabilities are limited to filtering and rate limiting
packets
as they enter or leave the device. Route filters and
service
specific filters (e.g. SNMP, telnet) are covered in other
documents.
Note that Capabilities are defined without reference to
specific
technologies. This is done to leave room for deployment of
new
technologies that implement the capability. Each capability
cites the practices it supports. Current implementations
that
support the capability are cited. Special considerations
are
discussed as appropriate listing operational and resource
constraints,
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.
Personnel
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.
(end)