Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Brian E Carpenter <[e-mail]>]

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