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

[Joe Touch <[e-mail]>]

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 <[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
>>>>>> .
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>