Last Call Review of draft-ietf-6man-udpchecksums-

Request Review of draft-ietf-6man-udpchecksums
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-09
Requested 2012-09-20
Authors Marshall Eubanks, Phil Chimento, Magnus Westerlund
Draft last updated 2012-10-04
Completed reviews Genart Last Call review of -04 by Peter Yee (diff)
Genart Last Call review of -?? by Peter Yee
Genart Last Call review of -06 by Peter Yee (diff)
Genart Telechat review of -07 by Peter Yee (diff)
Secdir Last Call review of -?? by David Waltermire
Assignment Reviewer David Waltermire 
State Completed
Review review-ietf-6man-udpchecksums-secdir-lc-waltermire-2012-10-04
Review result Ready with Nits
Review completed: 2012-10-04


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 document provides an update to IPv6 (RFC2460) providing requirements for using a performance optimization for use cases where a UDP-based tunneling protocol is used, where the inner protocol includes a checksum.  In this case the outer UDP checksum can be assigned a zero value to avoid the computational cost of checksum calculation and verification.

In general I found this draft to be very clear on the protocol implications.  The security considerations section addresses the fact that no new vulnerabilities have been added as the result of these changes. In general this document is ready with one suggestion and a couple minor nits.

My only concern is around clearly communicating to application developers what the security risks are.  According to Section 4, paragraph 4, bullet 4, if the packet is corrupted and sent to the wrong endpoint, but the same tunneling protocol is used with a matching context, then the packet should be decapsulated and forwarded.  It is the application developers responsibility to verify and discard the data if needed.  It looks like this situation could be used to craft datagrams for use in a denial of service attack, by flooding an application with junk datagrams or worse yet could be used to affect the application state (according to I-D.ietf-6man-udpzero examples).  It is also looks like it is possible to achieve this using a crafted datagram with a valid checksum.  It might be good to include text warning application developers about this possible situation in the security considerations section.  The warning could reference any other appropriate documents describing possible scenarios or any guidance related to addressing this issue.
Additional editorial nits:

- In the last sentence of the abstract "defines" should be "define"
- One other NIT in draft-ietf-6man-udpzero-06, section-5.1, item 5: in the last sentence "mechanisms" should be "mechanism".

David Waltermire