Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
RFC 7126

Note: This ballot was opened for revision 05 and is now closed.

Spencer Dawkins Yes

Comment (2013-11-21 for -05)
No email
send info
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.

(Adrian Farrel) Yes

Comment (2013-11-19 for -05)
No email
send info
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.

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

Comment (2013-11-21 for -05)
No email
send info
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.

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

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-11-21 for -05)
No email
send info
   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.

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-11-22 for -06)
No email
send info
Thanks for handling my discuss and educating me
on IPv4 options!

(Brian Haberman) No Objection

Comment (2013-11-18 for -05)
No email
send info
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.

(Barry Leiba) No Objection

Comment (2013-11-15 for -05)
No email
send info
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.

(Ted Lemon) No Objection

Comment (2013-11-20 for -05)
No email
send info
This is a great document.   Thanks for working on it!

(Pete Resnick) No Objection

Comment (2013-11-18 for -05)
No email
send info
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.

(Martin Stiemerling) No Objection