Subject: Re: [secdir] secdir review of draft-ietf-ippm-checksum-trailer

From: Tal Mizrahi <[email-masked]>
Date: Sun, 15 Nov 2015 10:17:49 +0000

Hi Rich,

Thanks for the comments.

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

It is meant to the latter, i.e., a single flow within a node. I will clarify this in the next version of the draft.

Thanks,
Tal.

>-----Original Message-----
>From: Salz, Rich [mailto:[email-masked]]
>Sent: Thursday, October 22, 2015 6:07 PM
>To: [email-masked]; [email-masked];
>[email-masked]
>Subject: secdir review of draft-ietf-ippm-checksum-trailer
>
>[ 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: [email-masked] Twitter: RichSalz
>

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 19 Nov 2015 11:16:05 +0000

Hi Rich,

The issue you raised was addressed in the current version of the draft (Figure 1), which was posted this week.
https://tools.ietf.org/html/draft-ietf-ippm-checksum-trailer-05

Please let me know if there are further comments.

Thanks,
Tal.

>From: Tal Mizrahi
>Sent: Sunday, November 15, 2015 12:18 PM
>To: 'Salz, Rich'; [email-masked]; [email-masked];
>[email-masked]
>Subject: RE: secdir review of draft-ietf-ippm-checksum-trailer
>
>Hi Rich,
>
>Thanks for the comments.
>
>IP Network "cloud"?
>>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.
>>
>>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.
>>
>>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 :)
>>
>>--