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

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 06:12:03 -0700

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.

This is an overstep for an OPS group, IMO.

Additionally, it refers to RFC2119 without taking care to capitalize
those keywords where used or to provide specific examples where
recommendations contradict existing Internet standards or are not
definitive (e.g., SHOULDs).

I don't think this document is ready in any way.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Oct 2017 13:36:20 +0000

Hi Joe,

Good to hear from you again! It’s been a while.

I have to disagree with your first statement. The document really is intended to be operational advice and nothing more. I know that because that really was our intent when we wrote the paragraph.

However, I suspect that you objections are much deeper and probably require a wider bandwidth conversation. Let’s chat later this week.

                                                                           Ron
                                                                            \ no hats

From: Joe Touch [mailto:[email-masked]]
Sent: Wednesday, October 4, 2017 9:12 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dopsec-2Dipv6-2Deh-2Dfiltering-2D03&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=w6ehR6tEWxWsAi6UqKPaO2-vlDr5WraZcRu4dMv8o90&s=FbWJlslQstgnVnyNGdY5995KFRwCx4RDtIBQPrOAdj8&e=>.

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.

Additionally, it refers to RFC2119 without taking care to capitalize those keywords where used or to provide specific examples where recommendations contradict existing Internet standards or are not definitive (e.g., SHOULDs).

Joe

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Oct 2017 14:38:22 -0700

I also don’t think this is ready for a w.g. last call.

It doesn’t reference the new version of the IPv6 specification RFC8200.  There were a number of clarifications in RFC8200 regarding extension headers that may require changes in the draft.

For example, Hop by Hop headers are now a “may” in RFC8200, but this draft says:

   The Hop-by-Hop Options header is used to carry optional information
   that should be examined by every node along a packet's delivery path.

This doesn’t match what is in RFC8200:

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,…

I didn’t do a through review after I saw it didn’t reference RFC8200, but I suspect there are other things that need to be changed to match RFC8200.  I think the authors need to do detailed review and publish a new draft.

Regard,
Bob

> On Sep 29, 2017, at 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03.
> If you have not read it, please do so now. You may send nits to the author, but substantive discussion should go to the [email-masked] list.
> (While V6OPS WG is in cc because of close alignment with the WG expertise area, may we ask to send feedback and comments in the OPSEC WG)
> 
> We will close the call on 13 October 2017
> 
> Gunter & Eric
> OPSEC WG co-chairs
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Oct 2017 11:10:06 +1300

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

    Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 5 Oct 2017 08:02:34 +0000

Hi,

> On 4 Oct 2017, at 23:10, Brian E Carpenter <[email-masked]> wrote:
> 

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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Oct 2017 14:36:08 +0000

Bob,

Thanks for the review. It is pretty clear that the draft will require rework after the comment period.

                                                                  Ron

> -----Original Message-----
> From: OPSEC [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Wednesday, October 4, 2017 5:38 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]>; [email-masked]
> Cc: [email-masked]; Bob Hinden <[email-masked]>; draft-ietf-opsec-
> [email-masked]
> Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
> 
> 
> It doesn’t reference the new version of the IPv6 specification RFC8200.
> There were a number of clarifications in RFC8200 regarding extension
> headers that may require changes in the draft.
> 
> I didn’t do a through review after I saw it didn’t reference RFC8200, but I
> suspect there are other things that need to be changed to match RFC8200.  I
> think the authors need to do detailed review and publish a new draft.
> 
> Regard,
> Bob
> 
> > If you have not read it, please do so now. You may send nits to the author,
> but substantive discussion should go to the [email-masked] list.
> > (While V6OPS WG is in cc because of close alignment with the WG
> expertise area, may we ask to send feedback and comments in the OPSEC
> WG)
> >

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Oct 2017 06:53:00 -0300

Hello, Bob,

On 10/04/2017 06:38 PM, Bob Hinden wrote:
> It doesn’t reference the new version of the IPv6 specification
> RFC8200.  There were a number of clarifications in RFC8200 regarding
> extension headers that may require changes in the draft.

We talked a bit about this. Best option seems to be to keep the current
text and add text regarding the changes in RFC8200 -- at the end of th
day, an operator will have to deal with both RFC2460 and RFC8200
implementations.

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 20 Oct 2017 15:55:57 +0000

Hi all,

There has been substantial discussion on the document during WGLC and the document has received valuable input for enhancement. The document is not ready yet.

Authors,

The document is on the right track. Please integrate the suggestions during WGLC and if needed we can have a discussion during IETF100 to close the harder suggestions into WG agreement. I’ll be looking forward to see an updated document which reflects WG consensus.

Brgds,
G/

From: Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Friday, September 29, 2017 10:12
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: WGLC for draft-ietf-opsec-ipv6-eh-filtering-03

This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03.
If you have not read it, please do so now. You may send nits to the author, but substantive discussion should go to the [email-masked]<mailto:[email-masked]> list.
(While V6OPS WG is in cc because of close alignment with the WG expertise area, may we ask to send feedback and comments in the OPSEC WG)

Gunter & Eric
OPSEC WG co-chairs

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2017 08:42:20 +1300

> day, an operator will have to deal with both RFC2460 and RFC8200

I don't think that is 100% right. Yes, of course add a general note at
the front stating that the current standard is 8200 but that many
implementations were based on 2460. But then, change all the references
to 8200 and add text where there is an actual difference between the
two cases. So far I think two have been pointed out:
https://mailarchive.ietf.org/arch/msg/opsec/StjbjvCP9PLC3ssnTKYO6jqFgk0
https://mailarchive.ietf.org/arch/msg/opsec/9FigBATRkVHAurXv3aNNR-Z46JU
but there may be others.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Oct 2017 20:36:48 -0300

(sorry for top-posting)

I meant: everywhere there's diverging behaviour between rfc2460 and
rfc8200, note both behaviors.

We can center discussion on rfc8200, and make refs to rfc2460 look like
"notes" (e.g., "rrc2470 used to blah blah...').

Thoughts?

Thanks,
Fernando

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2017 13:30:12 +1300

> "notes" (e.g., "rrc2470 used to blah blah...').

Exactly right. I think that I already proposed text in that spirit
for the RH0 case.

   Brian