Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT)

"Adrian Farrel" <afarrel@juniper.net> Wed, 15 February 2017 16:21 UTC

Return-Path: <afarrel@juniper.net>
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 2F3051295F4; Wed, 15 Feb 2017 08:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.955
X-Spam-Level:
X-Spam-Status: No, score=-1.955 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, SPF_SOFTFAIL=0.665] autolearn=no 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 j1wVdVFnrWU2; Wed, 15 Feb 2017 08:21:47 -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 707D3126579; Wed, 15 Feb 2017 08:21:47 -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 v1FGLfHw029052; Wed, 15 Feb 2017 16:21:41 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FGLNEp028927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 16:21:37 GMT
From: Adrian Farrel <afarrel@juniper.net>
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, "'Frank Brockners (fbrockne)'" <fbrockne@cisco.com>, 'Tal Mizrahi' <talmi@marvell.com>, 'The IESG' <iesg@ietf.org>
References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> <c10463c6506f44c482402ed74a4cbebc@IL-EXCH01.marvell.com> <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> <e6357ddd-3db0-e6bc-1358-b13c6a47589d@cs.tcd.ie>
In-Reply-To: <e6357ddd-3db0-e6bc-1358-b13c6a47589d@cs.tcd.ie>
Date: Wed, 15 Feb 2017 16:21:19 -0000
Message-ID: <072401d287a7$9717c010$c5474030$@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/AZmvTRgxU9TugAJ1Lg+t+WTXxAJAXalPAdu0rPsBbro0KgDLE9ZKoF6Zq6A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22886.007
X-TM-AS-Result: No--29.097-10.0-31-10
X-imss-scan-details: No--29.097-10.0-31-10
X-TMASE-MatchedRID: irl7E//xM97gpJkkN54KBu2z+g9Wb/sXuRiLMrkF73pH4a2iJdV4MQvx MaV6x4s8feHPnu31iHAVJO7iRcm6fMfMjt18MDaZJrjuWtraDtpF+3SPXMw7TOLdprnA5EQR6Jj 6zYvfFARcKZwALwMGs0/C7C10JE7vl0RBptHJuMS6pkTQud6O/22EnshdEio2Dko+EYiDQxHPTY o1Nwkfy+awlruCFTR8T8sRnQxSSqfdTNZM6RI8CWoCJ3XtBZawjlL/hujrw1vcWo5Vvs8MQiqQa lMhs4UB6i5zlFx/UHR3qJ37Ojwrqh2x50UbytBssyjQ53GdiCNqxW9c79DYM9cjCbPZgQnF6Zly P3mazsmLaDxfPEIN++s7USOi3SHK/QhRj4/WQnFpnryVaiXugL9ZdlL8eonaC24oEZ6SpSlND5/ KBbSwnPzffz+WOOti
Archived-At: <https://mailarchive.ietf.org/arch/msg/ioam/89jabOihGuynuWeN66I3eUPAVFE>
Cc: ioam@ietf.org, ioam-chairs@ietf.org
Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT)
X-BeenThere: ioam@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: afarrel@juniper.net
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: Wed, 15 Feb 2017 16:21:49 -0000

> > my reading of the draft charter is that IOAM would be focused on
> > gathering data, not interpreting data on network nodes.
> 
> I'm not clear what distinction you're making there sorry.
> (That's likely my ignorance, so sorry again:-)

Or possibly not your ignorance.
"Focused on" may be the catch.
I think it unlikely that a network node is not going to have to examine some fields of the IOAM data in order to discover what it is supposed to do (add an address, add a time stamp, send a response), and also I should expect it has to parse a bit to work out where to place any information that it adds to the data.

Furthermore, I suspect that it is only a matter of time before it is recognised that IOAM provides a cannel that can be used to configure and enable/disable OAM (noting that such a mechanism was found to be useful in MPLS and that it is improbable that a second channel - in addition to the IOAM channel - would be opened for OAM control mechanisms).

> > I.e. IOAM is
> > for operations support *not* for active management of nodes.
> 
> That sounds good, but I think needs to be clearer.

Like I say, I wouldn't put money on that remaining the case. So even if the charter explicitly forbids active management of (OAM on) the nodes, at some point there will need to be a recharter. Given that, you might do well to recognise the fact up front.

> > This is
> > also why SPUD/PLUS are probably orthogonal/complementary, because I
> > understand those approaches as targeting the communication between
> > end-system and middle-boxes for control/management purposes.
> 
> The similarity to SPUD/PLUS mainly affects privacy and not the
> ping-of-death question. Once one can add any label with enough
> bits in it to a packet then the privacy issues arise.

It may help to give an example or two of where the privacy issue arises.
For example, knowing the path of packets in a network is (possibly) a privacy issue for the owner of the network, but more likely it is a security issue. Is knowledge of the path of the packets a privacy issue for the end-user? I don't think so, but maybe it would open up information about src/dst pairs and so disclose something?
But the IOAM proponents are likely to answer that IOAM is "strictly confined within a domain" and so the information is not visible outside the network *except* as reported by subverted nodes or by network sniffers. It seems to me that there is remarkably little protection available against subverted nodes (maybe every node has to have its own SA with every OAM MEP?), but that sniffers could be thwarted.

Adrian