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

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.

   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.

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.

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.

Thanks for handling my discuss and educating me
on IPv4 options!

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.

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

This is a great document.   Thanks for working on it!