On Wed, Dec 5, 2018 at 11:57 PM Joe Touch <touch@xxxxxxxxxxxxxx> wrote:
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.
How is it, for example, different to put ipv6 packets into an MPLS path doing nothing along 'many' hops (except forwarding the packets along), and then once you pop out of the tunnel start processing the packet as you (joe) would want.
Versus just ignoring the offensive EHs along the same path outside of MPLS and then dealing with them after you pop out the last router in the chain?
In my mind this is what Brian (and me and apparently 8200) are proposing: "edge site sends packet with offensive header(s) to ISP, ISP ignores EHs and forwards across (potentially many) routers/as-hops and far end edge site gets the packet and parses EHs to it's hearts content."
> On Dec 5, 2018, at 4:38 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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 <brian.e.carpenter@xxxxxxxxx> wrote:
>>>>
>>>> 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
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
