On Sat, Nov 24, 2018 at 5:14 PM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > On 24/11/18 17:13, C. M. Heard wrote: > >> 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? > > 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
