Reviewreview-ietf-6man-udpzero-secdir-lc-weiler-2012-10-11

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This is a design doc examining the merits of allowing UDP with zero
checksums in IPv6.
This whole doc is about some very subtle stuff (at least to me), and I
wonder, given its revision history, how well cooked and well reviewed
it is. The security considerations section is this doc is
distressingly short and offers tantalizing hints of amusing attacks:
"These checks are also desirable to ensure packet counters correctly
log actual activity, and can be used to detect unusual behaviours."
It was reassuring to read the security considerations section of the
related doc draft-ietf-6man-udpchecksums, which I'll include here:
It requires less work to generate zero-checksum attack packets than
ones with full UDP checksums. However, this does not lead to any
significant new vulnerabilities as checksums are not a security
measure and can be easily generated by any attacker, as properly
configured tunnels should check the validity of the inner packet and
perform any needed security checks, regardless of the checksum
status, and finally as most attacks are generated from compromised
hosts which automatically create checksummed packets (in other words,
it would generally be more, not less, effort for most attackers to
generate zero UDP checksums on the host).
Given the above, I'm not really worried about "security" concerns, but
I still encourage the ADs to pay close attention to the substance of
the doc. Pay particular attention to section 5, which talks about
requirements that a spec "should consider adding".
Suggestion for the authors:
Section 5.1 number 3: rather than "A port for which zero-checksum has
been enabled must not log the datagram" how about "...is not required
to log..."? (Compare to the parallel section in udbchecksums: "of
course, there might be other reasons to log such packets".)
-- Sam