Re: Last Call: <draft-ietf-opsec-ip-options-filtering-05.txt> (Recommendations on filtering of IPv4 packets containing IPv4 options) to Best Current Practice

"C. M. Heard" <heard@pobox.com> Sat, 21 September 2013 23:24 UTC

Return-Path: <heard@pobox.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69F21F8EEA for <ietf@ietfa.amsl.com>; Sat, 21 Sep 2013 16:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a17Uj1muhSvS for <ietf@ietfa.amsl.com>; Sat, 21 Sep 2013 16:24:01 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EDB21F99CE for <ietf@ietf.org>; Sat, 21 Sep 2013 16:24:00 -0700 (PDT)
Received: (qmail 301 invoked from network); 21 Sep 2013 16:23:54 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Sep 2013 16:23:54 -0700
Date: Sat, 21 Sep 2013 16:23:54 -0700
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: IETF <ietf@ietf.org>
Subject: Re: Last Call: <draft-ietf-opsec-ip-options-filtering-05.txt> (Recommendations on filtering of IPv4 packets containing IPv4 options) to Best Current Practice
In-Reply-To: <20130916190502.31537.46859.idtracker@ietfa.amsl.com>
Message-ID: <Pine.LNX.4.64.1309201402090.16353@shell4.bayarea.net>
References: <20130916190502.31537.46859.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: OPSEC <opsec@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Sep 2013 23:24:06 -0000

On Mon, 16 Sep 2013, The IESG wrote:
> The IESG has received a request from the Operational Security
> Capabilities for IP Network Infrastructure WG (opsec) to consider the
> following document:
> - 'Recommendations on filtering of IPv4 packets containing IPv4 options.'
>   <draft-ietf-opsec-ip-options-filtering-05.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-09-30.



I would like to see the following issues addressed before this 
document is approved for publication.  I have suggested specific 
replacement text in most cases, but I recognize that there are other 
ways to address the concerns that I raise.



Sections 4.3 (LSRR) and 4.4 (SSRR):

OLD:
4.3.5.  Advice

   Routers, security gateways, and firewalls SHOULD implement an option-
   specific configuration knob whether packets with this option are
   dropped, packets with this IP option are forwarded as if they did not
   contain this IP option, or packets with this option are processed and
   forwarded as per [RFC0791].  The default setting for this knob SHOULD
   be "drop", and the default setting MUST be documented.

NEW:
4.3.5.  Advice

   Routers, security gateways, and firewalls SHOULD implement an option-
   specific configuration knob whether packets with this option are
   dropped or whether packets with this option are processed and
   forwarded as per [RFC0791].  The default setting for this knob SHOULD
   be "drop", and the default setting MUST be documented.

The same change should be applied to 4.4.5.

Rationale: pretending that the option is not present will result in
violation of the semantics of the option.  More specifically, if a node
is specified in the dettination address of the IPv4 header ignores an
unexpired source route option, then it will consume a packet that is
actually addressed to another node.



Section 4.6 (Stream ID):

Editorial:

OLD:
   However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and
   Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete.
   Therefore, it must be ignored by the processing systems.  See also
   Section 5.

NEW:
   However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and
   Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete.
   Therefore, it must be ignored by the processing systems.

Rationale: Section 5 is the IANA Considerations section.  RFC 6814 
requested IANA to mark this option as obsolete, and that has been 
done.  No change is needed to Section 5 as it does not request any 
actions from IANA.

Misuse of RFC 2119 language:

Section 4.6.3, Threats, says:

   No specific security issues are known for this IPv4 option.

while Section 4.6.5, Advice, says:

   Routers, security gateways, and firewalls SHOULD drop IP packets
   containing a Stream Identifier option.

Note that RFC 2119, Section 6 says:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions).  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for interoperability.

The document does not identify any interoperability problems or 
potential harm that would be mitigated by dropping packets with this 
option.  The SHOULD in Section 4.6.5 is therefore unjustified.

Possible fixes: either provide a valid justification for the SHOULD, 
change it to a MAY, or specify that the Stream ID option SHOULD be 
treated in the same manner as an unknown option, i.e., as specified 
in Section 4.23.4.  My vote would be for the latter; possible 
replacement text along those lines is as follows:

NEW:
4.6.5.  Advice

   Routers, security gateways, and firewalls SHOULD process IP packets
   containing this option in the same manner as those containing unknown
   options (see Section 4.23.4).



Section 4.7: The Internet Timestamp option has similar uses as the 
Record Route option, and should be treated similarly.  Specifically:

OLD:
4.7.1.  Uses

   This option provides a means for recording the time at which each
   system processed this datagram.

NEW:
4.7.1.  Uses

   This option provides a means for recording the time at which each
   system (or a specified set of systems) processed this datagram,
   and may optionally record the addresses of the systems providing
   the timestamps.

OLD:
4.7.4.  Operational and Interoperability Impact if Blocked

   None.

4.7.5.  Advice

   Routers, security gateways, and firewalls SHOULD drop IP packets
   containing an Internet Timestamp option.

NEW:
4.7.4.  Operational and Interoperability Impact if Blocked

   Network troubleshooting techniques that may employ the Internet
   Timestamp option (such as ping with the Timestamp option) would break
   when using the Timestamp option (ping without IPv4 options is not
   impacted).  Nevertheless, it should be noted that it is virtually
   impossible to use such techniques due to widespread dropping of
   packets that contain Internet Timestamp options.

4.7.5.  Advice

   Routers, security gateways, and firewalls SHOULD implement an option-
   specific configuration knob whether packets with this option are
   dropped, packets with this IP option are forwarded as if they did not
   contain this IP option, or packets with this option are processed and
   forwarded as per [RFC0791].  The default setting for this knob SHOULD
   be "drop", and the default setting MUST be documented.



Sections 4.9 (Probe MTU) and 4.10 (Reply MTU):

OLD:
4.9.3.  Threats

   No specific security issues are known for this IPv4 option.

NEW:
4.9.3.  Threats

   This option could have been exploited to cause a host to set its PMTU
   estimate to an inordinately low or an inordinately high value,
   thereby causing performance problems.

The same change should be applied to Section 4.10.3.  In the absence 
of this change (or something like it), the advice in Sections 4.9.5 
and 4.10.5 to drop packets containing these options lacks sufficient 
justification.



Section 4.11 (Traceroute):

OLD:
4.11.3.  Threats

   No specific security issues are known for this IPv4 option.

NEW:
4.11.3.  Threats

   Because this option required each router in the path both to
   provide special processing and to send an ICMP message, it 
   could have been exploited to perform a Denial of Service (DoS)
   attack by exhausting CPU resources at the processing routers.

In the absence of of this change (or something like it), the advice 
in Sections 4.11.5 to drop packets containing this option lacks 
sufficient justification.



Section 4.15 (VISA):

OLD:
4.15.5.  Advice

   Routers, security gateways, and firewalls SHOULD drop IP packets that
   contain this option.

NEW:
4.15.5.  Advice

   Routers, security gateways, and firewalls SHOULD process IP packets
   containing this option in the same manner as those containing unknown
   options (see Section 4.23.4).

Rationale: the identifiable security issues are identical with those 
associated with unknown options.



Section 4.16 (Extended Internet Protocol):

OLD:
4.16.3.  Threats

   There are no know threats arising from this option, other than the
   general security implications of IP options discussed in Section 3.

NEW:
4.16.3.  Threats

   This option was used (or was intended to be used) to signal that a
   packet superficially similar to an IPv4 packet actually containted a
   different protocol, opening up the possibility that an IPv4 node
   that simply ignored this option would process a received packet in
   a manner inconsistent with the intent of the sender.

In the absence of of this change (or something like it), the advice 
in Sections 4.16.5 to drop packets containing this option lacks 
sufficient justification.



Section 4.17 (Address Extension):

OLD:
4.17.5.  Advice

   Routers, security gateways, and firewalls SHOULD drop IP packets that
   contain this option.

NEW:
4.17.5.  Advice

   Routers, security gateways, and firewalls SHOULD process IP packets
   containing this option in the same manner as those containing unknown
   options (see Section 4.23.4).

Rationale: my reading of RFC 1475 reveals no specific security 
threats from this option, as is stated in Section 4.17.3.  The 
identifiable security issues are therefore no worse than those 
associated with unknown options.



4.18 (Sender-Directed Mult-Destination Delivery)

OLD:
4.18.3.  Threats

   This option could have been exploited for bandwidth-amplification in
   Denial of Service (DoS) attacks.

NEW:
4.18.3.  Threats

   This option could have been exploited for bandwidth-amplification in
   Denial of Service (DoS) attacks.  In addition, end nodes that simply
   ignored this option (instead of performing destination address
   filtering as specified in [RFC1770]) could have processed a received
   packet in a manner inconsistent with the intent of the sender.



4.20 (Upstream Multicast):

OLD:
4.20.3.  Threats

   None.

NEW:
4.20.3.  Threats

   A router that ignored this option instead of processing it as
   specified in [I-D.farinacci-bidir-pim] could have forwarded
   multicast packets to an unintended destination.

In the absence of of this change (or something like it), the advice 
in Sections 4.20.5 to drop packets containing this option lacks 
sufficient justification.



Section 4.21,  Quick-Start:

The last paragraph of 4.21.5 seems to belong in 4.21.3.



Thanks and regards,

Mike Heard