Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01

[Carlos Pignataro <[e-mail]>]

Hi Fernando,

I wanted to share some high-level comments on this I-D. I hope this is
useful feedback.

The great majority of this document as currently structured dives into
details about fifteen IPv4 Options, assessing threat model -> impact if
blocked -> advise. I think that the threat -> impact -> advise is a good
model.

However, this flow seems to make some strong underlying assumptions:
1. It may assume that the current state is that options are not blocked.
But currently, IP optioned packets do not have unfiltered success in the
Internet:
http://www.ietf.org/mail-archive/web/int-area/current/msg02334.html
http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html

2. It assumes that devices (i.e., routers) have the capability to filter
IP optioned packets with the per-option-value granularity. This might
not generally be the case.

3. It assumes that a desired granularity is to filter at the option
level, generally. This might result in increased and unjustified OpEx,
and an operator might chose to simply make a blanked determination, even
when the capability to filter per-option might exist.

Additionally,

4. There may be more than "filter" versus "not-filter" options. Some
platforms support ignoring IP options (i.e., acting as if an IP Optioned
packet did not have options), and that is a potential recommendation.

5. Doing an enumeration of all options would either need to be
exhaustive (and it appears that the document does not contain all option
values from <http://www.iana.org/assignments/ip-parameters>, e.g., 147),
or provide a catch-all final else clause in the conditional. This is
also solved by providing a non-per-option-value discussion.

Based on this, I believe that a document about ip-options-filtering
should start at a much higher level discussing coarse granularity (less
opex) options, as well as reasons for a perceived current state. There
are operational considerations to doing per-option-value filtering
versus generic option filtering or ignoring, and I believe those should
be discussed early on on the document.

Some more specific comments:

I suspect that the phrase "IP Options filtering" that is used throughout
the doc can be a bit ambiguous. The options are not filtered, the whole
optioned datagram is.

The intended status listed is BCP, and I wonder if that is what this
document is providing. More than a current practice (which arguably is
to filter or ignore without looking at the option value, modulo
exceptions), it appears to provide Information about impact of filtering
particular options.

The first sentence of Section 3, "Router manufacturers tend to do IP
option processing on the main processor, rather than on line cards",
speaks to specific router distributed architecture, and I think it might
be oversimplifying the current state.

For EOO and NOOP, the advise is to:

   No security issues are known for this option, other than the general
   security implications of IP options discussed in Section 2.

But I think that the general implications are the most important part of
this document but are minimal.

The document does not describe what the resulting disposition of a
packet with many options should be.

Nits:

There seems to be an inconsistency with the timestamp option:

   The timestamp option has a number of security implications.  Among
   them are:
...
   No security issues are known for this option, other than the general
   security implications of IP options discussed in Section 2.

The short title is "IPv4 Security Assessment".

There

I hope these comments are clear, please do let me know anything that
does not parse, I hope this is useful.

Thanks,

-- Carlos.


On 4/26/2011 6:52 PM, Fernando Gont wrote:
> Folks,
> 
> We have published a revision of our I-D "IP Options Filtering
> Recommendations". It is available at:
> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01
> 
> Publication of this document had been suggested at the Hiroshima IETF.
> Version -00 had expired a while ago, and I decided to invest some time
> and bring this document back to life. This time with much help from Ran
> Atkinson, who is co-authoring this latest rev.
> 
> Any comments will be welcome.
> 
> Thanks!
> 
> Best regards,
> Fernando
> 
> 
> 
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-gont-opsec-ip-options-filtering-01
> Date: Tue, 26 Apr 2011 15:31:13 -0700 (PDT)
> From: IETF I-D Submission Tool <[e-mail]>
> To: [e-mail]
> CC: [e-mail]
> 
> 
> A new version of I-D, draft-gont-opsec-ip-options-filtering-01.txt has
> been successfully submitted by Fernando Gont and posted to the IETF
> repository.
> 
> Filename:	 draft-gont-opsec-ip-options-filtering
> Revision:	 01
> Title:		 IP Options Filtering Recommendations
> Creation_date:	 2011-04-27
> WG ID:		 Independent Submission
> Number_of_pages: 26
> 
> Abstract:
> This document document provides advice on the filtering of packets
> based on the IP options they contain.  Additionally, it discusses the
> operational and interoperability implications of such filtering.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>