Last Call Review of draft-ietf-ippm-checksum-trailer-03

Request Review of draft-ietf-ippm-checksum-trailer
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-10-28
Requested 2015-10-15
Authors Tal Mizrahi
Draft last updated 2015-10-29
Completed reviews Genart Last Call review of -03 by Dan Romascanu (diff)
Genart Telechat review of -05 by Dan Romascanu (diff)
Genart Telechat review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -03 by Rich Salz (diff)
Opsdir Last Call review of -03 by Sarah Banks (diff)
Assignment Reviewer Rich Salz 
State Completed Snapshot
Review review-ietf-ippm-checksum-trailer-03-secdir-lc-salz-2015-10-29
Reviewed rev. 03 (document currently at 06)
Review result Has Nits
Review completed: 2015-10-29


[ My first review; please let me know if anything's wrong]

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.

In my view this document is Ready with nits; suggested clarification of Figure 1, below.

This document a mechanism for an intermediary to use space in a padding area to counteract the effect of a prior intermediary adding a high-accuracy timestamp into a UDP packet. The technique is used elsewhere (draft-ietf-ntp-checksum-trailer and IEEE1588) and dates back to RFC 1624 from 1994. The mechanism is better than the current approach, which zero's out the checksum and makes any checksum impossible.

The document and its security considerations are seem thorough, discussing the impact on encrypted packets, the general idea of an MITM modifying packets, and so on.

I think Figure 1 could be improved by showing how and/or where the checksum trailer is applied inside the "enabled Node" box.  Is it a separate node, or is it all a single flow within a node before the packet is put onto the IP Network "cloud"?  Also, the art of the cloud is commendable :)

Senior Architect, Akamai Technologies
IM: richsalz at Twitter: RichSalz