I am referring to the standards. They’re in direct conflict. > On Dec 5, 2018, at 4:05 PM, Brian E Carpenter <[email protected]> > wrote: > >> On 2018-12-06 11:50, Joe Touch wrote: >> >> >>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter >>>> <[email protected]> wrote: >>>> >>>> On 2018-12-06 01:16, Joe Touch wrote: >>>> >>>> >>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter >>>> <[email protected]> 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 >>>> . >>>> >>> >> >> >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
