Subject: [OPSEC] ietf-opsec-icmp-filtering (Was: New Version Notification fordraft-gont-opsec-ip-options-filtering-01)

From: Carlos Pignataro <[email-masked]>
Date: Sat, 10 Mar 2012 12:45:06 -0500

Donald,

Apologies for a late response. To set the context of this email (ICMP filtering and not IP Options) I updated the Subject line.

Please see inline.

On Feb 20, 2012, at 7:13 PM, Smith, Donald wrote:

> I have read this in the past but it has changed enough to require that I read it again a few times:) I like the concept and agree with most of what you have.
> 
Great -- and thanks again for the thorough review and comments!
> 
> Legend is incomplete, Deny, Permit, Send and N/A are undefined. I realize they are sort of self explanatory but it may help to define them. For example deny do you mean silent drop or reset or send icmp errors or ...?
> 
Ack.
> Deprecated options may still be in use so we may want to think about if we want to add an "action" to that. Is it apparent that the filtering is for routers only or routers and hosts or routers and hosts and firewalls?
> Firewalls tend to block a lot more then routers. They also incorrect use icmp errors to block certain types of packets/protocols etc... For example iptables sends port unreachable error msgs for all reject's. That can be modified but that is the default.
> 
> 
I think you clarified this comment in a subsequent email.
> Also the concept at edge of net, internal net etc... seem to be important but not covered by the table which may be ok just pointing that out. So while we might filter some packets out at the edge of the network we may allow them internally. For example I wouldn't want a icmp redirect to come from outside my network but may allow it internally same for TOS/df bits. I wouldn't want someone controlling which queue they get into on my routers but may want to use TOS within my network.
> 
> 
Do you think that this comment should be incorporated in a specific section? do you have some specific text in mind?
> 
> I am not sure I agree with all your recommendations in the table but that is going to require I read it a few times before making any suggestions.
> 
> Threats could probably be defined somewhere in full then use a similar abbreviation as you have done in the table to refer to them.
> Something like "redirect = Can be used to redirect all or some traffic to a site to compromise availability, integrity and confidentiality"
> DOS = Resource Exhaustion = Can be used to exhaust bandwidth, cpu, io or other scarce resources by consuming too much of a resource either by causing the device to generate a lot of msgs or by sending directly towards device.
> 
> Operational and interop impact could be done the same way since those are mostly the same or come from a small set of impacts.
> 
> 
I see, but the threats are not included in the table, only the recommendations. Do you still feel like having specific definition for each threat would help, if we do not cite them from a common place, instead of having more flexibility with the text at each section?
> You state in at least one spot that many stacks ignore an type/code pair but some other type/codes commonly ignored don't have that statement.
> 
> 
That would be a gap to fix. Which specific type/codes are currently commonly ignored but it is not mentioned in the corresponding section?

Thanks again!

-- Carlos.
> 
> (coffee != sleep) & (!coffee == sleep)
>  [email-masked]<mailto:[email-masked]>
> ________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Fernando Gont [[email-masked]]
> Sent: Monday, January 23, 2012 1:27 PM
> To: Carlos Pignataro
> Cc: [email-masked]'
> Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01
> 
> Hi, Carlos,
> 
> Is there anything that still need to be addressed in the document?
> (modulo nits and the quick fixes you highlighted in your last e-mail)?
> 
> Thanks,
> Fernando
> 
> 
> 
> 
> On 01/23/2012 03:12 PM, Carlos Pignataro wrote:
> 
> > On 12/16/2011 9:38 PM, Fernando Gont wrote:
> >> 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?
> >>
> >
> > This is the standard output of `wc` (word count), where the columns are
> > number of lines, words, and characters, respectively. Only the first
> > column is meaningful here (wc -l), and the important piece was that you
> > get only a 3.29% success when using known options.
> >
> > Without any IP options:
> > # grep open normal-nop.out | wc
> >      486    2430   29901
> >      ^^^
> > with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00
> > # grep open ip-options-nop.out | wc
> >       16      80    1099
> >       ^^
> > And 16 is a 3.29% of 486.
> >
> > [BTW: the script is at <http://www.employees.org/~dwing/ipoptions/>]
> >
> >>
> >>
> >>> 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.
> >>
> >
> > Ack -- Thanks!
> >
> >>
> >>>>> 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 ---
> >>
> >
> > Thanks.
> >
> >>
> >>>> 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?
> >>
> >
> > I think so, I will re-read it too.
> >
> >>
> >>>>> 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 ---
> >>
> >
> > Thanks -- note a typo, s/processs/process/;
> >
> >>
> >>>>> 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.
> >                                                           ^"a"
> >> Unless special care is taken, this represents Denial of Service (DoS)
> >                                                ^ "a potential"
> >> risk, as there is potential for overwhelming the router with option
> >       ^^^^^^^^^^^^^^^^^^^^^^^
> >       I'd remove this and add "if protective measures are not taken".
> >> processing."
> >> ?
> >>
> >
> > Looks good, modulo quick comments.
> >
> >>
> >>>>> 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?
> >>
> >
> > The text says "general security implications of IP options discussed in
> > Section 2", but there are no security implications discussed in S2.
> >
> >>
> >>
> >>> 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,
> >
> > Sounds good.
> >
> > Thanks,
> >
> > -- Carlos.
> >
> 
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 
> ________________________________
> This communication is the property of CenturyLink 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: Fernando Gont <[email-masked]>
Date: Sun, 11 Mar 2012 08:33:55 -0300

Hi, Panos,

Thanks so much for your feedback! Please find my comments inline....

On 02/21/2012 02:00 AM, Panos Kampanakis wrote:
> Hi Fernando,
> 
> Comments:
> - In 4.3.4, 4.4.4 and 4.5.4 it is not clear to me what you mean by
> "Nevertheless, it should be
>    noted that it is virtually impossible to use such techniques due to
>    widespread filtering of the LSRR/SSSR/... option."

It means that in practice you cannot do troubleshooting with LSRR/SSSR,
because they are largeley filtered (i.e., packets containing such
options are dropped).

-- I've tweaked the text a bit, to make it more clear.

> - In 4.14.5 it states "Because of the design of this option, with variable
> syntax and
>    variable length, it is not practical to support specialized filtering
>    using the CIPSO information.". If we can block based on type 130 or 131,
> it is not clear why blocking type 134 is not possible.

By filtering we mean "inspecting the contents of the option", rather
than "blocking/dropping". -- I understand that the current version of
the I-D uses "filtering" in ambiguous ways -- this will be fixed in the
next rev.

> - "4.18.  Other IP Options" says that the unknown options should be ignored.
> Routing devices and hosts should ignore options that they don't understand.
> but I believe when we are discussing filtering options, unknown options
> should be dropped for the sake of security and to prevent exploitations of
> flaws we are not yet aware of.

The issue here is that such filtering would prevent deployment of future
options.

One might argue that routers should ignore them, while firewalls should
drop them. (since from the firewall's perspective, the idea usually is
"anything that is not explicitly allowed should be blocked").

I'd like others to weigh in...

> 
> Suggestions:
> - In section "2.  IP Options" it seems going over the ip iption header would
> be better exlained with an ascii diagram 
> 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
>       |  Option Type  |  Opt Data Len |  Option Data
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Done.

> - In "3.1.  Processing Requirements" it seems you are referring to router
> architectures which could mean any L3 device. But later in the paragraph
> only routers are mentioned. Maybe it would make more sense to refer to them
> as network devices, as it could be other L3 devices that are performing the
> routing function

Not sure what you mean... "network devices" sounds a bit ambiguous...

> - In "4.12.5 Advice" and 4.13.5 it is stated "Routers and firewalls..."
> where in other .5 sections the advice was expressed in a different format
> "Filter...". A minor inconsistency there.

This will be fixed throughout the whole document. Thanks!

> Nit:
> - Paragraph "This is the IPv4-version of the IPv6 amplification attack that
> was
>       widely publicized in 2007 [Biondi2007].  The only difference is
>       that the maximum length of the IPv4 header (and hence the LSRR
>       option) limits the amplification factor when compared to the IPv6
>       counter-part." 
>   seems to be incorrectly indented.

It is meant to be a parenthetical note -- hence the indentation.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 12 Mar 2012 10:46:55 -0600

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 Fernando Gont
> Sent: Sunday, March 11, 2012 5:34 AM
> To: Panos Kampanakis
> Cc: Carlos Pignataro (cpignata); [email-masked]
> Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-
> ip-options-filtering-01
>
> Hi, Panos,
>

Most ISPs don't drop such packets but they do ignore them. The default on cisco is to ignore and has been for a long while.

Most Firewalls do drop such packets so from an enterprise POV dropping is probably the default while from an ISP pov ignoring is probably the default.

> > - In 4.14.5 it states "Because of the design of this option, with
> > variable syntax and
> >    using the CIPSO information.". If we can block based on type 130
> or
> > 131, it is not clear why blocking type 134 is not possible.
>
> > but I believe when we are discussing filtering options, unknown
> > options should be dropped for the sake of security and to prevent
> > exploitations of flaws we are not yet aware of.
>
> The issue here is that such filtering would prevent deployment of
> future options.
>
> > - In section "2.  IP Options" it seems going over the ip iption
> header
> > would be better exlained with an ascii diagram
> >
> > - In "3.1.  Processing Requirements" it seems you are referring to
> > router architectures which could mean any L3 device. But later in the
> > paragraph only routers are mentioned. Maybe it would make more sense
> > to refer to them as network devices, as it could be other L3 devices
> > that are performing the routing function
>
> > where in other .5 sections the advice was expressed in a different
> > format "Filter...". A minor inconsistency there.
>
> > - Paragraph "This is the IPv4-version of the IPv6 amplification
> attack
> > that was

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 12 Mar 2012 11:04:44 -0600

I made several very similar comments back on 2/20 which I never saw a response to. For example I suggested Depr be removed/moved....

Here is the text of the original email from 2/20/12

> Of Smith, Donald
> Sent: Monday, March 12, 2012 10:47 AM
> To: 'Fernando Gont'; 'Panos Kampanakis'
> Cc: 'Carlos Pignataro (cpignata)'; [email-masked]'
> When packets collide the controllers cease transmission AND wait a
> random time before retransmission (mostly)!
> > It means that in practice you cannot do troubleshooting with
> > LSRR/SSSR, because they are largeley filtered (i.e., packets
> > containing such options are dropped).
>
> Most ISPs don't drop such packets but they do ignore them. The default
> on cisco is to ignore and has been for a long while.
>
> Most Firewalls do drop such packets so from an enterprise POV dropping
> is probably the default while from an ISP pov ignoring is probably the
> default.
>
>
> >
> > the I-D uses "filtering" in ambiguous ways -- this will be fixed in
> > the next rev.
> >
> >
> > One might argue that routers should ignore them, while firewalls
> > should drop them. (since from the firewall's perspective, the idea
> > usually is "anything that is not explicitly allowed should be
> blocked").
> >
> > > router architectures which could mean any L3 device. But later in
> > > the paragraph only routers are mentioned. Maybe it would make more
> > > sense to refer to them as network devices, as it could be other L3
> > > devices that are performing the routing function
> >
> This communication is the property of CenturyLink 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.