Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
draft-ietf-opsec-ip-options-filtering-07
Yes
(Joel Jaeggli)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
Note: This ballot was opened for revision 05 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2013-11-19 for -05)
Unknown
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 Former IESG member
Yes
Yes
(for -05)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2013-11-21 for -05)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(2013-11-15 for -05)
Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection
(2013-11-21 for -05)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(2013-11-18 for -05)
Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2013-11-18 for -05)
Unknown
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.
Richard Barnes Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-11-22 for -06)
Unknown
Thanks for handling my discuss and educating me on IPv4 options!
Stewart Bryant Former IESG member
No Objection
No Objection
(2013-11-21 for -05)
Unknown
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. ==============
Ted Lemon Former IESG member
No Objection
No Objection
(2013-11-20 for -05)
Unknown
This is a great document. Thanks for working on it!