On 10/5/17 11: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
Traffic on a isp either the isp's traffic or a customers (customer is transitive, a customer of a customer is customer traffic). traffic which neither to a customer or the isp is party to unwanted, whether it's there due to malice or intention. what services one offers to a customer seems entirely like a contractual detail. strictly speaking the destination of a packet may not be the destination address in the ip header as when the TTL is lowered or when hop by hop options are employed. > > > 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 > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
