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

I agree that the active management possibility can't be totally excluded. Also, the node doesn't only collect data, but also possibly process the data in order to generate new OAM data. 

I think it's fine to explicitly confine the IOAM into a single domain so the privacy is no longer a concern. This also eliminates many other issues.

Haoyu 

-----Original Message-----
From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 8:21 AM
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>; 'Frank Brockners (fbrockne)' <fbrockne@cisco.com>; 'Tal Mizrahi' <talmi@marvell.com>; 'The IESG' <iesg@ietf.org>
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)

> > 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

_______________________________________________
Ioam mailing list
Ioam@ietf.org
https://www.ietf.org/mailman/listinfo/ioam