Ron, Mike, Yes. I'd missed that point.
Regards Brian On 06/10/2017 07:04, Ron Bonica wrote: > Mike, > > I think that you just struck the note that Fernando and I missed. Transit > routers filter extension headers for one of the following reasons: > > > - To protect themselves (as in RFC 6192) > > - To protect downstream devices > > Therefore, the document should contain two clearly marked sections, one > regarding EH filtering policies that protect the transit router and one > regarding EH filtering policies that protect downstream devices. > > The first section can: > > > - Be very short (2 pages max) > > - Be guided largely by RFC 8200 > > - Speak with some degree of authority (while still INFORMATIONAL) > > The second section should begin with a discussion of the relationship between > the transit router and the downstream devices. Let’s assume that the transit > router belongs to an ISP, while downstream devices fall into the following > three classes: > > > 1) Belong to the ISP > > 2) Belong to parties who want to be protected by the ISP (e.g., its > customers) > > 3) Belong to other parties > > Therefore, the transit router MAY discard packets that pose a threat to the > first two classes of downstream device, but MUST NOT discard packets that are > required by the third class of downstream device. > > From this point, we formulate a policy that *might* satisfy the above > mentioned requirement. We mark this policy with the following caveats: > > > - It is a best guess > > - If the policy is too permissive, downstream devices belonging to > the ISP and those who it protects will not receive all of the protection > possible > > - If the policy is too restrictive, downstream devices belonging to > other parties will experience collateral damage > > - One size doesn’t fit all > > If we were to rework the document into this shape, would it address your > concerns. > > Ron > > > > From: OPSEC [mailto:[email protected]] On Behalf Of C. M. Heard > Sent: Wednesday, October 4, 2017 11:08 PM > To: OPSEC <[email protected]> > Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03 > > On Thu, 5 Oct 2017 11:10:06 +1300, Brian E Carpenter 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dopsec-2Dipv6-2Deh-2Dfiltering-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=M7xHnDuuJxhA21iLVXO_-AZjAhvXwgaN__niQRcoBwc&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. >> >> 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 am afraid that I do not agree that the document, in its present form, > will do that. It says: > > > The filtering policy typically depends on where in the network such > > policy is enforced: when the policy is enforced in a transit network, > > the policy typically follows a "black-list" approach, where only > > packets with clear negative implications are dropped. On the other > > hand, when the policy is enforced closer to the destination systems, > > the policy typically follows a "white-list" approach, where only > > traffic that is expected to be received is allowed. The advice in > > this document is aimed only at transit routers that may need to > > enforce a filtering policy based on the EHs and IPv6 options a packet > > may contain, following a "black-list" approach, and hence is likely > > to be much more permissive that a filtering policy to be employed > > e.g. at the edge of an enterprise network. The advice in this > > document is meant to improve the current situation of the dropping of > > packets with IPv6 EHs in the Internet > [RFC7872<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7872&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=KqV5UiI6Ie51NtocuTw9zMCtHX8aMheboGCPVCzdepA&e=>]. > > while at the same time promoting a **default deny** policy with > respect to unrecognized options and unrecognized extension headers. > That is antithetical to the mission of a **transit router**, which > is to get packets transparently from point A to point B. It is > especially egregious to dispense this advice for unrecognized > extension headers, since they are indistinguishable from unrecognized > transport protocols. If these things are blocked by **transit routers** > it becomes impossible to deploy any new options or transport protocols. > > But we already know that, don't we? > > > > If we want to give constructive advice that really will make the > > world a better place, we should: > > > 1.) Advise operators of **transit routers** to be transparent to > > everything other than the Hop-by-Hop extensions header, and provide > > detailed advice on what to do (based on the updates in RFC 8200) > > about Hop-by-Hop options. The default should be IGNORE unless there > > is an option you need to process. > > > 2.) Reserve all the detailed filtering advicee for operators of > > firewalls, enterprise routers, and other systems whose mission it > > is to protect the end systems behind them (or to prevent misbehavior > > by said end systems). A default deny for unrecognized stuff is not > > unreasonable for such systems. > > > 3.) Remind implementors of the following requirement from RFC 7045: > > > Forwarding nodes MUST be configurable to allow packets containing > > unrecognised extension headers, but the default configuration MAY > > drop such packets. > > > and add similar advice for options. > > > Thanks and regards, > > > Mike Heard > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
