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
