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

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/02/17 14:23, Frank Brockners (fbrockne) wrote:
> Stephen,
> 
> 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:-)

> I.e. IOAM is
> for operations support *not* for active management of nodes. 

That sounds good, but I think needs to be clearer.

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

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

I don't get how it won't be possible - if you're considering
anything extensible, what'd prevent someone defining such an
extension later?

Cheers,
S.

> 
> Cheers, Frank
> 
> -----Original Message----- From: Ioam [mailto:[e-mail]]
> On Behalf Of Stephen Farrell Sent: Mittwoch, 15. Februar 2017 15:10 
> To: Tal Mizrahi <[e-mail]>; The IESG <[e-mail]> Cc:
> [e-mail]; [e-mail] 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:[e-mail]] On Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 15, 2017 2:09 PM To: The IESG Cc: 
>>> [e-mail]; [e-mail] 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 [e-mail] 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
>>>  [e-mail] https://www.ietf.org/mailman/listinfo/ioam
>> 
>