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

[Tom Herbert <[e-mail]>]

On Tue, Nov 19, 2019 at 3:51 PM Frank Brockners (fbrockne)
<[e-mail]> wrote:
>
> Tom,
>
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Dienstag, 19. November 2019 23:52
> > To: Frank Brockners (fbrockne) <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> >
> > On Mon, Nov 18, 2019 at 8:49 PM Frank Brockners (fbrockne)
> > <[e-mail]> wrote:
> > >
> > > Tom,
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tom Herbert <[e-mail]>
> > > > Sent: Dienstag, 19. November 2019 12:24
> > > > To: Frank Brockners (fbrockne) <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> > > >
> > > > On Mon, Nov 18, 2019 at 7:47 PM Frank Brockners (fbrockne)
> > > > <[e-mail]> wrote:
> > > > >
> > > > > 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/48175cf89de6369a4d01017ec80c
> > > > > 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.
> > > > >
> > > > > 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.
> >
> > 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.

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.

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

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.

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

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

> 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
> > >
> > >
> > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: ippm <[e-mail]> On Behalf Of
> > > > > [e-mail]
> > > > > Sent: Montag, 18. November 2019 13:18
> > > > > To: [e-mail]
> > > > > Subject: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > > _______________________________________________
> > > > > ippm mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/ippm