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. > On Dec 5, 2018, at 4:38 PM, Brian E Carpenter <[email protected]> > 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 >>>> <[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
