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

From: Merike Kaeo <[email-masked]>
Date: Sat, 06 Jul 2013 09:26:42 -0700

Overall it's a good document to explain what should be done with packets that use IP options.  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 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? 

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? 

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).

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]

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.

4.13.2 Same comment as for 4.12.

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.

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?!?

That about covers it from my review.

- merike

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 7 Jul 2013 20:02:30 +0000

Merike,

Thanks for the review, please see inline.

On Jul 6, 2013, at 12:26 PM, Merike Kaeo <[email-masked]> 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

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 helps I can also add a pointer to http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.html, "IP Options are not an option", from Dec 2005, but again, informal tests show this has not changed.

See for example Dan Wing's http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html. 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.

> 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…

I am not sure, but having "support" for an option is orthogonal to its default setting.

> 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 th…

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.

> 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 oth…

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.

> 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 i…

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.

> That about covers it from my review.

Thanks again.

Carlos.

> - merike
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec