Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03

[Tim Chown <[e-mail]>]

Hi,

> On 4 Oct 2017, at 23:10, Brian E Carpenter <[e-mail]> wrote:
> 
> On 05/10/2017 02:12, Joe Touch wrote:
>> 
>> 
>> On 9/29/2017 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
>>> 
>>> This is to open a two week WGLC
>>> for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03.
>>> 
>> 
>> I do not agree with the claims of this document. It "informationally"
>> advises against support for key IPv6 capabilities and undermines the
>> extensibility of IPv6 by making recommendations about discarding
>> currently unassigned codepoints.
> 
> Here's the problem, Joe. It's a fact of life that many firewalls
> discard a lot of stuff that they shouldn't - that's why we wrote
> RFC 7045 - but in the real world, operators blunder around based
> on folklore and vendors' defaults. We can't change any of that, but
> we can try to issue sensible advice that, overall, will limit the
> resulting breakage. IMHO this document, positioned correctly as
> Informational, will do that: on balance, it makes the world a better
> place.
> 
> I agree with Bob Hinden that a careful review against RFC 8200 is
> essential. I already pointed out one problem (RH0) at
> https://mailarchive.ietf.org/arch/msg/opsec/StjbjvCP9PLC3ssnTKYO6jqFgk0
> and Bob found a problem with Hop-by-Hop.

I think pragmatic Informational (not BCP) advice is useful.

The advice seems to boil down to four categories. I guess it would be interesting to discuss which categories the WG feels are acceptable for publication as an Informational document, and which are problematic. Can we nail down where the issues are?

a) Advice on different EH types

Here, the document advises dropping RH0; all other EH types except HBH are permitted.
For HBH options, the recommended policy depends on the system capability; with h/w support, allow, with only slow path support and no rate limiting capability, consider dropping.
This section seems pragmatic.

b) Advice on unknown EH types

3.5.5 "Intermediate systems should discard packets containing unknown IPv6 EHs.”
This conflicts with Section 2.1 of RFC7045.

c) Advice on different IPv6 options

The advice here is a mixture of recommended drops, and conditional drops.
Recommended drops: SMF_DPD, Endpoint Identification, Line-Identification Option, Deprecated
Conditional: Jumbo Payload, RPL, Router Alert, CALIPSO, IP_DFF, RFC3692-style Experiment 
i.e. if your network doesn’t require those options to function, drop them.
Pragmatic again.

d) Advice on unknown IPv6 options

4.4.5 "Enterprise intermediate systems that process the contents of IPv6 EHs
   should discard packets that contain unknown options.  Other
   intermediate systems that process the contents of IPv6 EHs should
   permit packets that contain unknown options.”

It’s not clear here why the advice is different for enterprise vs intermediate.
And why the recommended unknown IPv6 option policy is different to unknown EH policy.

A summary table for IPv6 options would be useful, as per the EH types.

Saying that, the summary for Routing Header types in the table is not consistent with the advice in the text.

As per Bob and Brian’s comments, alignment with RFC 8200 is a must.

So in general I support pragmatic advice, but there are some open questions and conflicts in the text as it is.

Tim