Subject: [OPSEC] (no subject)

From: "C. M. Heard" <[email-masked]>
Date: Sat, 24 Nov 2018 12:08:52 -0800

> On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote:
>
> Reviewer: Michael Scharf
> Review result: Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please
> always CC tsv-art at ietf.org if you reply to or forward this review.
>
> I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent
> transport issues. The proposed filtering could slow down the deployment of
> experimental protocols that use IPv6 options, but the tradeoffs are explained
> in the document.

Did you notice that Section 3.5.5 advises discarding IPv6 packets whose Next
Header value is unknown -- i.e., IPv6 packets with unknown EHs **or** unknown
transport protocols?  Even for an IPv6 core router in the open Internet?

If not, would that fact change your assessment of this document?

As I noted in my own last call comments, I think that a more nuanced approach
is called for (e.g., as set forth in Section 4.4.5 for unknown option values).

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 24 Nov 2018 12:13:22 -0800

Mike Heard

---

From: "Scharf, Michael" <[email-masked]>
Date: Sat, 24 Nov 2018 20:46:37 +0000

> transport protocols?  Even for an IPv6 core router in the open

Given the widespread deployment of NAT/NAPT and firewalls, which will typically drop packets with unknown transport protocols by default (AFAIKT), I have doubts that implementing the suggested policy in IPv6 core routers changes the overall situation significantly. 

Unfortunately, the reality is that it is today challenging to deploy new transport protocols in the Internet, no matter what this informational document writes.

> If not, would that fact change your assessment of this document?

I should perhaps have better highlighted the impact on unknown transport protocols. Yet, the real-world impact on transport protocols is IMHO small.

As a side note, if the document headed for BCP, I would be more concerned.
 
> is called for (e.g., as set forth in Section 4.4.5 for unknown option

I will not disagree with using a more nuanced approach.

Michael

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Nov 2018 22:07:14 -0300

> transport protocols?  Even for an IPv6 core router in the open Internet?

The document gos in line with RFC7045. Not sure what the issues is here...

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 24 Nov 2018 18:48:55 -0800

> The document gos in line with RFC7045. Not sure what the issues is here...

RFC 7045 requires that treatment of unknown Next Header codepoints be
configurable and says that the default configuration MAY be to discard.

The draft advises all operators to select the discard option.  As Brian
Carpenter pointed out in his response to the thread started by my last call
comments, that effectively trumps the MAY in RFC 7045 with a lower case
should.  So it really is not in line with RFC 7045.  That's one problem.

And as Joe Touch said, treating every unknown codepoint as an attack
is itself an attack.  Remember, the advice in the draft is directed to
operators of **transit routers**, including core routers in the open Internet,
and applies to traffic not directed to the router.  So the purpose is to protect
downstream infrastructure and customers.  But customers who want to use new
transport protocols will be harmed, not protected, by the discarding of packets
with Next Header values that are unknown to the operator of the router.  Biasing
the advice in this way exacerbates the very protocol ossification issues that
the draft purports to want to solve.  That's a much bigger problem.

I think that you and your co-author did a good job in Section 4.5 with unknown
options; there the advice is much more nuanced, instead of being biased
toward the blanket default-deny policy that got us into the ossification mess
in the first place.  Why not give the same advice for unknown Next Header
codepoints, as I suggested in my last call comments?   Or leave the
advice neutral, as Brian suggested?

Mike Heard