On 2018-12-06 08:26, Christian Huitema wrote: > > On 12/5/2018 10:08 AM, Gert Doering wrote: >> On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: >>> You are creating the ???perceived??? security problem yourself, by requiring processing deeper into the packet than is required. >>> Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header. >>> You seem to think HBH still means ???punt to software???. If it ever meant that. >>> >>> There???s no need for rate-limiting for not processing HBH obviously. >> I *must* be able to look at the protocol field of packets coming in on >> our borders (see detailed description on our rate-limiting rules in >> another mail of today). If there are EHs in the way so our routers' >> hardware cannot decide if this is a TCP or UDP packet, these packets >> go down the drain. > > Gert, I think that you are actually pointing at a significant issue with > the draft. > > The draft goes into an evaluation of "security issues", without actually > explaining some basic assumptions. For example, it is hard to believe > that a router forwarding too many packets of any kind will cause an > issue for the security *of that router*. But on the other hand there is > a widely distributed practice of network equipment attempting to provide > differential treatment of packets based on protocol types and port > numbers. That practice is not acknowledged in the RFC that specify IPv6. > In fact, the IPv6 design assumes that routers only look at the address > and flow-id fields. This design is actually a departure from IPv4, whose > header format makes it easy to skip over the option field and assess the > "five tuple". And I don't think that is an oversight. The *definition* of "router" for IPv6 is "a node that forwards IPv6 packets not explicitly addressed to itself." No mention of filtering, classification, admission control,... > The draft *implicitly* assumes that routers will try to find the > protocol and port numbers "because of security reasons", but never > actually delineates these reasons. I think the discussion would be much > more productive if the draft started by explaining why network managers > believe that access to the "five tuple" is essential for a variety of > reasons, many of which are only tangentially related to "security". At > that point we can have a discussion between protocol designers assuming > that the network routers shall only look at IPv6 addresses and that > everything else is end-to-end on one side, and on the other side network > managers explaining why they need access to the payload type and port > numbers. That seems to define a class of "routers" that have supplementary functions that are not part of routing. And, surprise, these functions cannot be satisfied by only inspecting the first 40 bytes of the packet. I agree that this could usefully be made very clear in the draft. > My personal preferences on the subject are not very relevant, and I > could actually line up arguments for both sides of that debate. But I > believe that getting to a resolution there would be much better than > arguing piecemeal over this or that end-to-end option. I doubt that we can ever resolve this, but we can document it. Brian
