Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-options-02

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 29 Jul 2020 10:16:02 +0000

Hi Tom,

Thanks for spotting this issue - and sorry for the late follow up (I've been on PTO).
We'll touch on the issue in the IPPM WG meeting on Friday - because the problem still exist in draft-ietf-ippm-ioam-ipv6-options-01 - which is the WG adopted version of the document that you were citing. 

In short, the paragraph that you are referring to below (i.e. the one that starts with "In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly...") is really a left-over from early discussions about how to address the concern that packets with IOAM extension headers could "leak" from an IOAM domain. With the details about IOAM deployment with IPv6 spelled out (in draft-ioametal-ippm-6man-ioam-ipv6-deployment-03) this paragraph is no longer needed and the proposal is to just remove it. The contradicting behavior of this paragraph with the 2 highest order bits of IOAM IPv6 option types would thus be naturally resolved.

Background: draft-ioametal-ippm-6man-ioam-ipv6-deployment-03 details two possible deployment options for IOAM with IPv6: 
1) IOAM domains bounded by hosts
2) IOAM domains bounded by network devices - with the following variants: (2.1) IPv6-in-IPv6 encapsulation, (2.2) IP-in-IPv6 encapsulation with ULA, (2.3) x-in-IPv6 encapsulation that is used Independently
As such, the encapsulation with another IPv6 header (that then carries IOAM extension headers) ensures that packets with IOAM option types will always stay within the IOAM domain. 

Cheers, Frank

> -----Original Message-----
> From: ippm <[email-masked]> On Behalf Of Tom Herbert
> Sent: Freitag, 26. Juni 2020 16:49
> To: IETF IPPM WG <[email-masked]>; Justin Iurman <[email-masked]>
> Subject: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-options-02
> 
> Some comments from section #3
> 
> >From the draft: "In order for IOAM to work in IPv6 networks, IOAM MUST
> be explicitly enabled per interface on every node within the IOAM domain."
> 
> Why this requirement? What if the user wants to only measure a few routers or
> perform an incremental deployment of IOAM. If they don't follow this
> requirement then what breaks?
> 
> >From the draft: "Unless a particular interface is explicitly enabled
> (i.e. explicitly configured) for IOAM, a router MUST drop packets which contain
> extension headers carrying IOAM data-fields. This is the default behavior and is
> independent of whether the Hop-by-Hop options or Destination options are
> used to encode the IOAM data."
> 
> But later in the draft the option types are defined with ack bits as zeroes. From
> RFC8200 this means: "00 - skip over this option and continue processing the
> header.". So there's a contradiction here. If a legacy router, one that doesn't
> implement IOAM, sees a packet with the options it will skip the TLV and continue
> to process per the requirements of RFC8200. Either the option type needs to use
> non-zero act bits or the above requirement needs to be relaxed (I would prefer
> changing the requirement to skip the option especially if HBH are used).
> 
> >From the draft: "This ensures that IOAM data does not unintentionally
> get forwarded outside the IOAM domain."
> 
> I don't think it does. Consider that a packet containing the IOAM option in
> Destination Options arrives at a border router of the domain. If the packet
> destination is outside the domain, the border router will only process the Hop-
> by-Hop options and doesn't look at the Destination Options so the IOAM will
> leak. This would also assume that all border routers either support IOAM or drop
> packet which as shown above isn't met but the current requirements of the
> draft.
> 
> Leakage prevention of protocols out of a domain is a common issue. It is in the
> realm of firewalls, not the individual protocols to best support that. Please look
> at section RFC8754 which describes the necessary filtering of SRH packets to
> contain them within a segment routing domain.
> 
> Tom
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm