Re: [Ioam] Internal WG Review: In-situ OAM (ioam)

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 14 February 2017 09:57 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ioam@ietfa.amsl.com
Delivered-To: ioam@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98321298AA; Tue, 14 Feb 2017 01:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 vY1ppt-Up62B; Tue, 14 Feb 2017 01:57:32 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F86B1294C4; Tue, 14 Feb 2017 01:57:31 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1E9vOp6030405; Tue, 14 Feb 2017 09:57:25 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1E9vKg0030337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2017 09:57:23 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Stewart Bryant' <stewart.bryant@gmail.com>, "'Carlos Pignataro (cpignata)'" <cpignata@cisco.com>
References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> <E23424A5-D78F-4680-B542-34CD6BC59862@cisco.com> <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> <0be201d283ae$1b120680$51361380$@olddog.co.uk> <245E4E88-DBE4-49E5-A05E-EB46C0BF2928@cisco.com> <53a1587f-1f2a-d10e-9b96-6b8c539328c5@gmail.com>
In-Reply-To: <53a1587f-1f2a-d10e-9b96-6b8c539328c5@gmail.com>
Date: Tue, 14 Feb 2017 09:57:19 -0000
Message-ID: <02fd01d286a8$bde38d00$39aaa700$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHPa9VlOQLpUKVlo/4ITVNuqPkWhAIITfo/Aao35ZECviEHQQIHsdB5AwVAxu8Cj3a96aD+D7MQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22884.006
X-TM-AS-Result: No--23.093-10.0-31-10
X-imss-scan-details: No--23.093-10.0-31-10
X-TMASE-MatchedRID: 9d2LtCNB3NJNlZ1zEcyAY4+YSzwl92XTXs5nqGvDCfOsVbcspinhtPOU uGB9RLG7sX8sN4WYnypiwHPBw2/v6i0M1J9+iCGWtLDu9qtqKeHqLDg4PiQdIykRn4qIywauKKD m6CPX8N7CP+Q6V63q3dNAQopQUNi6NdyCBd6LtFfcWo5Vvs8MQrd2noO4P7rALraGNlLRahivmp qFRV6sXIwWUgJWbP/q4c4eZs1WD75R2cR2TyQKnkhEDfw/93BuLAnNohUyMa2qk1pNnRLcWnkd7 fgSbdRZAhfygQKSgZpGTZylE32TfRxasQ/5XsrIiWatZUOj6OsvNM1bSrP4J5jk0EbtghtXPDE1 dnzqe9j+4JIhj1N/fgqyGvL90r7X7VzWdf1uCr/TbR5agAsD11AsQ+5PgsP5nvbaEOoeixN9qTN wMiKD+ise7faAfC+J1yyUtQ8ZyaE28LK855iUimiYls8x2M90tB3OND1JunKbKItl61J/ybLn+0 Vm71Lcq7rFUcuGp/GsWV0bdkf4OQSTC8t6yZ3k
Archived-At: <https://mailarchive.ietf.org/arch/msg/ioam/ZI-VaVr7PyyAuVoxSMb_wDEkcA4>
Cc: "'Alvaro Retana (aretana)'" <aretana@cisco.com>, ioam@ietf.org, 'The IESG' <iesg@ietf.org>, 'The IAB' <iab@iab.org>, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>
Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
X-BeenThere: ioam@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion on In-Situ OAM <ioam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ioam>, <mailto:ioam-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ioam/>
List-Post: <mailto:ioam@ietf.org>
List-Help: <mailto:ioam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ioam>, <mailto:ioam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 09:57:33 -0000

My concern was about use of the in-situ OAM container for non-OAM purposes. Such as, to allow an application to coordinate the use of the payload data.

Pending a conversation about whether that would be smart or stupid, I think that any in-situ OAM mechanism needs to be carefully ringed around with words that say what uses are unacceptable, and probably also words that carefully define where in-situ OAM bytes are and are not allowed to be added.

I think we probably have (albeit implicit?) that in-situ OAM bytes are not allowed to enter the domain. We should probably also have that they can only be added/modified by "OAM applications" and not "data sources". However, thin end of wedge? Will an application (perhaps a VoIP application) not consider it legitimate to add in-situ OAM to get feedback on the behavior of the network for its voice calls? And if so, that opens the gates for any application to use in-situ OAM, and *that* opens the possibility of two end-point applications using the in-situ OAM mechanism to talk about *anything*.

Adrian

> -----Original Message-----
> From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
> Sent: 14 February 2017 09:45
> To: Carlos Pignataro (cpignata); Adrian Farrel
> Cc: Alvaro Retana (aretana); ioam@ietf.org; The IESG; The IAB; Stephen Farrell
> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
> 
> 
> 
> On 10/02/2017 15:19, Carlos Pignataro (cpignata) wrote:
> >> On Feb 10, 2017, at 9:58 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> >>
> >>>>> 1) I'm sure there are good things one can do with such
> >>>>> marking, but it is very unclear to me how this proposal
> >>>>> doesn't also fall afoul of all the privacy downsides of
> >>>>> the SPUD/PLUS proposal. My understanding of those privacy
> >>>>> downsides was that any generic/extensible marking scheme
> >>>>> (whether of packets or transport connections/flows) could
> >>>>> easily be abused in many privacy unfriendly ways. Note
> >>>>> that I'm not claiming there is IETF consensus on that
> >>>>> but I do claim it was a significant issue for SPUD/PLUS
> >>>>> and would like to know why (and hope) it is not an issue
> >>>>> here. Can someone help me understand what's different here
> >>>>> so we avoid that same kind of mega-debate?
> >>> Note that this proposal concerns itself with OAM information, and not as a
> >>> generic container for all-things. It is not for application information.
> >> Hmmm.
> >> Once you define a channel to carry other stuff along with data packets it will
> be used for purposes as yet undreamed of.
> > I understand that — which is true pretty much for any new protocol field.
> >
> > I was curious to see if there were more specifics on the PLUS discussion beyond
> this that particularly apply to IOAM.
> 
> Adrian is correct here, but short of a breakthrough in cryptography that
> allows the use of  homomorphic encryption at speed with small payloads,
> we sit on the horns of a dilemma between enhancing the legitimate
> observability of a network for management purposes and enhancing the
> observability for nefarious purposes. Perhaps the answer is to require
> all phys to include encryption?
> 
> Stewart