Subject: Re: [ippm] WGLC on draft-ietf-ippm-checksum-trailer-00

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Mar 2015 14:07:54 +0100

Greetings, all,

Those of you who pledged to review this draft and have not yet commented: last call ends in two days! :)

Thanks, cheers,

Brian (chair hat)

> On 18 Feb 2015, at 11:38, Brian Trammell <[email-masked]> wrote:
> 
> Greetings, all,
> 
> As noted in our status message, Working Group Last Call on draft-ietf-ippm-checksum-trailer-00, "UDP Checksum Trailer in OWAMP and TWAMP" begins today, until EOB Wednesday 4 March 2015. Please review the draft if you have not already, and direct any final comments on this draft to the list.
> 
> Many thanks, best regards,
> 
> Brian

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 3 Mar 2015 19:09:21 -0500

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
> Sent: Wednesday, February 18, 2015 5:39 AM
> To: [email-masked]
> Subject: [ippm] WGLC on draft-ietf-ippm-checksum-trailer-00
> 
> Greetings, all,
> 
> As noted in our status message, Working Group Last Call on draft-ietf-
> ippm-checksum-trailer-00, "UDP Checksum Trailer in OWAMP and TWAMP" begins
> today, until EOB Wednesday 4 March 2015. Please review the draft if you
> have not already, and direct any final comments on this draft to the list.
> 

I read the draft, and have some general comments:

It's a good idea, and a good draft.

The main issue I saw involves the restricted applicability to
unauthenticated mode in Section 3.4:

...
   On the other hand, when message authentication is used, an
   intermediate entity that alters test packets must also re-compute the
   Message Authentication Code (MAC) accordingly. The MAC update
   typically requires the intermediate entity to store the packet, re-
   compute its MAC, and then forward it. Thus, the benefit of the
   checksum trailer is effectively irrelevant when a MAC is used.

However, section 4.2.1 of RFC5357 TWAMP says:

   Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
   generated independently of any other pseudo-random numbers mentioned
   in this document).  However, implementations MUST provide a
   configuration parameter, an option, or a different means of making
   Packet Padding consist of all zeros.  Packet Padding MUST NOT be
   covered by the HMAC and MUST NOT be encrypted.

So, if the HMAC and encryption operations are supposed to ignore the Padding octets,
I don't understand how the Padding modifications made by an intermediate entity
will require HMAC re-calculation.

What am I missing, Tal?

Other points:

The Checksum Trailer is neither a Checksum itself, nor is it a trailer
because it is embedded in the existing Padding octets. They are 
Checksum alignment octets. I don't want to spend too many cycles on
the name but something more accurate could be helpful.

In TWAMP, there are two instances where the out-going packet can benefit
from this feature
- on egress from the Session-Sender
- on egress from the Session-Reflector
This should be noted in the Intro section.

regards,
Al

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 4 Mar 2015 07:11:03 +0000

Hi Al,

Thanks for the comments.

> So, if the HMAC and encryption operations are supposed to ignore the Padding octets, I don't understand how the Padding modifications made by an intermediate entity will require HMAC re-calculation.
> What am I missing, Tal?

Encrypted mode:
The 'intermediate entity' timestamps the OWAMP/TWAMP packet. Since the timestamp field is modified: (i) The checksum or checksum trailer need to be updated, and (ii) The packet needs to be re-encrypted since the timestamp field was modified.
As you pointed out, the padding is not protected by the encryption, but the timestamp *is*, and therefore re-encryption is required.

Authenticated mode:
You make a good point. In *authenticated* mode, the timestamp is *not* protected by the HMAC. Therefore, when the intermediate node updates the timestamp and checksum/checksum trailer, there is no need to update the HMAC.
I will update the draft.

> The Checksum Trailer is neither a Checksum itself, nor is it a trailer because it is embedded in the existing Padding octets. They are Checksum alignment octets. I don't want to spend too many cycles on the name but something more accurate could be helpful.

I considered a few options, such as <Checksum Complement> or <Checksum Diff>. My personal opinion is that <Checksum Trailer> is still the most suitable one, but I am open to other opinions / suggestions. 

Thanks,
Tal.

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Wednesday, March 04, 2015 2:09 AM
To: Brian Trammell; [email-masked]; Tal Mizrahi
Subject: RE: [ippm] WGLC on draft-ietf-ippm-checksum-trailer-00

> ippm-checksum-trailer-00, "UDP Checksum Trailer in OWAMP and TWAMP" 
> begins today, until EOB Wednesday 4 March 2015. Please review the 
> draft if you have not already, and direct any final comments on this draft to the list.
> 

The main issue I saw involves the restricted applicability to unauthenticated mode in Section 3.4:

...

So, if the HMAC and encryption operations are supposed to ignore the Padding octets, I don't understand how the Padding modifications made by an intermediate entity will require HMAC re-calculation.

What am I missing, Tal?

Other points:

The Checksum Trailer is neither a Checksum itself, nor is it a trailer because it is embedded in the existing Padding octets. They are Checksum alignment octets. I don't want to spend too many cycles on the name but something more accurate could be helpful.

In TWAMP, there are two instances where the out-going packet can benefit from this feature
- on egress from the Session-Sender
- on egress from the Session-Reflector
This should be noted in the Intro section.

regards,
Al

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 4 Mar 2015 11:46:24 -0500

Hi Tal,

thanks for your analysis and feedback.
...
> > because it is embedded in the existing Padding octets. They are Checksum
> > alignment octets. I don't want to spend too many cycles on the name but
> > something more accurate could be helpful.
> 
> I considered a few options, such as <Checksum Complement> or <Checksum
> Diff>. My personal opinion is that <Checksum Trailer> is still the most
> suitable one, but I am open to other opinions / suggestions.

I like Checksum Complement, it seems more accurate/descriptive to me. 
The ASCII-art, field description, etc., tells us where it will reside.

regards,
Al