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(_at_)ietf(_dot_)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