Skip to main content

Last Call Review of draft-ietf-6man-udpchecksums-
review-ietf-6man-udpchecksums-secdir-lc-waltermire-2012-10-04-00

Request Review of draft-ietf-6man-udpchecksums
Requested revision 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
I-D last updated 2012-10-04
Completed reviews Genart Last Call review of -04 by Peter E. Yee (diff)
Genart Last Call review of -?? by Peter E. Yee
Genart Last Call review of -06 by Peter E. Yee (diff)
Genart Telechat review of -07 by Peter E. Yee (diff)
Secdir Last Call review of -?? by David Waltermire
Assignment Reviewer David Waltermire
State Completed
Request Last Call review on draft-ietf-6man-udpchecksums by Security Area Directorate Assigned
Result Ready w/nits
Completed 2012-10-04
review-ietf-6man-udpchecksums-secdir-lc-waltermire-2012-10-04-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.

Summary:

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".

Sincerely,
David Waltermire