Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Thu, 01 August 2019 16:32 UTC

Return-Path: <fbrockne@cisco.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 1AC001201A2; Thu, 1 Aug 2019 09:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TtTF/9/Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jBTllxeK
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 v-1KnUu5mkPV; Thu, 1 Aug 2019 09:32:25 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079E31200E0; Thu, 1 Aug 2019 09:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7294; q=dns/txt; s=iport; t=1564677144; x=1565886744; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mpmRPZ04h4SVYzESkz1s/hvl1sp3a1EA9HWx4PwyCvI=; b=TtTF/9/Zmp/ojTpGwuxVEj6AOfwjH5pYspepM4mDdec7WfptnE+l2oOO dPLRSWgqb0/sSb3b8Ux1iO9ORvlXitHw7kvi2S5T3IUqXiGq8gTZ5p5g1 YWao9L9hASqjQVdwgZnIsNceiaKFhQV241ajMyuiZS466tDSWB9dW84ao Q=;
IronPort-PHdr: 9a23:3Kb+1h10qwEELePRsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQB0fhK/XpaSESF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAADEE0Nd/49dJa1mGQEBAQEBAQEBAQEBAQcBAQEBAQGBVQIBAQEBAQsBgUQkBScDbVUgBAsqCodbA4smgluJVY4CgS4UgRADVAkBAQEMAQEYCwoCAQGEQAKCVSM2Bw4BAwEBBAEBAgEGbYUeDIVKAQEBBAEBEAsdBgEBLAsBCwQCAQgRBAEBAR4FCyEGCx0IAgQBDQUIEweDAYFqAx0BAgyiSgKBOIhggiOCegEBBYEyAYNQDQuCEwmBNAGJFoJJF4FAP4ERRoJMPoIaRwEBgSkSKIM7giaMHggZiXiUIUAJAoIahlyJSIQSgi6HKIQQijSMYQlYgTKGH4F3jh0CBAIEBQIOAQEFgVcFLIFYcBU7gmwJgjk3bwEBgkmCZIIwhT9ygSmLQ4EwAYEgAQE
X-IronPort-AV: E=Sophos;i="5.64,334,1559520000"; d="scan'208";a="609356235"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Aug 2019 16:32:23 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x71GWNcL023252 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Aug 2019 16:32:23 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Aug 2019 11:32:22 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Aug 2019 11:32:22 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 1 Aug 2019 12:32:22 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IYhw2GNApreRRAOtpZRa9AAm/xRsq7wJbH70LbaWsHtGP1dv4QUXVpkSNnC+bkbFhK9+O38Xi6yi/TSfYIekINfAlMBHyLcc7WFW0wz9cjwyxtXuHJpkqmGVDwfPEZ7k1GpY+HxSDC0GaaOafgriC44+qFRz7ZmKI576W1mBdPqgqxVfdYxJveb/+UiariaA9IciLIgpbucglpRJv2l/XtkFrPTLt+iP+muXuesxER8OZrEg4e10ZebsvqcBawBP9oOdY1ANfG/gnROjMNTHFmy2+gOgoBZksLMJoVMuPqXmsTDzHiRs8TOfWOXB3XSv1LxcwTnmC8fa2CKP8vcYXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPenhGiVSUQ0QYjyJM2hmIsBwtdaprGtxSS6Y+80rXI=; b=oP8l23W8uJEhvbMbTZwxWGKiC4G1yw8GbU+3Tc7dkm1THQsYXGJK5yrHI4meT0qOQLWqlEj8swkG/dYR/ediapSFKzaeA+Kl2NIP/bsRt2vIQFhCfvO/e30g6vYbYSeCPO+2+dy/NFHJ76WaVb6jERf6QqQsjWGJE2+j+fsWs4DFoFlcLhVNPh+jH4TDY7WKdjVJUY6wT9iKvjIoOM5Y/h0lO4l14s22gVoGnNJRAgHmWxKoQK70UYyWawvGEPBZQF0jRedUuc/RDhilbM1GaaYVbG+KUs4L45KykdKkoQa70jiRcxfy+InDKW8EQGImF59obZhaKiUZ4hj8I7ET1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPenhGiVSUQ0QYjyJM2hmIsBwtdaprGtxSS6Y+80rXI=; b=jBTllxeKcXMWJBQsyRv4nCDXHb0+bes52ahS6z5d1KAUtDTcSWti2DOapujBBZzcaKzc3ZFZghwr1vKQbOAPsbG5hvERQ4fhlUcPBXJfsQdoEspu8wRXdVBRh0HOktVX/YEccIItgkoEUvp/pYVdRUAdpwfG7u/zM2Brs65dS6c=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.227.17) by BYAPR11MB2632.namprd11.prod.outlook.com (52.135.227.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.13; Thu, 1 Aug 2019 16:32:20 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d443:d196:b8f6:d858]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d443:d196:b8f6:d858%7]) with mapi id 15.20.2094.017; Thu, 1 Aug 2019 16:32:20 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Tom Herbert <tom@quantonium.net>, Greg Mirsky <gregimirsky@gmail.com>
CC: IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
Thread-Index: AQHVQxPfcyCqkf67BUCt2X7oyo6/OKblHFwAgAA/ZQCAASInQA==
Date: Thu, 01 Aug 2019 16:32:20 +0000
Message-ID: <BYAPR11MB258458D075E929C9C0CF4901DADE0@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <CA+RyBmVnkMFEQv=Hr3y9OD09+_vocHRgnGQnLwEVO=yuTcptEQ@mail.gmail.com> <EAB5C70D-A160-423E-84FE-3CE7AC079168@trammell.ch> <CA+RyBmWxh+FRxnrFH9ZbQ_F0V42UTm8aE0yOpd2N7vXb-Eqaiw@mail.gmail.com> <CAPDqMeoS8ZatMF9SXNYi0bPDdRN7T0gj-snxrLNL+1arGv5RTw@mail.gmail.com>
In-Reply-To: <CAPDqMeoS8ZatMF9SXNYi0bPDdRN7T0gj-snxrLNL+1arGv5RTw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com;
x-originating-ip: [173.38.220.53]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d7377fcf-5e63-4c01-d7e4-08d7169dd374
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB2632;
x-ms-traffictypediagnostic: BYAPR11MB2632:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB263227CBA96F930DD92DC55ADADE0@BYAPR11MB2632.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01165471DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(54094003)(51914003)(13464003)(199004)(189003)(186003)(229853002)(478600001)(53936002)(54906003)(6246003)(86362001)(74316002)(110136005)(99286004)(55016002)(11346002)(966005)(446003)(7696005)(476003)(9686003)(76176011)(102836004)(6306002)(7736002)(6506007)(486006)(6436002)(53546011)(5660300002)(305945005)(66476007)(66556008)(14444005)(561944003)(64756008)(8676002)(256004)(3846002)(6116002)(26005)(68736007)(66946007)(2906002)(25786009)(52536014)(76116006)(33656002)(66066001)(81156014)(14454004)(71200400001)(316002)(81166006)(4326008)(66446008)(8936002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2632; H:BYAPR11MB2584.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: oKAJoMI2U/0v3iWQh4xE4/ENLfXC6HAKeZc2lTkTRoKZiW+KzKU0BRWuAmW/cU3hy3AAaPMrLvdcHhISTzMDX5dpf9N85nlLm4J4ZnqmU5IswKQMk3ZTiGRuQaqIuzqMbejKpZEhheQKtk3OS1zY5tTZpau07wp66rBBDX65tU+ayG4quWZR8IL6vV9XYJw+8GKU3sIbQzhzNS7dgyuHg1rAu8I6rw9OxRhiD0Z9BqZveY4JE1lZefPo6rYPNuL+Ba2eyn1m6ukVF/9hAurTDGjGrkwjVv0/51dKltvXBY2tToKSJy2ROFhWScrvmr/i9FuNuFl5F+EWoBa1uOD1Sn7D/bxNozUcSQjKR4ADSYqGcc2s6YxOaBxe2uEZ9S0TdvhBsfjNHWv5UkUCQQ9Jwh4yDUhp1FJ6Vo0bihsrHOg=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d7377fcf-5e63-4c01-d7e4-08d7169dd374
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2019 16:32:20.6182 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fbrockne@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2632
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/stwivRy49JmgzBfVj4079zNyiOM>
Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
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: Thu, 01 Aug 2019 16:32:27 -0000

Some additional notes on the different flags - restating and expanding the discussion we had at the WG meeting in Montreal:

Loopback flag: 
The loopback flag was inspired by a specific use case, which could be summarized as "rapid identification of a failed link/node in a DC": In a DC (read: controlled/specific domain), one runs UDP probes (draft-lapukhov-dataplane-probe-01) over a v6 fabric. In case a UDP probe detects a failure, one adds the IOAM trace option and enables loopback mode - i.e. every node sends a copy back to the source in addition to forwarding the packet. Correlating the information from both ends allows one to pinpoint the failed node/link rapidly and gives one a view of the overall forwarding topology. This use-case was implemented in FD.io/VPP roughly 2 years ago and was also showcased at IETF bits-n-bites. There is a rough outline of the open source implementation available here: https://jira.fd.io/browse/VPP-471 .
In more generic words: Loopback mode is like all IOAM, a domain specific feature. Loopback mode is to enrich an existing (here the dataplane-probe) active OAM mechanism.
Reading through the comments below, it proves that the current draft is indeed a good basis for the discussion and it also clearly shows that we need to add a section to the document that expands on how loopback mode is expected to be used. 

Immediate export flag:
Per the WG discussion in Montreal - and the follow up breakout meeting (https://mailarchive.ietf.org/arch/msg/ippm/Do9kJ9ED_grmTqwcZHSdpy3CmRk):
The plan is to consolidate the IOAM-related content for a new "immediate export option" from draft-song-ippm-postcard-based-telemetry-04 and the description of the immediate export flag in draft-mizrahi-ippm-ioam-flags  into a new draft. 

Active flag: 
The active flag is not to replace any existing active OAM mechanisms - but rather allow an operator who uses his own probing along with IOAM to flag a packet as a probe packet. 

Security considerations for flags in the context of PNF vs. VNF:
Thanks for raising the point. It would be great to see specifics/details discussed here on the list, so that those could be incorporated into the security section.

Thanks, Frank

> -----Original Message-----
> From: ippm <ippm-bounces@ietf.org> On Behalf Of Tom Herbert
> Sent: Donnerstag, 1. August 2019 00:41
> To: Greg Mirsky <gregimirsky@gmail.com>
> Cc: IPPM Chairs <ippm-chairs@ietf.org>; IETF IPPM WG <ippm@ietf.org>
> Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re:
> Regarding draft-mizrahi-ippm-ioam-flags
> 
> On Wed, Jul 31, 2019 at 11:53 AM Greg Mirsky <gregimirsky@gmail.com>
> wrote:
> >
> > Dear Authors,
> > thank you for bringing this proposal for the discussion. When considering WG
> AP, I use the following criteria:
> >
> > is the document reasonably well-written; does it addresses a practical
> > problem; is the proposed solution viable?
> >
> > On the first point, I commend you - the draft is easy to read.
> > On the second point, I have several questions:
> >
> > What is the benefit of using Loopback flag in the Trace mode?
> 
> This is unclear to me also. Additionally, I am concerned that protocol blindly
> reflects the packet back to the source without any regard to what else the
> packet contains. For instance, if a TCP packet is reflected by ten intermediate
> nodes this is nonsensical. The possibility of an amplification attack is obvious
> and in fact mentioned in the security section, however I'm skeptical that the
> proposed mitigation of rate limiting is sufficient.
> 
> Minimally, it seems like the reflected packets should be wrapped in ICMP to
> mitigate spoofing attacks. Also, I wonder if traceroute methodology could be
> used for tracing, i.e. one sent packet results in at most one return packet (ICMP),
> to mitigate the amplification problem.
> 
> Tom
> 
> > Why is it important to limit the applicability of Loopback to only Trace mode?
> > What is the benefit of collecting the same, as I understand the description,
> data on the return path to the source?
> > What is the benefit of using Active flag comparing to existing active OAM
> protocols?
> > What is the benefit of using Immediate flag comparing to Postcard-Based
> Telemetry (PBT) proposal?
> >
> > On the third point, I'd appreciate your clarification on these points:
> >
> > In which transports (I find that iOAM encapsulation has been proposed for all
> known transports) you've envisioned to use Loopback flag?
> > The third bullet in Section 5 refers to a replica of the data packet that follows
> the same path as the original packet. What controls that replication?
> > The last paragraph in the Security Consideration section relies on "restricted
> administrative domain" to mitigate the threat of malicious attacks using a
> combination of iOAM extensions. That might be the case when operating in a
> PNF environment, but it is much more challenging to maintain such a trusted
> domain in VNF environment. How can these new security risks be mitigated in a
> VNF environment?
> >
> > Appreciate your consideration and clarifications to my questions.
> >
> > Regards,
> > Greg
> >
> > On Thu, Jul 25, 2019 at 2:07 PM Brian Trammell (IETF) <ietf@trammell.ch>
> wrote:
> >>
> >> hi Greg,
> >>
> >> Thanks for the feedback; absolutely, we can do this the normal way. Authors:
> let's do a normal two-week adoption call for this document before publishing
> the update.
> >>
> >> This adoption call starts now.
> >>
> >> IPPM, please respond to this message with an indication to the mailing list of
> your support for adopting draft-mizrahi-ippm-ioam-flags as a working group
> document, in partial fulfillment of our charter milestone "submit a Standards
> Track draft on inband OAM based measurement methodologies to the IESG"
> (obviously, depending on how many documents we end up sending to the IESG,
> we may have to change the plurality of this milestone). If you do not support
> this, please send a message to the list explaining why.
> >>
> >> Thanks, cheers,
> >>
> >> Brian (as IPPM co-chair)
> >>
> >>
> >> > On 25 Jul 2019, at 13:15, Greg Mirsky <gregimirsky@gmail.com> wrote:
> >> >
> >> > Dear Chairs, et al.,
> >> > I appreciate that editors of draft-ietf-ippm-ioam-data followed on the
> decision of the WG reached at the meeting in Prague to extract material not
> directly related to the definition of iOAM data elements from the document. The
> new draft was presented earlier this week and generated many comments. I feel
> that it would be right to discuss the draft and its relevance to the charter of the
> IPPM WG before starting WG adoption poll.
> >> >
> >> > Regards,
> >> > Greg
> >>
> > _______________________________________________
> > 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