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

From: Carlos Pignataro <[email-masked]>
Date: Thu, 12 May 2011 23:10:48 -0400

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 <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 13 May 2011 12:43:29 -0400

Donald,

Thanks for the response, some additional follow-ups inline.

On 5/13/2011 12:04 PM, Smith, Donald wrote:
> General comment this document needs a through spell checking:)
> Additional comments in line below.
> 
> 
> "When packets collide the controllers cease transmission AND wait a random time before retransmission (mostly)!"
> [email-masked]
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Carlos Pignataro
>> Sent: Thursday, May 12, 2011 9:11 PM
>> To: Fernando Gont
>> Cc: [email-masked]'
>> Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-
>> opsec-ip-options-filtering-01
>>
>> Hi Fernando,
>>
> I didn't read it that way.
> I read it to assume that ip options MIGHT not be filtered and therefore MAY arrive unfiltered.
> 

OK, I can see that too.

One thing that perhaps would help, as a suggestion, is to specify the
scope and instantiation of filtering. Is it through an ISP, to a Large
Enterprise datacenter, at the edge, or at some infrastructure?

> This appears to be about NEW IP options not known existing ones.
> 
> Here are the options used in the test.
> --ip-options \xc0\x06\xde\xad\xbe\xef\x00\x00
> 
> Hex C0 = 11000000 binary or 192 in decimal.
> I couldn't find an ip options type of 192.
> 

Yes, this test is for new options (which the doc should cover as well as
to what to do with "the rest" / unknown. The paper cited at the earlier
email, S4.3 of
<http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf>, covers
both existing and new options.

> I am familiar with the top carrier class router vendors and their ip options filtering ability.
> It certainly isn't complete but most support filtering many of the options identified in this document as potentially needing to be filtered.
> 

I know of routers that do via ACLs and routers that don't. And the ones
that do, they support all options either by specifying a name for a
well-known one or entering the type number.

Some "typical enterprise" might not deploy carrier class routers, at
least everywhere.

If most support it but some do not, I think the doc could speak to what
to do if not.

Frankly, I think this is more important in the next point, as operators
might choose to not deal with particular options by type but instead
with all at once, and differently though versus to the device.

> True enough, however I believe most ISPs are already blocking or ignoring many of the ip options that potentially need to be filtered.
> 

I agree, but in my experience, the way in which they are blocked is
often times all at once regardless of type, and differently through the
device (ignore options) versus to the device (drop).

> Strongly agree, ignoring an option from a SP perspective is much better then filtering them.
> Rate limiting them towards the control plane/RE is probably also a valuable recommendation but is at least partially covered in other rfc's.
> 

I agree with both these statements.

> If I can leave your packet unmolested and deny others an attack avenue against the router's RE that is always my first choice.
> Any packet I have to modify costs me some amount of processing and impacts our clients ability to generate traffic of their choice.
> 

That matches my experience as well. There is an opex variable as well,
so as to ignore all options through and drop all options to is a two-liner.

> Should we call out what an ISP should do vs. an enterprise?

I think so.

> Additionally recommending what a core router, edge router, PE, peering router and cpe should do?

I think so to. And the other variable to be explicit about is to vs.
through.

> 
> Additionally most of the recommendations say filter but I did see drop in at least one recommendation.
> 

What's the difference in meaning between the two?

> Both could be useful.

Agree.

> I agree this could provide additional value but am a bit concerned as others have suggested the document is too large:(
> 

I could agree that the document is too large. That was part of my
comment in regards to structure. However having:

1. A description of all-or-nothing filtering and ignoring at the
beginning, followed by

2. a table summarizing the per-option citations and dispositions

Can provide a concise kernel of information, followed by details for
completeness.

Just a suggestion.

> Again from an SP perspective this is current and correct most large router vendors today use the ASIC forwarder and RE/CPU architecture.
> Many have added additional layers so it may be asic for most forwarding, then a shared NP for some other work, then a Routing Engine.
> 

Right, but LCs have processors that perform CP functions often times,
and like you say there are layers of forwarding.

I agree though with the point that (I understand) is being made here,
since there is no hop-by-hop versus end-to-end concept for IPv4 options,
there is a different (and more CPU-expensive) processing path for IPv4
Optioned packets than optionless ones. I would just suggest, as an
editorial, to make that point explicitly and in a timeless way without
delving into routing architectures.

Thanks,

-- Carlos.

> This communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly
> prohibited and may be unlawful.  If you have received this communication
> in error, please immediately notify the sender by reply e-mail and destroy
> all copies of the communication and any attachments.
>

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 13 May 2011 10:04:50 -0600

Both could be useful.

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 13 May 2011 13:09:18 -0600

Your welcome!
Mostly we are agreeing but a comment or two below.

h8Hz
[email-masked]

> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Friday, May 13, 2011 10:43 AM
> To: Smith, Donald
> Cc: 'Fernando Gont'; [email-masked]'
> > "When packets collide the controllers cease transmission AND wait a
> random time before retransmission (mostly)!"
> > [email-masked]
> >
> >
Lots of ways to slice and dice this one but primary function of the router makes the most sense to me.

> both existing and new options.

So do we lump all of the "never seen in the wild" values together.
Or should we have 'assigned but seldom seen' category vs undefined vs new ... ??

> > It certainly isn't complete but most support filtering many of the
> options identified in this document as potentially needing to be
> filtered.
> >
>
Agreed.

> with all at once, and differently though versus to the device.

Through vs. to is an important distiction but where through also means "hits the RE" there is less difference as the effect can be similar.

> > True enough, however I believe most ISPs are already blocking or
> ignoring many of the ip options that potentially need to be filtered.
> >
>
The all ignore has some issues as Fernando points out RSVP for example can be impacted.
Now if you can say "process this type" and ignore the rest that's probably the best approach.

> > Rate limiting them towards the control plane/RE is probably also a
> valuable recommendation but is at least partially covered in other
> rfc's.
> >
>
> > If I can leave your packet unmolested and deny others an attack
> avenue against the router's RE that is always my first choice.
> > Any packet I have to modify costs me some amount of processing and
> impacts our clients ability to generate traffic of their choice.
> >
>
I think they are meant to be the same. I was pointing out an inconsistenty.
Fernando if you inteded drop to mean something different the filter you may want to clarify that here.

> > I agree this could provide additional value but am a bit concerned as
> others have suggested the document is too large:(
> >
>

This sounds like a good approach to me.

> > Again from an SP perspective this is current and correct most large
> router vendors today use the ASIC forwarder and RE/CPU architecture.
> > Many have added additional layers so it may be asic for most
> forwarding, then a shared NP for some other work, then a Routing
> Engine.
> >
>
> >> But I think that the general implications are the most important
> part
> >> of

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 May 2011 01:58:56 -0300

Hi, Carlos,

Please find my comments inline...

> http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html

The document does not assume that options are not filtering in the
current Internet, but rather argues what should/could/should not be done
with respect to IP options filtering.

-- I agree that it would be good to have some text and pointers about
the current state of affairs wrt ip options filtering. -- Will craft
some text and post it for review.

> when the capability to filter per-option might exist.

I disagree with this assessment. The document assesses the impact of
filtering different options. If you're fine with the impact of filtering
all ip-optioned packets, then you don't need to filter at the
granularity of per-option-type.

> packet did not have options), and that is a potential recommendation.

IIRC, this is already mentioned in the document.

[....]
> be discussed early on on the document.

I agree with this. If you can craft text for that, that'd be welcome.

> the doc can be a bit ambiguous. The options are not filtered, the whole

Agreed. This was also noted by another participant off-list, and will be
fixed in the next rev.

> be oversimplifying the current state.

Proposed change?

> this document but are minimal.

hence?

> packet with many options should be.

Will fix this.

> does not parse, I hope this is useful.

Indeed it is!

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1