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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Fri, 23 October 2015 05:49 UTC

Return-Path: <dromasca@avaya.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 E947F1B3268 for <gen-art@ietfa.amsl.com>; Thu, 22 Oct 2015 22:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 pU6SY8q8h12W for <gen-art@ietfa.amsl.com>; Thu, 22 Oct 2015 22:49:19 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A12F1B3269 for <gen-art@ietf.org>; Thu, 22 Oct 2015 22:49:18 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AeAwBBP8ZV/yYyC4dbGQEBAYIyISxUaQapbgaTNgmCA4V6AoEmOBQBAQEBAQEBgQqEIwEBAQEDEhtMEAIBCA0EAwEBAQsWBwcyFAkIAQEEAQ0FCBqIDAEMrGygPgEBAQEBAQEBAQEBAQEBAQEBAQEBAReGH4UyhDAoIA0EBgEJgw+BFAWSBYMGAYUBiSpGg1+DC4hahESDZhcPgg4cgVNvAQEBgQJDgQQBAQE
X-IPAS-Result: A2AeAwBBP8ZV/yYyC4dbGQEBAYIyISxUaQapbgaTNgmCA4V6AoEmOBQBAQEBAQEBgQqEIwEBAQEDEhtMEAIBCA0EAwEBAQsWBwcyFAkIAQEEAQ0FCBqIDAEMrGygPgEBAQEBAQEBAQEBAQEBAQEBAQEBAReGH4UyhDAoIA0EBgEJgw+BFAWSBYMGAYUBiSpGg1+DC4hahESDZhcPgg4cgVNvAQEBgQJDgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="125464966"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Oct 2015 01:49:12 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Oct 2015 01:49:13 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 23 Oct 2015 07:49:10 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>, General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART review for draft-ietf-ippm-checksum-trailer-03
Thread-Index: AdEM4fI3grCA7Hh5TrK4VRztKuBZXwANDIYgAA/wUQA=
Date: Fri, 23 Oct 2015 05:49:10 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB5D60E@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA5CB5BB2B@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D0BB67F9B6A@NJFPSRVEXG0.research.att.com>
In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB67F9B6A@NJFPSRVEXG0.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.48]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB5D60EAZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/AMmwaDRTJqkToCr86J5jbw7Pc6U>
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: Fri, 23 Oct 2015 05:49:23 -0000

Hi Al,

Thanks for the explanation, this helped me a lot.


1.       It may be useful to insert a paragraph that provides this explanation

2.       Makes sense - no change needed.

Regards,

Dan


From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Friday, October 23, 2015 1:32 AM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer.all@tools.ietf.org
Subject: RE: Gen-ART review for draft-ietf-ippm-checksum-trailer-03

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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=BQMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=nJVpve6nf4_IRNZwgYgb3Wvwua190G7VDeX_tVtAfcY&s=77sOZhtQIK_EQ0NICPaIIQs0bTXgAPQT9SLzjuCjoyE&e=>>.



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: