Subject: Re: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jul 2013 10:26:54 -0400

On Jun 24, 2013, at 4:12 PM, Warren Kumari <[email-masked]> wrote:

> 
> On Jun 24, 2013, at 10:28 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
>> Thanks, Arturo, for this review! Much appreciated.
>> 
>> While we review these comments, one questions for the chairs...
>> 
>> There was a WGLC on this document started on Feb 18, 2013, and it appears it was never "formally closed".
> 
> Yup, you are right, it was not formally closed. We were attempting to win the record for the longest WGLC, but seeing as you asked, we have decided to abort this valiant effort :-P
> 
>> What is the status of that? I assume the WGLC ended on "04-Mar-2013" as per the WGLC message -- could you please summarize the outcome
> 
> The status was (and I apologize, this was not well communicated[0]) that we did not feel that we had gotten sufficient review.
> We asked for more volunteers, and Merike, Ron Bonica and Arturo stepped up (thanks!). 
> They have now completed their reviews (thanks again!)[1].
> 
>> and next steps (i.e., is the doc ready to be submitted to the IESG, after we submit a -03 incorporating comments?)
> 
> Assuming the comments are integrated (and that Merike didn't stumble across anything *too* scary) we think that the this should be ready for the IESG.
> 
> Apologies for the delay. 
> 
> W
> 
> [0]: IIRC we discussed this in the in person meeting, but then didn't really followup on-list correctly. 
> [1]: Merike has reviewed the document, but is currently sitting on a plane and so has not yet had a chance to send them in… 

Due to travel, etc Merike has been really busy, and the 4th of July is a large holiday in the USA and so we are going to wait till Monday for her review. 
If she doesn't get a chance to submit it by then, we'll call consensus without it… 

Honestly, we see strong consensus for advancing this, we just went to be able to say, in good faith, that sufficient folk have reviewed the document.

W
> 
>> 
>> Thanks,
>> 
>> -- Carlos.
>> 
>> On Jun 24, 2013, at 8:13 AM, Arturo Servin <[email-masked]> wrote:
>> 
>>> 
>>> I reviewed the document draft-ietf-opsec-ip-options-filtering-02. It is
>>> very well written and it explains very well the problems and threats of
>>> each IP option. The advices given through the document are clear,
>>> plausible and very logical to me.
>>> 
>>> I have a few minor comments:
>>> 
>>> Section 4.8.5
>>> 
>>> "Additionally,
>>> Routers, security gateways, and firewalls SHOULD have a configuration
>>> setting that indicates whether they should react react on the Router
>>> Alert option as indicated in the corresponding specification or
>>> ignore the option, or whether packets containing this option should
>>> be dropped (with the default configuration being to ignore the Router
>>> Alert option)."
>>> 
>>> This paragraph is a bit confusing. It is not clear to me if the two
>>> options are to drop the packet and do nothing (ignore the option). I
>>> would suggest rephrasing it. Also it has a typo (they should react react)
>>> 
>>> Section 4.12.2
>>> 
>>> I am not sure the goal of the paragraph about the Cisco routers. It
>>> looks to "Cisco centric" to me. I would just remove the whole paragraph
>>> as I do not see any value added by it.
>>> 
>>> The same is for section 4.13.2 ….
>>> 
>>> Section 4.12.5
>>> 
>>> I wonder that if this option is only used within very secure networks
>>> and it is not common or used in the Internet the advice is to forward
>>> it. I would assume that the advice should be to drop unless the network
>>> admin expects to see this option.
>>> 
>>> This same applies to section 4.13.5 and 4.14.5
>>> 
>>> Section 4.22.5
>>> 
>>> The advice mentions "drop and log event" as the default. I wonder that
>>> if logging a large amount of packets with these options would create a
>>> DoS on the control plane. Perhaps the default should be just drop or to
>>> add an advice that excessive logging could also be an attack vector.
>>> 
>>> Same for 4.23.4 about "Other IP options" and in general every time that
>>> the document recommends "drop and logging".
>>> 
>>> Best regards.
>>> /Arturo Servin
>>> 
>>> 
>>> _______________________________________________
>>> OPSEC mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/opsec
>> 
>> _______________________________________________
>> OPSEC mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/opsec
>> 
> 
> -- 
> With Feudalism, it's your Count that votes.
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 

--
"When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie."
-- Terry Pratchett

---

From: Merike Kaeo <[email-masked]>
Date: Sun, 07 Jul 2013 14:43:20 -0700

Inline...

On Sun 07/07/13  1:02 PM , "Carlos Pignataro (cpignata)" <[email-masked]> wrote:

> Merike,
> 
> Thanks for the review, please see inline.
> 
> On Jul 6, 2013, at 12:26 PM, Merike Kaeo  wrote:
> 
> > 
> > Overall it's a good document to explain what should be done with packets
> that use IP options.
> 
> Thanks.
> 
> > Some detailed comments follow.
> > 
> > 
> > Introduction
> > "We note that data seems to indicate that there is a current widespread
> practice of blocking IPv4 optioned packets"….. The reference [MEDINA] is
> from a 2004 publication, is there anything more recent? If not, at least
> don't state it's a 'current' study and just refer to it as a study. Since
> the tests in MEDINA encompassed "IP Record Route Option", "IP Timestamp
> Option" and "IP OptionX" I'm not sure it's accurate to say that data seems
> to indicate there's widespread practice unless there's other data to back
> it up. [perhaps if default in devices is to block specific options that's a
> factor to be considered]
> 
> The fact that nobody "invested" the time in writing another paper on the
> study of the practice of blocking IPv4 optioned packets is probably, more
> than anything else, an indication that the situation has not changed... not
> too much value in re-writing the same conclusions every few years. There
> are fairly common informal tests about it, that support the paper.

If it's commonly known, OK.  I wasn't aware.  
 
> If it helps I can also add a pointer to
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.html, [1] "IP
> Options are not an option", from Dec 2005, but again, informal tests show
> this has not changed.

Just want to make sure reader knows that informal tests exist :)  Else they just take something at face value
but I guess that's OK too as long as the documented is vetted and enough people know about the
informal tests and agree with them.

> See for example Dan Wing's
> http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html. [2] I
> also used Dan's scripts in a cron job testing top Alexa sites for some
> time, same result.
> 
> > 
> > The last two paragraphs give no definitive recommendation. Are you
> simply giving advice on dropping packets on a per IP options basis or is
> that the recommendation as a BCP? 
> 
> This is still the Introduction to the document.
> 
> > 
> > 4.3. LSRR option
> > In 4.3.1 it states that some ISPs peering agreements require support for
> LSRR option - I am a bit surprised at this since most routers since
> mid-90's have had source routing off by default. Was it just strict source
> routing that's off by default or did that apply to both LSRR and SSRR? 
> > 
> 
> I am not sure, but having "support" for an option is orthogonal to its
> default setting.

Agreed.  Was just wondering.
 
> > Ping and trace route do NOT always break which is not clear in section
> 4.3.4. If UDP/ICMP is used there is no problem right? Only with TCP and
> using IP options. Might explicitly want to state that for clarity to
> reader(s).
> > 
> 
> This is a good point and the text is not clear. I will fix this.
> 
> > I'd also explicitly state that most routers since late 1990's have had
> source routing off by default. [caveat - may differentiate between LSRR vs
> SSRR if not same]
> > 
> 
> Do you have citable source for this? I am not comfortable talking about
> "most" without some solid reference.

No, I'd have to hunt down the config guidelines.  I do remember cisco changing their defaults although
don't know off-hand the IOS rev.  And I am fairly certain Juniper also shipped with it not enabled.
The problem was publicized widely around 1999...here's a reference that describes it

http://www.rapid7.com/vulndb/lookup/generic-ip-source-routing-enabled

Maybe useful to say that "The security concerns with source routing have been known since 1999 and many recommendations
have since then existed to disable source routing".  But I'm not vetted to this.  Do what you think is best.

> 
> > 
> > 4.4 Most routers since late 1990's have had source routing off by
> default so may want to state that [same caveat as above relating to LSRR vs
> SSRR]
> > 
> > 4.12.2 If you are including vendor behavior, it would be useful to
> include at least 2 vendors' behavior ( For example Juniper or
> Alcatel-Lucent routers or some "Layer 3 switch" device). If no other router
> or layer 3 switch supports this option, state that.
> > 
> 
> Removed the Cisco references on 4.12.2 and 4.13.2 from a previous review.
> 
> > 4.13.2 Same comment as for 4.12.
> 
> Ditto.
> 
> > 
> > 6. Security Considerations
> > At least half of the IP options discussed seem to be deprecated and do
> not appear to have any operational impact if dropped. So rather than state
> that "dropping packets containing IP options can cause real operational
> problems in deployed networks" I'd restate to something like "Many of the
> IP options listed in this document are deprecated and cause no operational
> impact if dropped. However, dropping packets containing IP options that are
> in use can cause real operational problems in deployed networks."
> > 
> > And leave the last sentence as is.
> > 
> 
> OK, I'll rework this piece a bit.
> 
> > 
> > For all the IP options that have been formerly deprecated in RFC 6814,
> why are they listed as SHOULD be dropped and not MUST? Especially if the
> operational and interoperability impact if blocked is None?!?
> > 
> > 
> 
> I am very judicious with MUST statements and shy away a bit unless there
> is harm. But certainly we can MUST this one if it is the WG's view.

But that's the point isn't it, that these particular IP options DO cause harm and are NOT needed?  At 
least the ones that are listed as SHOULD drop?  From my read in the document all of those are
specifically listed as having NONE as operational and interoperability impact.

I defer to working group consensus here.  

> 
> > That about covers it from my review.
> > 
> 
> Thanks again.

Happy to review.  Will read your updated doc next but wanted to at least comment to this email.  You are expedient in your updates :)

- merike

> Carlos.
> > - merike
> > https://www.ietf.org/mailman/listinfo/opsec [3]
> 
> 
> 
> Links:
> ------
> [1]
> http://webmail.sonic.net/parse.php?redirect=http://www.eecs.berkeley.edu/Pu
> bs/TechRpts/2005/EECS-2005-24.html%2C[2]
> http://webmail.sonic.net/parse.php?redirect=http://www.ietf.org/mail-archiv
> e/web/int-area/current/msg02360.html.[3]
> http://webmail.sonic.net/parse.php?redirect=https://www.ietf.org/mailman/li
> stinfo/opsec
>