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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 15 Feb 2017 04:08:32 -0800

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
[email-masked] 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.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 15 Feb 2017 14:05:28 +0000

Hi Stephen,

Minor comment: as in [RFC6291] OAM in our context stands for Operations, Administration, and Maintenance.

Cheers,
Tal.

>-----Original Message-----
>From: Ioam [mailto:[email-masked]] On Behalf Of Stephen Farrell
>Sent: Wednesday, February 15, 2017 2:09 PM
>To: The IESG
>Cc: [email-masked]; [email-masked]
>Subject: [EXT] [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with
>BLOCK and COMMENT)
>
>External Email
>
>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.)
>
>
>
>(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?
>
>- I remain unconvinced that this can go ahead before the IPv6 header processing
>discussion currently happening on [email-masked] 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ioam

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2017 14:10:01 +0000

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:[email-masked]] On Behalf Of Stephen Farrell Sent:
>> Wednesday, February 15, 2017 2:09 PM To: The IESG Cc:
>> [email-masked]; [email-masked] Subject: [EXT] [Ioam] Stephen
>> Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and
>> COMMENT)
>> 
>> External Email
>> 
>> 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/
>> 
>> 
>> 
(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?
>> 
- I remain unconvinced that this can go ahead before the IPv6 header
processing
>> 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 
>> [email-masked] https://www.ietf.org/mailman/listinfo/ioam
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 15 Feb 2017 14:23:36 +0000

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:[email-masked]] On Behalf Of Stephen Farrell
Sent: Mittwoch, 15. Februar 2017 15:10
To: Tal Mizrahi <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT)

Hiya,

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:[email-masked]] 
>> On Behalf Of Stephen Farrell Sent:
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this introductory paragraph, however.)
>> 
>> 
>> 
>> seems to be very badly inconsistent on behalf of the IESG, given the 
>> community concern about at least the meta-data insertion aspects in 
>> 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.
>> defined - is the implication of the name that the proponents want to 
>> be able to do all management functions this way, or just some?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2017 14:33:00 +0000

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

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.

> On Behalf Of Stephen Farrell Sent: Mittwoch, 15. Februar 2017 15:10 
> To: Tal Mizrahi <[email-masked]>; The IESG <[email-masked]> Cc:
> [email-masked]; [email-masked] Subject: Re: [Ioam] [EXT] Stephen
> Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT)
> 
> 
> Hiya,
> 
> 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.
>> 
>>> [mailto:[email-masked]] On Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 15, 2017 2:09 PM To: The IESG Cc: 
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>> all email addresses included in the To and CC lines. (Feel free
>>> to cut this introductory paragraph, however.)
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>> 
>>> 
> BLOCK:
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>> (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.)
>>> 
>>> 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
>>> 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?
>>> 
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>> 
>>> 
> COMMENT:
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>> between this and SPUD/PLUS in that respect I figure, though I'm
>>> not anything like expert on that.
>>> 
>>>

---

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 15 Feb 2017 15:54:24 +0000

Hi Stephen,

> common. (And maybe more aspects.)

SPUD is targetting a different layer and the problem scope for SPUD is 
very different than for IOAM. IOAM does not target to be a signalling 
mechanism as such, and its scope is on the internet layer and lower data 
plane encapsulations (below the path layer in that PLUS proposal). It is 
also not a bidirectional mechanism. Details in the charter to make this 
clear would help.

> different from doing the same thing at any other layer.

It seems that a clarification of scope would be needed here - IOAM does 
not plan to address the end to end internet operation. It is targetted 
to a controlled environment typically under single administrative 
control, typically having clear edge boundaries, and typically 
constrained to a single data plane encapsulation domain (an example - 
data center fabric), and dealing with gathering of the operational 
packet level and network element operation data of that particular 
domain. While it may be used in a broader end to end network scope that 
at least is not the intention.

> I am
> ill-defined.

It certainly is possible to extend the IOAM domain, the leaking aspect 
is a more difficult one as proper IOAM operation needs explicit support 
of it by the network elements. Not saying that is impossible to happen. 
Again, a more detailed scope description needs to be added to the charter.

>   A further point here is that the suggested

Privacy issues are certainly relevant from the perspective of being able 
to see the recorded IOAM information. As for the TLVs, the preference 
from hardware implementation side is to have fixed field structures and 
not full TLVs. It is certainly possible (and likely) to have full TLV 
encodings, the important note is on the consumers of such packets - IOAM 
data is not expected to reach end systems for which the packets carrying 
IOAM are destined, it is removed at the boundary of the IOAM domain.

> which, and why is that a good idea?

The goal of IOAM is not to define a universal all purpose manageability 
mechanism for all use cases. It is trying to address the limitations of 
having to inject separate OAM packets and try to deal with multiple 
paths, heuristics of network elements in trying to find out what payload 
type it is, and using exactly the path taken by the data packets, and 
not the possible approximation of the path by the injected OAM packets.

> [email-masked] is resolved.

Yes, that is important dependency. One option is to continue IOAM work 
on non-IPv6 based data planes and tunnelling mechanisms first and wait 
for IPv6 header discussion to come to a result.

> though I'm not anything like expert on that.
IOAM is not a transport protocol as such - there is no end to end 
channel between the end systems, there is no end to end channel within 
the IOAM domain too - it is a unidirectional path metadata collection 
mechanism.

Thank you for the comments - they identify the areas that need to be 
clarified in the charter.

Ignas

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Feb 2017 16:21:19 -0000

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

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

> 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

---

From: Haoyu song <[email-masked]>
Date: Wed, 15 Feb 2017 19:41:08 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 8:21 AM
To: 'Stephen Farrell' <[email-masked]>; 'Frank Brockners (fbrockne)' <[email-masked]>; 'Tal Mizrahi' <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT)

> ping-of-death question. Once one can add any label with enough bits in 
> it to a packet then the privacy issues arise.

Adrian