Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Jun 2012 11:57:45 -0700

On May 31, 2012, at 12:04 PM, Dave Dugal wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Warren.
> 
> I have also read Fernando's draft and do see the value and benefit of
> proposing a more granular approach to IP options filtering.  Many
> times, the only mitigation for a particular attack or issue is to drop
> all optioned packets, which depending on configuration and topology
> can do more harm than good.  BCP'ing a more finely granular approach
> is not without merit.
> 
> Should we adopt this draft, I do agree with previous comments that
> perhaps more fine-tuning of recommended options, tradeoffs and caveats
> is warranted, but that discussion can continue within the WG.
> 
> I support the adoption of this draft as an OPSEC working group document.

Great, thank you..

Anyone else? We only have another 2 or so days before the adoption call closes, and I'd really like to see some more feedback, even a simple "Support" or "No, worst idea ever!!!"

W

> 
> - ---
> Dave Dugal
> Sr. Product Security Incident Wrangler
> 
> 
> On 5/31/2012 9:42 AM, Warren Kumari <[email-masked]> proclaimed ...
>> Dear Working Group,
>> 
>> We are now halfway through the call for adoption on this draft --
>> please take a moment to read and comment on if you support the
>> adoption of this draft…
>> 
>> W On May 24, 2012, at 11:58 AM, Warren Kumari wrote:
>> 
>>> Dear Working Group,
>>> 
>>> This is to start a two week poll to adopt 
>>> draft-gont-opsec-ip-options-filtering ( helpful link:
>>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04)
>>> 
>>> 
> as an OpSec Working Group draft.
>>> 
>>> Please send your comments to the OpSec list ([email-masked]).
>>> 
>>> This adoption call closes on June 7th, 2012.
>>> 
>>> (This document was discussed in the Paris meeting, and not enough
>>> people had read the document to be able to predict consensus.
>>> Please take a moment (or 5) to read and comment. I should mention
>>> that Memorial Day is coming up in the US soon -- there is nothing
>>> quite so enjoyable as reading drafts on the beach -- try it!)
>>> 
>>> W
>>> 
>>> -- With Feudalism, it's your Count that votes.
>>> 
>>> 
>>> _______________________________________________ OPSEC mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/opsec
>>> 
>> 
>> _______________________________________________ OPSEC mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/opsec
>> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (MingW32)
> 
> iEYEARECAAYFAk/HwMIACgkQh59lzatuAqXiuwCgtXDacC7wSx0gtdfC41JRXcJN
> 03MAoPf9m5FVlWOrHlOJzsPrRI117UqR
> =lEqG
> -----END PGP SIGNATURE-----
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 5 Jun 2012 15:23:54 -0600

This isn't quite correct.
4.3.4. Operational and Interoperability Impact if Blocked

Network troubleshooting techniques that may employ the LSRR option
(such as ping or traceroute) would break. Nevertheless, it should be
noted that it is virtually impossible to use the LSRR option for
troubleshooting, due to widespread dropping of packets that contain
such option.
4.3.5. Advice
Routers, security gateways, and firewalls SHOULD, by default, drop IP
packets that contain an LSRR option.
Most routers don't drop LSRR or SSRR they ignore them. no ip source-route drops that ip option towards the router itself it shouldn't afaik drop the packets themselves.
Now given that that is the default config for them and most other router vendors I believe your correct in saying you can pretty safely drop these packets.
This also is incorrect as I understand it.
4.5.4. Operational and Interoperability Impact if Blocked
Network troubleshooting techniques that may employ the RR option
(such as ping with the RR option) would break. Nevertheless, it
should be noted that it is virtually impossible to use such
techniques due to widespread dropping of packets that contain RR
options.
4.5.5. Advice
Routers, security gateways, and firewalls SHOULD drop IP packets
containing a Record Route option.
While RR can be dropped it requires a 12.++ image to do options acls on a cisco so that is "fairly" recent 8 years or so ago:)
I don't know of many ISPs that drop RR.
Feel free to correct me if someone knows of this being a common practice.
This isn't the operational impact statement it is a security statement.
4.7.4. Operational and Interoperability Impact if Blocked

No security issues are known for this option, other than the general
security implications of IP options discussed in Section 3.
This:
4.10.1. Uses

This option and originally provided a mechanism to discover the Path-
MTU. It is now obsolete.
Should be this
4.10.1. Uses

This option originally provided a mechanism to discover the Path-
MTU. It is now obsolete.
4.18.4. Operational and Interoperability Impact if Blocked
None.
Rather then None as is used throughout the document how about "no known impact" or something along those lines?
4.23 doesn't include any specific adivse it does however point to other rfcs with language on ignoring unknown options.
I think we should make it a SHOULD drop but am open to discussion this further.
Lastly the "generic section 3" threat should probably be standardized you have a couple of slightly different versions.

4.17.3.  Threats
   There are no know threats arising from this option, other than the
   general security implications of IP options discussed in Section 3.
4.10.3.  Threats
   No security issues are known for this option, other than the general
   security implications of IP options discussed in Section 3.

Also support addoption once this issues can be worked out.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Warren Kumari [[email-masked]]
Sent: Tuesday, June 05, 2012 12:57 PM
To: Dave Dugal
Cc: [email-masked]; Warren Kumari
Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering

Great, thank you..

W

________________________________
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: "Panos Kampanakis" <[email-masked]>
Date: Tue, 5 Jun 2012 17:35:01 -0400

I also support the adoption of this as WG item.

Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Warren Kumari
Sent: Tuesday, June 05, 2012 2:58 PM
To: Dave Dugal
Cc: [email-masked]; Warren Kumari
Subject: Re: [OPSEC] Call for adoption
ofdraft-gont-opsec-ip-options-filtering

Great, thank you..

Anyone else? We only have another 2 or so days before the adoption call
closes, and I'd really like to see some more feedback, even a simple
"Support" or "No, worst idea ever!!!"

W

>> adoption of this draft.

--
What our ancestors would really be thinking, if they were alive today, is:
"Why is it so dark in here?"

---

From: Fernando Gont <[email-masked]>
Date: Tue, 05 Jun 2012 21:43:02 -0300

Hi, Donald,

On 06/05/2012 06:23 PM, Smith, Donald wrote:
> This isn't quite correct. 4.3.4. Operational and Interoperability
> Impact if Blocked
> 
> Network troubleshooting techniques that may employ the LSRRoption 
> (such as ping or traceroute) would break. Nevertheless, it should
> be noted that it is virtually impossible to use the LSRRoption for 
> troubleshooting, due to widespread dropping of packets that
> contain such option. 4.3.5. Advice Routers, security gateways, and
> firewalls SHOULD, by default, drop IP packets that contain an
> LSRRoption. Most routers don't drop LSRRor SSRRthey ignore them. no
> ipsource-route drops that ipoption towards the router itself it
> shouldn't afaikdrop the packets themselves. Now given that that is
> the default configfor them and most other router vendors I believe
> your correct in saying you can pretty safely drop these packets.

Just double-checking: Is your argument that the advice is okay, but
just that  we should note that routers typically ignore this option
rather than drop them.

THat aside: Can anyone check the defaults for Ciscos and Junipers?

> This also is incorrect as I understand it. 4.5.4. Operational and
> Interoperability Impact if Blocked Network troubleshooting
> techniques that may employ the RR option (such as ping with the RR
> option) would break. Nevertheless, it should be noted that it is
> virtually impossible to use such techniques due to widespread
> dropping of packets that contain RR options. 4.5.5. Advice Routers,
> security gateways, and firewalls SHOULD drop IP packets containing
> a Record Route option. While RR can be dropped it requires a 12.++
> image to do options aclson a ciscoso that is "fairly" recent 8
> years or so ago:) I don't know of many ISPs that drop RR. Feel free
> to correct me if someone knows of this being a common practice.

As with the other one, can folks provide input on this one?

> This isn't the operational impact statement it is a security
> statement. 4.7.4. Operational and Interoperability Impact if
> Blocked
> 
> No security issues are known for this option, other than the

Will fix this one.

> This: 4.10.1. Uses
> 
> This option and originally provided a mechanism to discover the
> Path- MTU. It is now obsolete. Should be this 4.10.1. Uses
> 
> MTU. It is now obsolete. 4.18.4. Operational and Interoperability
> Impact if Blocked None. Rather then None as is used throughout the
> document how about "no known impact" or something along those
> lines?

Have we ever relied upon this option for Path-MTU discovery? Has this
option ever been widely deployed? -- My take is that the answer to
these two is "No".

> 4.23 doesn't include any specific adivseit does however point to 
> other rfcswith language on ignoring unknown options. I think we
> should make it a SHOULD drop but am open to discussion this 
> further.

According to discussions with the other co-authors for, and
considering that this document provides advices for routers (rather
than firewalls), folks would like to ignore (rather than drop) packets
containing unknown options.

What do you folks think?

> Lastly the "generic section 3" threat should probably be
> standardized you have a couple of slightly different versions.
> 
> 4.17.3.  Threats There are no know threats arising from this
> option, other than the general security implications of IP options
> discussed in Section 3. 4.10.3.  Threats No security issues are
> known for this option, other than the general security implications
> of IP options discussed in Section 3.

Will do.

> Also support addoption once this issues can be worked out.

Great. Thanks!

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

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 5 Jun 2012 22:55:24 -0400

On JUNOS, the behavior is configurable with the default being to ignore. See

- http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/source-routing-edit-routing-options.html

                                Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fernando Gont
> Sent: Tuesday, June 05, 2012 8:43 PM
> To: Smith, Donald
> > noted that it is virtually impossible to use the LSRRoption for
> > such option. 4.3.5. Advice Routers, security gateways, and firewalls
> > SHOULD, by default, drop IP packets that contain an LSRRoption. Most
> > routers don't drop LSRRor SSRRthey ignore them. no ipsource-route
> > drops that ipoption towards the router itself it shouldn't afaikdrop
> > the packets themselves. Now given that that is the default configfor
> > them and most other router vendors I believe your correct in saying
> > you can pretty safely drop these packets.
> 
> > Interoperability Impact if Blocked Network troubleshooting techniques
> > that may employ the RR option (such as ping with the RR
> dropping
> > of packets that contain RR options. 4.5.5. Advice Routers, security
> > gateways, and firewalls SHOULD drop IP packets containing a Record
> > Route option. While RR can be dropped it requires a 12.++ image to do
> > options aclson a ciscoso that is "fairly" recent 8 years or so ago:)
> I
> > don't know of many ISPs that drop RR. Feel free to correct me if
> > someone knows of this being a common practice.
> 
> > statement. 4.7.4. Operational and Interoperability Impact if Blocked
> >
> MTU.
> > It is now obsolete. 4.18.4. Operational and Interoperability Impact
> if
> > Blocked None. Rather then None as is used throughout the document how
> > about "no known impact" or something along those lines?
> 
> other
> > rfcswith language on ignoring unknown options. I think we should make
> > it a SHOULD drop but am open to discussion this further.
> 
> According to discussions with the other co-authors for, and considering
> that this document provides advices for routers (rather than
> firewalls), folks would like to ignore (rather than drop) packets
> > Lastly the "generic section 3" threat should probably be standardized
> > you have a couple of slightly different versions.
> >
> > 4.17.3.  Threats There are no know threats arising from this option,
> > other than the general security implications of IP options discussed
> > in Section 3. 4.10.3.  Threats No security issues are known for this
> > discussed in Section 3.
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
>

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 6 Jun 2012 12:24:28 -0600

When packets collide the controllers cease transmission AND wait a random time before retransmission (mostly)!
[email-masked]

> From: Fernando Gont [mailto:[email-masked]] On
> Behalf Of Fernando Gont
> Sent: Tuesday, June 05, 2012 6:43 PM
> To: Smith, Donald
> Cc: Warren Kumari; Dave Dugal; [email-masked]
Correct. Ignore vs drop your recommendation can stand.

> > Impact if Blocked None.
My real point on this one was the use of none vs no known impact.

> > Rather then None as is used throughout the
> > 4.23 doesn't include any specific advise does however point to
> > other rfcs with language on ignoring unknown options. I think we
That would be the default for MOST ISPs. The general rule of thumb is we forward traffic period. Dropping anything even something that we don't expect to see THROUGH the routers is not advisable. To the router on the other hand (thus ignore) is advisable.

---

From: John Kristoff <[email-masked]>
Date: Wed, 6 Jun 2012 18:07:31 -0500

On Thu, 24 May 2012 11:58:58 -0400

> Please send your comments to the OpSec list ([email-masked]).

Sorry for the slight delay, I started reviewing the document about a
week ago, but didn't get around to finishing until now.  I think it a
document worth adopting.

> people had read the document to be able to predict consensus. Please
> take a moment (or 5) to read and comment. I should mention that
> Memorial Day is coming up in the US soon -- there is nothing quite so
> enjoyable as reading drafts on the beach -- try it!)

My comments on the document below.

In the Abstract the second word "document" is repeated.

Structurally having a single subsection is awkward.  I'd suggest Putting
1.1 into it's own section number 2 and adjust the document accordingly.

Likewise, remove the subsection 3.1 and just put what is now 3.1's
text directly under 3.0.

Throughout the draft Service Provider is capitalized.  I don't see why
it should be.

In section 1 and elsewhere the past tense use of "optioned" and
"un-optioned" is awkward.  I'd suggest something like "datagrams with
options" or "without options" instead.

In section 1, I believe "tends to support" should instead be "tend to
support".

Also in section 1, the sentence starting with "Some results of
regarding" is worded awkwardly.  I'd suggest starting with it "Some
results on" instead.

In section 2, the first sentence should be terminated with a period
and the following sentence can immediately follow it.

Section 3.1 starts by saying "Router architectures can perform", but I
think what is ultimately meant is "Router architectures often perform".

A question for the group that may lead to another subsection under
section 3, addressing one of the issues mentioned above... does the
processing of datagrams with options potentially alter the order of
packets?  That is, if a datagram with options hits the slow path, may
datagrams that arrived immediately after be forwarded first while the
packet with options is being worked on? If so,this potential out of
order delivery may be worth identifying as a general security
implication.

Why is the advice in 4.1.5 SHOULD NOT instead of MUST NOT?

In section 4.3.1 the statement "in the routers within the peer of the
ISP" is awkward.  I'd suggest changing it to "between routers that are
used in ISP peering relationships".

Section 4.3.3 claims "The LSRR option has well-known security
implications", but provides no supporting references and should.  You
can reference your own document, IETF RFC 6274.

In section 4.3.3. the statement "the one that has probably received
least attention" is probably better written as "one that has received
little attention".

Additionally, in section 4.3.3 there is specific mention of
Microsoft1999 and OpenBSD1998.  Why make an issue of those
implementations here?  To be consistent wouldn't you have to mention
lots of other implementation issues with the handling of other
options.  In other words, you seem to point out some very specific
issues that have been experienced with this option, but not others.

In my experience I've seen a number of peering requirements for LSSR,
but I can't recall them ever being enforced.  While I suspect it
gets very little use these days, contrary to the statement in 4.3.4
there is some evidence that that the LSRR option is still used for
ISP-to-ISP connectivity troubleshooting:

  http://psg.com/peering.html
  http://www.gweep.net/~crimson/network/lsrr.html
  http://palvelut.aina.net/peering/index.html

Outside even this limited usage, perhaps path asymmetry is common enough
to render this and the following option obsolete anyway?  If so, that
would be an argument that could be added to sections 4.3.4 and 4.4.4.

In section 4.4.1 the statement "within the peer of the ISP" is probably
probably stated as "between ISPs".

The last sentence in section 4.8.5 is long, awkward and contains at
least one small grammatical error. Perhaps change to this:

  Additionally, routers, security gateways and firewalls SHOULD have a
  configuration setting that indicates what action to take when
  encountering the Router Alert option.  The configuration option
  could be a choice of whether to react on the Router Alert
  option as indicated in the corresponding specification, ignore the
  option or drop the packet.  The default configuration setting SHOULD
  be to ignore the Router Alert option.

In section 4.10.1, the first sentence should probably start with "This
option originally".

The statement in Section 4.12.1 that reads "This option probably has
more deployment now than when the IESG describes a similar option"
should be supported with a reference to justify the claim if possible.

To be consistent, shouldn't the first sentence in 4.12.3 be as it is in
4.11.3 and others?

In section 4.12.5 it is recommended that the option be logged on a
per-interface basis.  Why is this recommended only for this option?

Presumably 4.20.3 was not forgotten and will at least get the
standard statement used in other Threats subsections.

At the heart of most of this document is that datagrams with options
have a tendency to melt routers since they have to do extra, hard to
optimize for work.  There are very few options in this document that
document recommends not dropping.  This could be viewed as a way to
avoid going around and obsoleting all those options individually or as a
shortcut to practically obsoleting options entirely.

It might be argued that recommending dropping all these datagrams may
pose more problems than simply ignoring them, especially by anything
but the destination.  That is, dropping may incur a processing penalty.
For example, there is some cost when advocating for logging or if the
system would generate an an ICMP destination unreachable message.  I'm
inclined to suggest that some nuance may be better here. For example,
perhaps recommend changing "SHOULD drop packets" to "MAY drop packets"
and "SHOULD ignore packets" for routing nodes. Perhaps destinations
would get the same recommendation, but that might not necessarily need
to be the case.

There does not seem to be any consideration for the general case of
excessive repetition of options, anomalous repeated options or
malformed options. Perhaps these should be discussed at length also?

It should be noted that this document would update IETF RFCs 791, 1122
and 1812.

John

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Jun 2012 04:26:50 -0300

On 06/06/2012 03:24 PM, Smith, Donald wrote:
>>> This option originally provided a mechanism to discover the
>>> Path- MTU. It is now obsolete. 4.18.4. Operational and
>>> Interoperability Impact if Blocked None.

Ok, I will "standardize" the wording. such that all these options have
the same text.

Thanks!

Best regards,

---

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Jun 2012 14:49:25 -0400

On May 24, 2012, at 11:58 AM, Warren Kumari wrote:

>   draft-gont-opsec-ip-options-filtering ( helpful link: http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04)

Apologies, I was on a plane on the 7th and didn't get a chance to send the "This is now closed!" mail…. Anyway, this is now closed :-p

While I would have liked to see more comments, there was enough to adopt, so:

The author is requested to resubmit the document as draft-ietf-opsec-ip-options-filtering-00.

Thank you to everyone who provided comments and feedback…

W

> 
> (This document was discussed in the Paris meeting, and not enough people had read the document to be able to predict consensus. Please take a moment (or 5) to read and comment. I should mention that Memorial Day is coming up in the US soon -- there is nothing quite so enjoyable as reading drafts on the beach -- try it!)
> 
> W
> 
> -- 
> With Feudalism, it's your Count that votes.
> 
> 

-- 
With Feudalism, it's your Count that votes.