On 2018-12-06 11:50, Joe Touch wrote: > > >> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: >> >>> On 2018-12-06 01:16, Joe Touch wrote: >>> >>> >>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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 >>> . >>> >> > >
