Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
draft-ietf-opsec-ip-options-filtering-07

07 addressed outstanding lc comments with some minor text changes. I have personally reviewed them and do not believe that the iesg does not need to revist them.

[Ballot comment]
I wish we produced docs like this more often. Thanks for working on it.

I agree with Pete that the 2119 language seems odd, but whatever works for him will work for me.

[Ballot comment]
From a purely historical point of view I think that the following is a
little late:

"From about 1995 onwards, a growing number of IP routers have
incorporated specialized IP packet processing silicon (i.e., FPGA,
ASIC), "

The processing split that you are concerned about happened
much earlier that this. For example Cisco launched the AGS+
using this forwarding model in1989, and thereafter it was
pretty much the only way to design a high-speed router.

The person that knows most about the history is Scott Bradner
who provided the definitive router bench tests in those days
and thus tracked the architectural changes in some detail.

==============

However, at
  present, the particular architectural and engineering details of the
  particular IP router being considered are important to understand
  when evaluating the operational security risks associated with a
  particular IP packet type or IP option type.

"important" or "not important"?

==============

I am surprised that the advice for new implementations is not MUST
drop the  obsolete (and maybe experimental) options. There surely
cannot be any of them in deployment by now. At the least it should
surely be MUST default to drop.

==============

[Ballot comment]
  We also note that while this document provides advice on dropping
  packets on a "per IP option type", not all devices may provide this
  capability with such granularity.  Additionally, even in cases in
  which such functionality is provided, the operator might want to
  specify a dropping policy with a coarser granularity (rather than on
  a "per IP option type" granularity), as indicated above.

  Finally, in scenarios in which processing of IP options by
  intermediate systems is not required, a widespread approach is to
  simply ignore IP options, and process the corresponding packets as if
  they do not contain any IP options.

The first paragraph speaks of device, while the second speaks of intermediate systems.
So what's a device? I guess you only mean an intermediate system and not an end host, correct?
I see later, for ex. in section 4.1.5 that you have advice for Routers, security gateways, and firewalls.
Please expand in the intro what you have in mind with "device".
For example: the advice in this document focus on routers, security gateways, firewalls

As I conclude from ongoing discussions, this document targets operators and "routers, security gateways, firewalls" vendors.
I also see that you want to add this paragraph below. Fine, but
s/implementers/routers, security gateways, firewalls implementers

+  Finally, in addition to advice to operators, this document also
+  provides advice to implementers in terms of providing the capability
+  to filter packets with different granularities: both on a "per IP
+  option type" granularity (to maximize flexibility) as well as more
+  coarse filters (to minimize configuration complexity).

- Section 4.6.5
  Routers, security gateways, and firewalls SHOULD drop IP packets
  containing a Stream Identifier option.
This option is obsolete. Either it's a MUST, or if you keep a SHOULD, then you should log the event if you see this option.
We could debate what to do with "SHOULD drop" advice when the option is not obsolete (4.9.5, 4,11.5, and maybe others) but IMHO, the event must be logged.
So the Routers, security gateways, and firewalls MUST provide the ability to log the event. Potentially a generic requirement


- 
  This option probably
  has more deployment now than when the IESG removed this option from
  the IETF standards-track.

Can you please expand on this counter-intuitive observation.

[Ballot discuss]

So I'm not sure if this really needs fixing but 4.23.1
notes that RFCs 1122 and 1812 say you MUST ignore
unknown options, but 4.23.4 here says that you SHOULD
have a configuration knob with a "drop & log" setting.
If that knob is set to "drop & log" then that node
would seem to no longer be compliant with 1122 or 1812.
Yet this document doesn't update those, nor say why
that's ok. Why is that ok? If even a small percentage
of nodes turn that knob to "drop & log" wouldn't that
mean that no new IPv4 option with very broad impact
could ever be introduced in future?

[Ballot comment]

- 4.12 and 4.13 seem to have a lot of duplicated
text so it wasn't clear to me how they differed
if at all.

[Ballot comment]
Thanks for this document. I support its publication.

---

I agree with Pete that the value of using RFC 2119 language in the
"Advice" sections is questionable. For me it just disrupts the flow of
the text and is somewhat ambiguous - what does it mean to advise that
you MUST do something? But this is just my opinion.

---

It is possible that some of your Informational references are really
normative. For example, 6398 is used to define some terms that you use
and also to describe some environments that you reference. This is not
very important, but perhaps you could take a quick look at your
references to see how you feel about them.

[Ballot comment]
A question: Are router vendors already adopting these recommendations? If not, are we sure they're going to? That is, is this document aspirational or is the actual ops community on board with this?

Overall editorial comment: It might have been nice if the "Advice" sections got reduced to one or two keywords. You could have defined up at the top of the document "DROP", "FORWARD", "CONFIGURABLE", "DEFAULT DROP", "DEFAULT FORWARD", "LOG", and then just used those terms. You could have even made a handy-dandy table of options and advice and saved people the read if they just wanted to take the advice without caring why.

Also, I think the 2119 use in this document is unnecessary. You're only using "SHOULD" and "SHOULD NOT" throughout, and in all those cases you really mean "This is the best plan" or "This is not the best plan", not really what 2119 says.

But it's up to the WG whether either of those editorial issues are worth addressing.

[Ballot comment]
This is a useful piece of work.  I only have two nit-like comments that you can take or leave...

1. The end of section 3 suggests that operators should take a device's IP options filtering capabilities into account when making deployment decisions.  Should a similar statement be made that this document is focused on recommendations for vendors to provide filtering support/capabilities for IP options?

2. A little pedantic, but if an option is obsolete wouldn't its presence in a packet indicate a possible covert channel?  If that is the case, options like the one described in 4.6 should have a covert channel listed as a possible threat.

[Ballot comment]
One small editorial comment:

-- Section 4.3 --

  RFC 791 states that this option should appear, at most, once in a
  given packet.

Both commas are spurious, and should be removed.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsec-ip-options-filtering-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Recommendations on filtering of IPv4 packets containing IPv4 options.) to Best Current Practice


The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'Recommendations on filtering of IPv4 packets containing IPv4 options.'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides advice on the filtering of IPv4 packets based
  on the IPv4 options they contain.  Additionally, it discusses the
  operational and interoperability implications of dropping packets
  based on the IP options they contain.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/ballot/


No IPR declarations have been submitted directly on this I-D.

some thoughts from my review.

1. I'm not sure sure we should be getting all the alarms from the NITs on the table in 4.23.1I leave it you you to device how to reformat that or site them.

2. obsoleted refences to documents where both the current and obsoleted version are cited e.g.


4.12.2.  Option Specification

  It is specified by RFC 1108 [RFC1108]], which obsoleted RFC 1038
  [RFC1038] (which in turn obsoleted the Security Option defined in RFC
  791 [RFC0791]).

could probably reference the current version only without causing confusion.

3. Third citatations of  current implementations of something found in IRIX seem a little silly.  6.5.30 was the last release and that was something like 8 years ago, the hardware that shipped with it went EOS in 2006.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document captures the current thinking on operational and interoperability implications of filtering IPv4 packets based upon the IPv6 options that they contain, including guidance to operators on the best way to achieve this filtering. For this reason, we believe that BCP is the correct track.

(2) 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:

This document discusses the operational and interoperability implications of filtering IPv4 packets based on the IPv4 options they contain. It also provides advice to operators who wish to do such filtering.

Working Group Summary:

This document received in-depth review from some key WG members. The WGLC concluded that this is useful information that is presented in an easy to read format.

Document Quality:

This documents evaluates, in detail, every IPv4 option that has been specified so far and provides the following analysis:
1) The use case for each option
2) Specific threats that have been identified with said option
3) Operational implications of blocking said option
4) Very specific advice to operators on how to deal with said option
The format in which the information is provided makes this document very easy to read. This is very useful information for operators of Internet Service Provider and Enterprise networks.

Personnel:

Kiran Kumar Chittimaneni (KK) is the Document Shepherd. Joel Jaeggli is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The Document Shepherd (also a WG chair) has followed the progression of the draft through revisions and the WG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A WGLC was initiated, and then extended to get additional review from key WG members. The Shepherd believes that there is now sufficient review, both in terms of volume, and expertise.

(5) Do portions of the document need review from a particular or from broader perspective?

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document?

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document?

The most involved / active WG participants did respond and their comments were supportive. We also requested a thorough review from three key members of the WG. We believe there is general consensus in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

Not at all.

(11) Identify any ID nits the Document Shepherd has found in this document.

-- Obsolete informational reference: RFC 2407 (Obsoleted by RFC 4306)
-- Outdated reference: A later version (-03) exists of draft-stoica-diffserv-dps-02

-- The ID Nits tool spat out a few missing references (people)
== Missing Reference: 'ZSu' is mentioned on line 1239, but not defined
== Missing Reference: 'Finn' is mentioned on line 1240, but not defined
== Missing Reference: 'VerSteeg' is mentioned on line 1241, but not defined
== Missing Reference: 'Lee' is mentioned on line 1242, but not defined

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

No - all normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None.

(16) Will publication of this document change the status of any existing RFCs?

No / N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section.

No IANA action requested or required. This matches the text of the document.

(18) List any new IANA registries that require Expert Review for future allocations.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None / N/A.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document captures the current thinking on operational and interoperability implications of filtering IPv4 packets based upon the IPv6 options that they contain, including guidance to operators on the best way to achieve this filtering. For this reason, we believe that BCP is the correct track.

(2) 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:

This document discusses the operational and interoperability implications of filtering IPv4 packets based on the IPv4 options they contain. It also provides advice to operators who wish to do such filtering.

Working Group Summary:

This document received in-depth review from some key WG members. The WGLC concluded that this is useful information that is presented in an easy to read format.

Document Quality:

This documents evaluates, in detail, every IPv4 option that has been specified so far and provides the following analysis:
1) The use case for each option
2) Specific threats that have been identified with said option
3) Operational implications of blocking said option
4) Very specific advice to operators on how to deal with said option
The format in which the information is provided makes this document very easy to read. This is very useful information for operators of Internet Service Provider and Enterprise networks.

Personnel:

Kiran Kumar Chittimaneni (KK) is the Document Shepherd. Joel Jaeggli is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The Document Shepherd (also a WG chair) has followed the progression of the draft through revisions and the WG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A WGLC was initiated, and then extended to get additional review from key WG members. The Shepherd believes that there is now sufficient review, both in terms of volume, and expertise.

(5) Do portions of the document need review from a particular or from broader perspective?

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document?

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document?

The most involved / active WG participants did respond and their comments were supportive. We also requested a thorough review from three key members of the WG. We believe there is general consensus in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

Not at all.

(11) Identify any ID nits the Document Shepherd has found in this document.

-- Obsolete informational reference: RFC 2407 (Obsoleted by RFC 4306)
-- Outdated reference: A later version (-03) exists of draft-stoica-diffserv-dps-02

-- The ID Nits tool spat out a few missing references (people)
== Missing Reference: 'ZSu' is mentioned on line 1239, but not defined
== Missing Reference: 'Finn' is mentioned on line 1240, but not defined
== Missing Reference: 'VerSteeg' is mentioned on line 1241, but not defined
== Missing Reference: 'Lee' is mentioned on line 1242, but not defined

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

No - all normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None.

(16) Will publication of this document change the status of any existing RFCs?

No / N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section.

No IANA action requested or required. This matches the text of the document.

(18) List any new IANA registries that require Expert Review for future allocations.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None / N/A.