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

From: Fernando Gont <[email-masked]>
Date: Fri, 16 Dec 2011 23:38:37 -0300

Hi, Carlos,

My apologies for the delay in my response. Please find my comments inline...

On 06/15/2011 01:01 PM, Carlos Pignataro wrote:
> In a way, the comment behind my comment was that if today optioned
> packets are already mostly blocked/filtered out, the value of a
> per-option analysis decreases.
> 
> Dan Wing was kind enough to run his experiment with existing options (as
> opposed to unknown options), with these results:
> 
> Without any IP options:
> # grep open normal-nop.out | wc
>      486    2430   29901

Sorry, what does each of the columns stand for?

> I am not aware of papers with more scientific analysis of success rates
> with existing options. But:
> 
> --->8---
> 	Data seems to indicate that there is a current widespread
> 	practice of blocking IPv4 optioned packets. There are various
> 	plausible approaches to minimize the potential negative effects
> 	of IPv4 optioned packets while allowing some options semantics.
> 	One approach is to allow for specific options that are expected
> 	or needed, and a default deny. A different approach is to deny
> 	unneeded options and a default allow. Yet a third option is to
> 	allow for end-to-end semantics by ignoring options and treating
> 	packets as unoptioned while in transit. The current state tends
> 	to support the first or third approaches as more realistic.
> --->8---

I've added this (verbatim) to the intro, and have also added a pointer
to Medina's paper.

>>> 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.
> 
> I think this point should also be clarified.

Done in the intro (right bellow the text you suggested above):

--- cut here ---
We also note that while this document provides advice on a "per IP
option type", not all devices may provide functionality to filter IP
packets on a "per IP option type". Additionally, even in cases in which
such functionality is provided, the operator might want to specify a
filtering policy with a coarser granularity (rather than on a "per IP
option type" granularity), as indicated above.
---- cut here ---

>> 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.
> 
> I guess what I was thinking is that an operator could think "what do I
> lose if I block this option" and do that exercise for every option, or
> "what do I gain by allowing", and this is where the (apparent) current
> practice has a role in deciding this.

I think this is addressed by the text that you've provided?

>>> 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.
>>
>> IIRC, this is already mentioned in the document.
>>
> 
> I could not find it. Could you please point to the specific para?
> 
> I think this is quite important because I think this is another practice
> often seen as the best option.

You were right -- it wasn't there. I have added this to the intro:

---- cut here ----
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 processs the corresponding packets as if they do not
contain any IP options.
--- cut here ---

>>> 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.
>>
>> Proposed change?
> 
> http://tools.ietf.org/html/rfc6192#section-1
> 
>    Modern router architecture design maintains a strict separation of
>    forwarding and router control plane hardware and software.  The
> 
> There are possible things like ICMP generation and IP option processing
> on general use processors in Line Cards, as opposed to LC forwarding
> ASICs. It is a punt to a slower path. But not necessarily a punt to the
> RP -- there may not be "main processor" but "main processors" depending
> on the context, and abstracting from actual architectures helps the
> document be more time invariant.

How about changing the text to:
"Router manufacturers tend to do IP option processing in slower path.
Unless special care is taken, this represents Denial of Service (DoS)
risk, as there is potential for overwhelming the router with option
processing."
?

>>> 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.
>>
>> hence?
> 
> Well, Section 2 is the default gateway for general implications
> applicable to all options but IMHO inadequately covers that subject. To
> be more precise, it does not cover it.

Can you specify what (exactly) you're referring to, so that I can
improve the document in this respect?

> Section 2 does not have general security implications of IP options. It
> seems to contain a guide as to what options are (semantics and syntax)
> but not security implications.

I've changed the ref to the one about the processing requirements.
Things can be improved from there.

P.S.: I've submitted a rev of the document, since it had expired. It is
available at:
<http://www.ietf.org/id/draft-gont-opsec-ip-options-filtering-02.txt>.
Please take a look and see if any of the issues raised in this e-mail
still needs to be addressed. (It still need to work on other feedback
you provided in other e-mails).

Thanks!

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