Last Call Review of draft-ietf-6man-udpzero-
review-ietf-6man-udpzero-secdir-lc-weiler-2012-10-11-00

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