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

On Mon, Nov 18, 2019 at 8:49 PM Frank Brockners (fbrockne)
<fbrockne@cisco.com> wrote:
>
> Tom,
>
>
> > -----Original Message-----
> > From: Tom Herbert <tom@quantonium.net>
> > Sent: Dienstag, 19. November 2019 12:24
> > To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
> > Cc: xiao.min2@zte.com.cn; ippm@ietf.org
> > Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> >
> > On Mon, Nov 18, 2019 at 7:47 PM Frank Brockners (fbrockne)
> > <fbrockne@cisco.com> 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.

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

>
> 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 <ippm-bounces@ietf.org> On Behalf Of xiao.min2@zte.com.cn
> > > Sent: Montag, 18. November 2019 13:18
> > > To: ippm@ietf.org
> > > 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
> > > ippm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ippm