Subject: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00

From: <[email-masked]>
Date: Mon, 18 Nov 2019 13:18:08 +0800 (CST)

Hi Frank,

Repeat what I said on the mic this morning as below.

In section 3 of draft-ietf-ippm-ioam-ipv6-options-00 it says:

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

But in section 4.4 of draft-ietf-ippm-ioam-data-08 it says:

"If not all nodes within a domain are IOAM capable, IOAM tracing information (i.e., node data, see below) will only be collected on those nodes which are IOAM capable.  Nodes which are not IOAM capable will forward the packet without any changes to the IOAM-Data-Fields."

It seems they're not in alignment.

Best Regards,

Xiao Min

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 19 Nov 2019 03:47:37 +0000

Hi Xiao,

thanks for following up. Apparently the behavior described in draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we speculated in the IPPM WG meeting yesterday, but the desired behavior that we arrived at after WG discussions in 6man and with several IPv6 experts.  See https://github.com/inband-oam/ietf/commit/48175cf89de6369a4d01017ec80c07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't forward an IOAM packet unless configured to do so.”)
This behavior for IPv6 is to ensure that packets with IOAM do not accidentally leak from a domain that employs IPv6.
This also means for IPv6, things are more constrained than what is stated in the more generic draft-ietf-ippm-ioam-data-08.

Cheers, Frank

From: ippm <[email-masked]> On Behalf Of [email-masked]
Sent: Montag, 18. November 2019 13:18
To: [email-masked]
Subject: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00

Hi Frank,

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

Best Regards,

Xiao Min

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Nov 2019 20:23:49 -0800

> This also means for IPv6, things are more constrained than what is stated in the more generic draft-ietf-ippm-ioam-data-08.
Frank,

Per the draft-ietf-ippm-ioam-ipv6-options-00 the act bits are 00 which
means "skip over this option and continue processing the header". So
if a router doesn't support IOAM, I believe other act bits like maybe
01 would be necessary to enforce the rule of “Don't forward an IOAM
packet unless configured to do so.” Of course, nodes may also ignore
HBH options completely per RFC8200 which means even such packets might
be forwarded out of the domain anyway. So trying to guarantee packets
won't be forwarded out of the domain at all edge routers may be a
futile effort. An alternative would be that the source SHOULD only use
IOAM when it knows the destination is in the domain, and a firewall
MAY be applied at the domain edge to drop packets with IOAM.

Tom

> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 19 Nov 2019 04:49:40 +0000

Tom,

> -----Original Message-----
> From: Tom Herbert <[email-masked]>
> Sent: Dienstag, 19. November 2019 12:24
> To: Frank Brockners (fbrockne) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> 
> > thanks for following up. Apparently the behavior described in
> > draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we speculated in
> > the IPPM WG meeting yesterday, but the desired behavior that we
> > arrived at after WG discussions in 6man and with several IPv6 experts.
> > See
> > https://github.com/inband-
> oam/ietf/commit/48175cf89de6369a4d01017ec80c
> > 07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't forward an
> > IOAM packet unless configured to do so.”)
> >
> > This also means for IPv6, things are more constrained than what is stated in
> the more generic draft-ietf-ippm-ioam-data-08.
> >
> Frank,
> 
> Per the draft-ietf-ippm-ioam-ipv6-options-00 the act bits are 00 which means
> "skip over this option and continue processing the header". So if a router doesn't
> support IOAM, I believe other act bits like maybe
> 01 would be necessary to enforce the rule of “Don't forward an IOAM packet
> unless configured to do so.” Of course, nodes may also ignore HBH options
> completely per RFC8200 which means even such packets might be forwarded
> out of the domain anyway. 

...  the current text is a for a more specific case, i.e. you have a router that *does* understand IOAM and receives a packet with IOAM on an interface that is not configured for IOAM. 
The conclusion from earlier discussions was to drop the packet - per the current text. This leaves default processing of unknown option types untouched - i.e. processing would happen per RFC 8200.

Frank

So trying to guarantee packets won't be forwarded
> out of the domain at all edge routers may be a futile effort. An alternative would
> be that the source SHOULD only use IOAM when it knows the destination is in
> the domain, and a firewall MAY be applied at the domain edge to drop packets
> with IOAM.
> 
> Tom
> 
> >
> >
> > Cheers, Frank
> >
> >
> >
> >
> >
> >
> >
> > "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."
> >
> > "If not all nodes within a domain are IOAM capable, IOAM tracing information
> (i.e., node data, see below) will only be collected on those nodes which are
> IOAM capable.  Nodes which are not IOAM capable will forward the packet
> without any changes to the IOAM-Data-Fields."
> >

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Nov 2019 07:51:57 -0800

> ...  the current text is a for a more specific case, i.e. you have a router that *does* understand IOAM and receives a packet with IOAM on an interface that is not configured for IOAM.

But the draft says "This ensures that IOAM data does not
unintentionally get forwarded outside the IOAM domain.", these
requirements don't do that.

I see another issue, the option may be in a Destination Options
header. So in order for a router to detect presence of the IOAM option
it would need to examine the Desintation Option while the packet is
inflight, but that prohibited by RFC8200: "Extension headers (except
for the Hop-by-Hop Options header) are not processed, inserted, or
deleted by any node along a packet's delivery path..."

> The conclusion from earlier discussions was to drop the packet - per the current text. This leaves default processing of unknown option types untouched - i.e. processing would happen per RFC 8200.

Yes, packet should be dropped at the domain edege, but that is a
firewall functionality not router functionality. If we start adding
requirements to routers to drop traffic on the basis of inspecting
content not normally required for routing, then this will create a
avalanche of router requirements for each type of limited domain.
Clearly packets with SRH need to be dropped at edge, as do packets
with private addresses, and there will no doubt be other cases. All of
these fall under the auspices of firewalls at the edge of the domain,
not routers within the domain. Segement rouitng handles this properly
as filtering packets with SRH at edge is required.

Tom

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 19 Nov 2019 23:51:48 +0000

Tom,

> Sent: Dienstag, 19. November 2019 23:52
> > > > draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we
> > > > speculated in the IPPM WG meeting yesterday, but the desired
> > > > behavior that we arrived at after WG discussions in 6man and with several
> IPv6 experts.
> > > > See
> > > > 07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't forward
> > > > an IOAM packet unless configured to do so.”)
> > > >
> > > > This behavior for IPv6 is to ensure that packets with IOAM do not
> > > > accidentally
> > > leak from a domain that employs IPv6.
> > > >
> > > Per the draft-ietf-ippm-ioam-ipv6-options-00 the act bits are 00
> > > which means "skip over this option and continue processing the
> > > header". So if a router doesn't support IOAM, I believe other act
> > > bits like maybe
> > > HBH options completely per RFC8200 which means even such packets
> > > might be forwarded out of the domain anyway.
> >
> > ...  the current text is a for a more specific case, i.e. you have a router that
> *does* understand IOAM and receives a packet with IOAM on an interface that
> is not configured for IOAM.
> 
> But the draft says "This ensures that IOAM data does not unintentionally get
> forwarded outside the IOAM domain.", these requirements don't do that.

... FB: If everything is properly setup, packets with IOAM data fields should never leave the IOAM domain. 
Having a default of "drop" with the need to explicitly configure an "allow" reduces the potential of errors.
Which means we should soften the statement, given that it does not "ensure" that bad things don't happen - but it does try to help avoid bad things happening.

> 
> I see another issue, the option may be in a Destination Options header. So in
> order for a router to detect presence of the IOAM option it would need to
> examine the Desintation Option while the packet is inflight, but that prohibited
> by RFC8200: "Extension headers (except for the Hop-by-Hop Options header) are
> not processed, inserted, or deleted by any node along a packet's delivery
> path..."

...FB: Hmmm - I'm not following. Why would a router (i.e. transit node) look at DO? The text does not say that anywhere. 
If you are an IOAM encap/decap node (host or tunnel endpoint), you'd deal with DO and HbyH - and the text means: Ignore those on interfaces which aren't enabled for IOAM.
If you are an IOAM transit node, you'd deal with HbyH - and the text again means: Ignore those on interfaces which aren't enabled for IOAM.

> 
> > The conclusion from earlier discussions was to drop the packet - per the
> current text. This leaves default processing of unknown option types untouched
> - i.e. processing would happen per RFC 8200.
> 
> Yes, packet should be dropped at the domain edege, but that is a firewall
> functionality not router functionality. If we start adding requirements to routers
> to drop traffic on the basis of inspecting content not normally required for
> routing, then this will create a avalanche of router requirements for each type of
> limited domain.

...FB: Per what I said above, we don't ask the router to inspect anything that the router would look at in any case.
If you believe that the behavior of "explicitly enable an interface for IOAM" - i.e. ask for explicit config - does not add any benefits, and others feel the same way, we can drop that requirement from the spec again. It adds to configuration complexity - so unless we feel it adds a benefit, we should get rid of it. The earlier conversation we had on the topic concluded that it would add a benefit - which is why the text is there.

Cheers, Frank

> Clearly packets with SRH need to be dropped at edge, as do packets with private
> addresses, and there will no doubt be other cases. All of these fall under the
> auspices of firewalls at the edge of the domain, not routers within the domain.
> Segement rouitng handles this properly as filtering packets with SRH at edge is
> required.
> 
> Tom
> 
> 
> >
> > Frank
> >
> >
> > > out of the domain at all edge routers may be a futile effort. An
> > > alternative would be that the source SHOULD only use IOAM when it
> > > knows the destination is in the domain, and a firewall MAY be
> > > applied at the domain edge to drop packets with IOAM.
> > >
> > > Tom
> > >
> > > >
> > > >
> > > > Cheers, Frank
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> configured)
> > > for IOAM, a router MUST drop packets which contain extension headers
> > > carrying IOAM data-fields."
> > > >
> > > (i.e., node data, see below) will only be collected on those nodes
> > > which are IOAM capable.  Nodes which are not IOAM capable will
> > > forward the packet without any changes to the IOAM-Data-Fields."
> > > >

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Nov 2019 16:17:04 -0800

Frank,

If everything were set up correctly one would expect that the source
would only set IOAM in the packet if it knows that the destination is
in the domain. From that POV the purpose of an egress firewall is to
protect against misconfiguration or bugs.

> Which means we should soften the statement, given that it does not "ensure" that bad things don't happen - but it does try to help avoid bad things happening.

An explicit firewall at the edge could just as easily and more
completely enforce the isolation. Per the current draft requirements,
even non-edge routers need to act as firewalls for IOAM.

> ...FB: Hmmm - I'm not following. Why would a router (i.e. transit node) look at DO? The text does not say that anywhere.

Per the draft: "IOAM data fields are encapsulated in "option data"
fields of two types of extension headers in IPv6 packets - either
Hop-by-Hop Options header or Destination options header."

-and-

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

Putting these two statements together means that a router MUST drop
packets with a Destination Options header that carried IOAM
data-fields regardless of whether the packet is addressed to the
router. If the intent is that the router only drops for HBH then the
requirement should read "...a router MUST drop packets which contain a
Hop-by-Hop extension header carrying IOAM data-fields."

Tom

---

From: <[email-masked]>
Date: Wed, 20 Nov 2019 10:38:56 +0800 (CST)

Hi Frank,

Now I understand the intention behind the text, you might need to rephrase the text, when it says "a router MUST drop packets..." it really means "an IOAM capable router MUST drop packets...".

BTW, I didn't see it as a bug from the beginning, I just raised it as an inconsistency between the two drafts for you to clarify.

Best Regards,

Xiao Min

原始邮件

发件人：FrankBrockners(fbrockne) <[email-masked]>
收件人：肖敏10093570;[email-masked] <[email-masked]>;
日 期 ：2019年11月19日 11:47
主 题 ：RE: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00

Hi Xiao,

thanks for following up. Apparently the behavior described in draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we speculated in the IPPM WG meeting yesterday, but the desired behavior that we arrived at after WG discussions in 6man
 and with several IPv6 experts.  See https://github.com/inband-oam/ietf/commit/48175cf89de6369a4d01017ec80c07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't forward an IOAM packet unless configured to do so.”)

 

Cheers, Frank

 

 

Hi Frank,

Best Regards,

Xiao Min

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 20 Nov 2019 02:39:40 +0000

Tom,

> Sent: Mittwoch, 20. November 2019 08:17
> > > > > > 07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't
> > > > > > forward an IOAM packet unless configured to do so.”)
> > > > > >
> > > > > > This behavior for IPv6 is to ensure that packets with IOAM do
> > > > > > not accidentally
> > > > > header". So if a router doesn't support IOAM, I believe other
> > > > > act bits like maybe
> > > > > 01 would be necessary to enforce the rule of “Don't forward an
> > > > > IOAM packet unless configured to do so.” Of course, nodes may
> > > > > also ignore HBH options completely per RFC8200 which means even
> > > > > such packets might be forwarded out of the domain anyway.
> > > >
> > > *does* understand IOAM and receives a packet with IOAM on an
> > > interface that is not configured for IOAM.
> > >
> If everything were set up correctly one would expect that the source would only
> set IOAM in the packet if it knows that the destination is in the domain. From
> that POV the purpose of an egress firewall is to protect against misconfiguration
> or bugs.
> 
> > Which means we should soften the statement, given that it does not "ensure"
> that bad things don't happen - but it does try to help avoid bad things happening.
> 
> An explicit firewall at the edge could just as easily and more completely enforce
> the isolation. Per the current draft requirements, even non-edge routers need to
> act as firewalls for IOAM.

... not sure whether I'd call the function "drop packets of a specific type unless configured to accept them" a firewall.
Would you call a router that drops v6 on an interface unless explicitly configured to forward v6 on an interface a firewall?
Anyway - I think we agree on what behavior we refer to, hence no need to argue nomenclature.

> > > header. So in order for a router to detect presence of the IOAM
> > > option it would need to examine the Desintation Option while the
> > > packet is inflight, but that prohibited by RFC8200: "Extension
> > > headers (except for the Hop-by-Hop Options header) are not
> > > processed, inserted, or deleted by any node along a packet's delivery path..."
> >
> fields of two types of extension headers in IPv6 packets - either Hop-by-Hop
> Options header or Destination options header."
> 
> -and-
> 
> Putting these two statements together means that a router MUST drop packets
> with a Destination Options header that carried IOAM data-fields regardless of
> whether the packet is addressed to the router. If the intent is that the router
> only drops for HBH then the requirement should read "...a router MUST drop
> packets which contain a Hop-by-Hop extension header carrying IOAM data-
> fields."

... point taken. We'll improve the language in the next revision to ensure that things cannot be misread - which is why the whole discussion started here in the first place.

Thanks, Frank
> 
> Tom
> 
> > If you are an IOAM encap/decap node (host or tunnel endpoint), you'd deal
> with DO and HbyH - and the text means: Ignore those on interfaces which aren't
> enabled for IOAM.
> > If you are an IOAM transit node, you'd deal with HbyH - and the text again
> means: Ignore those on interfaces which aren't enabled for IOAM.
> >
> > >
> > If you believe that the behavior of "explicitly enable an interface for IOAM" -
> i.e. ask for explicit config - does not add any benefits, and others feel the same
> way, we can drop that requirement from the spec again. It adds to configuration
> complexity - so unless we feel it adds a benefit, we should get rid of it. The
> earlier conversation we had on the topic concluded that it would add a benefit -
> which is why the text is there.
> >
> > Cheers, Frank
> >
> > > with private addresses, and there will no doubt be other cases. All
> > > of these fall under the auspices of firewalls at the edge of the domain, not
> routers within the domain.
> > > Segement rouitng handles this properly as filtering packets with SRH
> > > at edge is required.
> > >
> > > Tom
> > >
> > >
> > > >
> > > > Frank
> > > >
> > > >
> > > > > alternative would be that the source SHOULD only use IOAM when
> > > > > it knows the destination is in the domain, and a firewall MAY be
> > > > > for IOAM, a router MUST drop packets which contain extension
> > > > > headers carrying IOAM data-fields."
> > > > > >
> > > > > (i.e., node data, see below) will only be collected on those
> > > > > nodes which are IOAM capable.  Nodes which are not IOAM capable
> > > > > will forward the packet without any changes to the IOAM-Data-Fields."
> > > > > >