Re: [Tsv-art] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

[Christopher Morrow <[e-mail]>]

On Wed, Dec 5, 2018 at 11:57 PM Joe Touch <[e-mail]> wrote:

> Then explain what it means to mark an EH as ‘drop if not supported’ if it
> isn’t dropped where - well - NOT SUPPORTED.
>
> Or ICMP where not supported.
>
> Or any of those values.
>
> I’m talking about a conflict in the text of 8200 - which has those fields
> as required to support - and 7045, which says they can be silently ignored.
>
>
How is it, for example, different to put ipv6 packets into an MPLS path
doing nothing along 'many' hops (except forwarding the packets along), and
then once you pop out of the tunnel start processing the packet as you
(joe) would want.

Versus just ignoring the offensive EHs along the same path outside of MPLS
and then dealing with them after you pop out the last router in the chain?

In my mind this is what Brian (and me and apparently 8200) are proposing:
"edge site sends packet with offensive header(s) to ISP, ISP ignores EHs
and forwards across (potentially many) routers/as-hops and far end edge
site gets the packet and parses EHs to it's hearts content."


> > On Dec 5, 2018, at 4:38 PM, Brian E Carpenter <
> [e-mail]> wrote:
> >
> >> On 2018-12-06 13:17, Joe Touch wrote:
> >> I am referring to the standards. They’re in direct conflict.
> >
> > I see no conflict between RFC8200 and RFC7045. RFC2460 is obsolete, so
> it doesn't matter.
> >
> >    Brian
> >
> >>
> >>>> On Dec 5, 2018, at 4:05 PM, Brian E Carpenter <
> [e-mail]> wrote:
> >>>>
> >>>> On 2018-12-06 11:50, Joe Touch wrote:
> >>>>
> >>>>
> >>>>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter <
> [e-mail]> wrote:
> >>>>>>
> >>>>>> On 2018-12-06 01:16, Joe Touch wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter <
> [e-mail]> wrote:
> >>>>>>
> >>>>>>>> Nobody deprecated the flags that require HBH options to be
> processed or dropped if not supported.
> >>>>>>>
> >>>>>>> Intentionally. If a forwarding node is transparent to HbH options,
> >>>>>>> it is not looking at those flags. If it is looking at HbH options,
> >>>>>>> it will obey those flags. Why is that a problem?
> >>>>>>
> >>>>>> What exactly does ‘transparent to HbH options mean’ if not ‘not
> supported’?
> >>>>>
> >>>>> It means a forwarding node that uses the exception added by RFC7045
> and simply
> >>>>> doesn't even look for an HbH header. The flag bits are invisible and
> irrelevant
> >>>>> to such a node. The flag bits apply as defined for a forwarding node
> that *does*
> >>>>> process HbH options, so they certainly should not be deprecated
> >>>>
> >>>> Do why bother with “drop if not supported” if not supported can mean
> silently skipped over?
> >>>
> >>> Ah. I assume that you are not referring to RFC7045 + RFC8200 (the
> standards)
> >>> but to
> https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5
> , which is quite nuanced. All I can say is that *if* we are going to issue
> guidance for security-based filtering of HbH headers, that advice seems
> realistic. It does include this:
> >>>  ...  Finally, when
> >>>  packets containing a HBH Options EH are processed in the slow-path,
> >>>  and the underlying platform does not have any mitigation options
> >>>  available for attacks based on these packets, we recommend that such
> >>>  platforms discard packets containing IPv6 HBH Options EHs.
> >>> Frankly I don't think you'd find any operational security practitioner
> who disagrees with this.
> >>>
> >>> Whether we *should* issue guidance for security-based filtering of HbH
> headers is a broader question. All I would say is that if we don't, then
> either somebody else will, or default-deny will remain as the most common
> practice.
> >>>
> >>> Brian
> >>>
> >>>> Or the other variants?
> >>>>
> >>>> They’re now meaningless but required to support. You don’t see the
> contradiction?
> >>>>
> >>>>
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>>>
> >>>>>> In that case, the flags have exactly no meaning anywhere. But
> they’re not deprecated.
> >>>>>>
> >>>>>> That makes no sense at all.
> >>>>>>
> >>>>>> Joe
> >>>>>> .
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>