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