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. >>> >> >> 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://tools.ietf.org/html/rfc7872>]. 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
