Re: [Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03

"MORTON, ALFRED C (AL)" <acmorton@att.com> Thu, 22 October 2015 22:32 UTC

Return-Path: <acmorton@att.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EDA1B2EA2 for <gen-art@ietfa.amsl.com>; Thu, 22 Oct 2015 15:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0YXmC_HXumi for <gen-art@ietfa.amsl.com>; Thu, 22 Oct 2015 15:32:22 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 858C41B2D9C for <gen-art@ietf.org>; Thu, 22 Oct 2015 15:32:22 -0700 (PDT)
Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 4D43E12264F; Thu, 22 Oct 2015 18:32:15 -0400 (EDT)
Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.255.123]) by mail-azure.research.att.com (Postfix) with ESMTP id 2AC34E0A40; Thu, 22 Oct 2015 18:32:22 -0400 (EDT)
Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Thu, 22 Oct 2015 18:32:21 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, General Area Review Team <gen-art@ietf.org>
Date: Thu, 22 Oct 2015 18:32:19 -0400
Thread-Topic: Gen-ART review for draft-ietf-ippm-checksum-trailer-03
Thread-Index: AdEM4fI3grCA7Hh5TrK4VRztKuBZXwANDIYg
Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB67F9B6A@NJFPSRVEXG0.research.att.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA5CB5BB2B@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB5BB2B@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D0BB67F9B6ANJFPSRVEXG0re_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/EmUhHhG5UdVe-K-lDD0J26obrDc>
Cc: "draft-ietf-ippm-checksum-trailer.all@tools.ietf.org" <draft-ietf-ippm-checksum-trailer.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 22:32:26 -0000

Hi Dan,
I'll wade-in as Document Shepherd and begin to answer your questions,
Al

1.   It is not clear to me how backwards compatibility is ensured. How do implementations make distinction between OWAMP or TWAMP packets that use timestamp update and Checksum Complement rather than timestamp update and UDP checksum update? Is a mix of senders/receivers (for OWAMP) or senders/reflectors (for TWAMP) that some support and some do not support Checksum Complement possible?

[ACM]
Yes, the mix is possible, because the receiver stack performs normally
and evaluates checksums. Inserting the time stamp at a lower layer and
keeping the checksum accurate by providing the checksum-complement octets at the
same lower layer is a sender-only process.

2.   The last paragraph in section 4 reads: 'The concept described in this document is intended to be used only in unauthenticated or in authenticated mode.' This seems either a mistake, or I did not understand what it means and some clarification is needed.

[ACM]
In OWAMP and TWAMP, there are three Modes of operation for the Core protocol
(without optional extensions):
Unauthenticated (completely in the clear)
Authenticated
Encrypted

Authenticated mode does not calculate the HMAC over the timestamps and packet padding
fields in the Test Session packets, where checksum complement is used.
So, after lower layer placement of the timestamp and checksum-complement,
the HMAC is still valid.

Encrypted Mode requires the Timestamps of test packets to be encrypted,
so timestamps cannot be inserted at lower layers before transmission,
(unless you are also re-encrypting, then the checksum complement has little value,
as Tal points out).

Section 3.4 explains this, and provides limited *WAMP background
on the modes.

Hope this helps,
Al



From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Thursday, October 22, 2015 11:55 AM
To: General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer.all@tools.ietf.org
Subject: Gen-ART review for draft-ietf-ippm-checksum-trailer-03


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Document: draft-ietf-ippm-checksum-trailer-03

Reviewer: Dan Romascanu

Review Date: 10/22/15

IETF LC End Date: N/A

IESG Telechat date: N/A



Summary:



This document is ready for publication. I have a couple of minor issues that need clarification and can be solved easily by minor editing.



Major issues:



Minor issues:



1.       It is not clear to me how backwards compatibility is ensured. How do implementations make distinction between OWAMP or TWAMP packets that use timestamp update and Checksum Complement rather than timestamp update and UDP checksum update? Is a mix of senders/receivers (for OWAMP) or senders/reflectors (for TWAMP) that some support and some do not support Checksum Complement possible?

2.       The last paragraph in section 4 reads: 'The concept described in this document is intended to be used only in unauthenticated or in authenticated mode.' This seems either a mistake, or I did not understand what it means and some clarification is needed.



Nits/editorial comments: