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
