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

Stephen,

my reading of the draft charter is that IOAM would be focused on gathering data, not interpreting data on network nodes. I.e. IOAM is for operations support *not* for active management of nodes. 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 lack of “control” or “management” should also mitigate a lot of the security concerns for IOAM, because we just gather data, we don’t interpret data or act on data in IOAM.

So on your question: A "ping of death" won't be possible with IOAM .

Cheers, Frank

-----Original Message-----
From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Mittwoch, 15. Februar 2017 15:10
To: 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)

Hiya,

On 15/02/17 14:05, Tal Mizrahi wrote:
> Hi Stephen,
> 
> Minor comment: as in [RFC6291] OAM in our context stands for 
> Operations, Administration, and Maintenance.

Fair enough, thanks.

The question in (3) though stands as to whether the scope includes (the moral equivalent) of a ping of death or not.
Admin vs. Management in the acronym doesn't really impact on that.

Cheers,
S.

> 
> Cheers, Tal.
> 
>> -----Original Message----- From: Ioam [mailto:ioam-bounces@ietf.org] 
>> On Behalf Of Stephen Farrell Sent:
>> Wednesday, February 15, 2017 2:09 PM To: The IESG Cc:
>> ioam@ietf.org; ioam-chairs@ietf.org Subject: [EXT] [Ioam] Stephen 
>> Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and
>> COMMENT)
>> 
>> External Email
>> 
>> ---------------------------------------------------------------------
>> -
>>
>> 
Stephen Farrell has entered the following ballot position for
>> charter-ietf-ioam-00-02: Block
>> 
>> When responding, please keep the subject line intact and reply to all 
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this introductory paragraph, however.)
>> 
>> 
>> 
>> The document, along with other ballot positions, can be found
>> here: https://datatracker.ietf.org/doc/charter-ietf-ioam/
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> -
>>
>> 
BLOCK:
>> ---------------------------------------------------------------------
>> -
>>
>>
>>
>> 
(1) I think we should have a BoF for this. Given the similarities with SPUD/PLUS
>> (see [1] below) just going ahead and chartering this (and in RTG?) 
>> seems to be very badly inconsistent on behalf of the IESG, given the 
>> community concern about at least the meta-data insertion aspects in 
>> common. (And maybe more aspects.)
>> 
>> (2) As with SPUD/PLUS I am very concerned at the potential privacy 
>> (not security) implications of any generic method of injecting 
>> meta-data whether that be into transport layer flows/sessions or at 
>> other layers. I do not see how doing that at any layer that can 
>> potentially span the Internet is different from doing the same thing 
>> at any other layer. I am concerned that there may not in fact be any 
>> acceptable solution for this problem (other than not aiming to allow 
>> any generic encoding), so I think this is something that does need to 
>> be discussed before external review happens. I am not convinced by 
>> the "domain" boundary argument in the charter - such things leak 
>> and/or the concept of "domain" is too ill-defined. A further point 
>> here is that the suggested timeline (data format defined in April 
>> 2017) clearly suggests that the idea here is to define a way to add a 
>> generic TLV structure to any packet, which I think equally clearly 
>> means that all of the privacy issues are relevant.
>> 
>> (3) I assume the "M" in the name is for management. I don't see what 
>> would prevent someone developing a standardised ping of death if that 
>> is the case. (Or actually, possibly many flavours of that.) And 
>> actually that'd probably be inevitable if the "M" is really seriously 
>> meant. I am not sure that we (the IETF) would like that.
>> That makes me wonder if the scope here is at all sufficiently well 
>> defined - is the implication of the name that the proponents want to 
>> be able to do all management functions this way, or just some?
>> If just some, then which, and why is that a good idea?
>> 
>> [1] https://www.ietf.org/proceedings/96/plus.html
>> 
>> 
>> ---------------------------------------------------------------------
>> -
>>
>> 
COMMENT:
>> ---------------------------------------------------------------------
>> -
>>
>>
>>
>> 
- I remain unconvinced that this can go ahead before the IPv6 header processing
>> discussion currently happening on ietf@ietf.org is resolved.
>> 
>> - Were I mostly interested in "transport" issues, I'd be quite 
>> concerned about those as well - there are also things in common 
>> between this and SPUD/PLUS in that respect I figure, though I'm not 
>> anything like expert on that.
>> 
>> 
>> _______________________________________________ Ioam mailing list 
>> Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam
> 