Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt

Greg Mirsky <gregimirsky@gmail.com> Sat, 10 November 2018 09:23 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2552F130E11 for <ippm@ietfa.amsl.com>; Sat, 10 Nov 2018 01:23:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UgZRQC3YTkMx for <ippm@ietfa.amsl.com>; Sat, 10 Nov 2018 01:23:14 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0990130DE4 for <ippm@ietf.org>; Sat, 10 Nov 2018 01:23:13 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id q186-v6so3611368ljb.5 for <ippm@ietf.org>; Sat, 10 Nov 2018 01:23:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=16EbQ0J7ZSeBEFr+6gTPjHXkZZEzjBVoAbYqSIrZ+Kg=; b=FV6NkkTa8CElyoUJRk4Tj9FaE7Ba3gEdTeEntywPWE1n9Cs9l90QPASZRhTGuNjKyk CEg3X5HwPaqk1uVq/XN03CwehEfPSr0mrczFr5P6+cm5p2XExrAuoL1tMP+qY9sj/0Ks olHUFKXNHQA0yyF49c19jXtL63n9FFQXpVedoTnONaCmpXfT2f9k2TGB2c6nhOtH3AC4 rTj9tz5e84E8QMsp9Ssmwf2mzD7soRLGO2scb07n5tviH81jNzRGzp5IwPoT3OO0kVSq RQk22vPUBPhiC31zg+Mg9kM4EEepVvDZZEoPnahdPNEVmdvB4BBLCoXKBKty9qiRaX2H /B3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=16EbQ0J7ZSeBEFr+6gTPjHXkZZEzjBVoAbYqSIrZ+Kg=; b=sqHboULZp2eHJfcrWrQobv2umCtVTAe9k2AOt/7GdtWv0JfI4vf66aVA31eXNulD8a I1tNtmGSh7EmaeHtkf3/dlqtW47dp7VQ8CZ/E3vYv2y4MDtaL+kLB488+C+Y/6dwzom2 CAwyoQUkPlQf9J/rjZaUzZJdvNWSOhsx2EMT2oU1f0CuBoPq4MAsyhMSfppRlD9/aBWK g6rxZ/QyjSoeU946fqkgN+xxSGdmytQVe1NxgbnSdq8kNe3hw2X/KhP2rPDG9+w2eKjw c2Ra/X+sx6LDnMBhII7kF71cAfJYPvUeh0optoslXlKW5233ZJxV/q7AjLY6inLlMAfY G3sQ==
X-Gm-Message-State: AGRZ1gK5V6+qL8jZxgnJ0lQx82+K69NPp4w9Ii39mdS3KzQkroboqtQB cUeO2F7Jfuzsc64DcLlRW3KLeCj/WibwntW9fdA=
X-Google-Smtp-Source: AJdET5erumL7OV9qDRkVB86v8zyAhkig2W2X2gQ1jjDTAt67bMlowvQoKv4gohBpFv0x4zq9KIcqSeNkE8kTw7ltwrQ=
X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr7576899ljd.94.1541841791742; Sat, 10 Nov 2018 01:23:11 -0800 (PST)
MIME-Version: 1.0
References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <CA+RyBmV_BQbjuf63eZWShaZ1DnZB0cUmbaJMzDQrnZHG7xGxtA@mail.gmail.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <CA+RyBmXWMq1c79O9x2uhmZxXjt0gipe=B_KTCcstW5Jxum8nrw@mail.gmail.com> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> <B869E846-83DF-429C-A833-A1D2B613DA73@cnet.fi.uba.ar> <CA+RyBmWS-3hpWU=37b1geHtXZFAVA3Ap5ohz3DYpeOhShGiv0g@mail.gmail.com> <F77B6597-C36C-483B-8325-AE69DE393E86@cisco.com>
In-Reply-To: <F77B6597-C36C-483B-8325-AE69DE393E86@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 10 Nov 2018 16:23:01 +0700
Message-ID: <CA+RyBmWfG0Mjb+H0vUAoA0hBzPmSePWssr5dLmBkkVcy0ZXYHA@mail.gmail.com>
To: bew@cisco.com
Cc: "J. Ignacio Alvarez-Hamelin" <ihameli@cnet.fi.uba.ar>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bf70a057a4c04a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/M30Pk7FW7GCdxOnvwjlpS49vki4>
Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Nov 2018 09:23:17 -0000

Hi Brian,
I've started the new working version to apply updates resulting from our
discussion and need to clarify one question with you. You've suggested that
confidentiality may be provided by encryption at a higher level, i.e., not
on the STAMP message. Thus, as I understand, we would not need to define
the encrypted mode in STAMP and only have two modes - unauthenticated and
authenticated. Would you agree?

Regards,
Greg

On Wed, Nov 7, 2018 at 10:50 AM Brian Weis (bew) <bew@cisco.com> wrote:

> Hi Ignacio and Greg,
>
> ECDSA is a digital signature algorithm, which is very expensive and
> because of this it is not traditionally used to protect network data
> packets.  I don’t recommend specifying it. Unless this is a rarely sent
> data packet sent, you would be consuming a substantial amount of the CPU by
> applying a digital signature to every packet sent with STAMP. Also, in
> order to get the value  you want, you actually have to create a hash of the
> packet (e.g., using SHA1/SHA256) and then sign the hash, where the result
> will be at least the length of a full HMAC output. So you’re not saving any
> space.
>
> Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4 is
> very reasonable.  Section 5 of RFC 2104 (HMAC) says how it’s acceptable to
> truncate the hash output, and security protocols usually do this.  IPSec
> truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and HMAC-SHA-256 is
> truncated to 128 bits (RFC 4868).  Since -03 was willing to apply a 128-bit
> truncated hash, I think you could safely specify using HMAC-SHA-256 with a
> 128 bit truncation. Note that if you specify the use of HMAC-SHA1, you will
> very likely run into SecDir complaints when you get to IETF last call.
>
> I did mention in the IPPM meeting that adding AES support is bit more
> problematic. I would recommend specifying that when confidentiality is
> needed that it be done a higher layer. If you do decide to keep it in this
> draft, you should describe what is the value of protecting only the first
> 16 octets. Also, you should know that cryptographers do not recommend using
> EBC. A Wikipedia page describes this plainly: "The disadvantage of this
> method is a lack of diffusion. Because ECB encrypts
> identical plaintext blocks into identical ciphertext blocks, it does not
> hide data patterns well. In some senses, it doesn't provide serious message
> confidentiality, and it is not recommended for use in cryptographic
> protocols at all.” (
> https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_(ECB))
> .
>
> The other mode -03 mentioned is using AES-CBC to protect the entire
> message. That’s a conventional use of AES, but when AES-CBC is used, both
> the encryptor and decrypt need the same Initialization Vector (IV) used
> with the method. Traditionally it is included in the packet, so that’s
> another 16 octets you probably need to add to the packet format. This
> should NOT replace the HMAC field, because cryptographers strongly state
> that it is bad practice to send an unauthenticated encrypted packet.
>
> I don’t see the rationale in -03 for needing confidentiality. So it might
> be best to stick with an HMAC-SHA256 hash, and if confidentiality is
> required to use a higher layer encryption. Otherwise, you’ll need to do a
> lot more specification of how the confidentially is done in this draft.
>
> I hope that helps.
>
> Brian
>
> On Nov 7, 2018, at 9:15 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Ho J.Ignacio,
> thank you for the comment and helpful suggestion. Will read the
> draft-alavarez-hamelin-tictoc-sic and respond accordingly in a short time.
> From the quick run through the draft, I agree with you that ECDSA offers
> advantages over the SHA1 of the same length. Just need to check for
> possible impact on YANG data model.
>
> Regards,
> Greg
>
> On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin <
> ihameli@cnet.fi.uba.ar> wrote:
>
>> Hi Greg,
>>
>> Today at the IPPM meeting I said that you could consider using SHA1 256
>> with bits for authentication, to respect some security standards. Your
>> comment that is expensive, and I agree with that.
>> I propose another alternative, is the one that I used in
>> draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital Signature
>> Algorithm (ECDSA), which yields in few bits and has some securities form de
>> cryptographic point of view.
>>
>>
>> Best withes,
>>
>>         J. Ignacio
>> _______________________________________________________________
>>
>> Dr. Ing. José Ignacio Alvarez-Hamelin
>> CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
>> Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
>> +54 (11) 5285 0716 / 5285 0705
>> e-mail: ihameli@cnet.fi.uba.ar
>> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
>> _______________________________________________________________
>>
>>
>>
>> > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) <ietf@trammell.ch>
>> wrote:
>> >
>> > hi Greg,
>> >
>> > We'll put this and a tentative start of WGLC on the Bangkok agenda..
>> >
>> > Thanks, cheers,
>> >
>> > Brian
>> >
>> >> On 16 Oct 2018, at 01:00, Greg Mirsky <gregimirsky@gmail.com> wrote:
>> >>
>> >> Hi Brian,
>> >> my apologies for the delayed response. The new version of the draft
>> has been just uploaded. The updates include the new section that describes
>> authentication and encryption operations on STAMP packets. I'd request the
>> presentation slot at the meeting and, if there are no significant concerns,
>> would ask to consider starting the WG LC on the base specification. The
>> work on the STAMP YANG data model still on-going and we're addressing the
>> comments from the early YANG Doctors review by Mahesh. I expect we'll have
>> the new version by the end of November.
>> >>
>> >> Regards,
>> >> Greg
>> >>
>> >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) <ietf@trammell.ch>
>> wrote:
>> >> hi Greg,
>> >>
>> >> following up a bit late, perhaps... when do you think this will be
>> ready for LC?
>> >>
>> >> Cheers,
>> >>
>> >> Brian (as WG co-chair)
>> >>
>> >>> On 8 Sep 2018, at 00:53, Greg Mirsky <gregimirsky@gmail.com> wrote:
>> >>>
>> >>> Dear All,
>> >>> minor editorial improvements to the document..
>> >>> Your comments, questions, and suggestions always welcome and much
>> appreciated.
>> >>>
>> >>> Regards,
>> >>> Greg
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: <internet-drafts@ietf.org>
>> >>> Date: Fri, Sep 7, 2018 at 2:56 PM
>> >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt
>> >>> To: i-d-announce@ietf.org
>> >>> Cc: ippm@ietf.org
>> >>>
>> >>>
>> >>>
>> >>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> >>> This draft is a work item of the IP Performance Measurement WG of the
>> IETF.
>> >>>
>> >>>        Title           : Simple Two-way Active Measurement Protocol
>> >>>        Authors         : Greg Mirsky
>> >>>                          Guo Jun
>> >>>                          Henrik Nydell
>> >>>                          Richard Foote
>> >>>        Filename        : draft-ietf-ippm-stamp-02.txt
>> >>>        Pages           : 14
>> >>>        Date            : 2018-09-07
>> >>>
>> >>> Abstract:
>> >>>   This document describes a Simple Two-way Active Measurement Protocol
>> >>>   which enables measurement of both one-way and round-trip performance
>> >>>   metrics like delay, delay variation, and packet loss.
>> >>>
>> >>>
>> >>> The IETF datatracker status page for this draft is:
>> >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
>> >>>
>> >>> There are also htmlized versions available at:
>> >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02
>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02
>> >>>
>> >>> A diff from the previous version is available at:
>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-02
>> >>>
>> >>>
>> >>> Please note that it may take a couple of minutes from the time of
>> submission
>> >>> until the htmlized version and diff are available at tools.ietf.org.
>> >>>
>> >>> Internet-Drafts are also available by anonymous FTP at:
>> >>> ftp://ftp.ietf.org/internet-drafts/
>> >>>
>> >>> _______________________________________________
>> >>> ippm mailing list
>> >>> ippm@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/ippm
>> >>>
>> >>> _______________________________________________
>> >>> ippm mailing list
>> >>> ippm@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/ippm
>> >>
>> >
>> > _______________________________________________
>> > ippm mailing list
>> > ippm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/ippm
>>
>> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>
> --
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: +1 408 526 4796
> Email: bew@cisco.com
>
>