Skip to main content

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

Request Review of draft-ietf-ippm-checksum-trailer
Requested revision 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
Review review-ietf-ippm-checksum-trailer-03-secdir-lc-salz-2015-10-29
Reviewed revision 03 (document currently at 06)
Result Has Nits
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