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

[Fernando Gont <[e-mail]>]

On 5/12/18 16: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".
> 
> 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.

We did that in gont-v6ops-ipv6-ehs-packet-drops, but I agree that that
is not explicitly mentioned in the document. I wouldn't rehash the I-D
here, but simply note something along the lines of:

---- cut here ----
While not strictly part of the functionality in of a router, it is a
common practice for network equipment attempting to provide differential
treatment of packets based on protocol types and port, for reasons such as:

 o ECMP and Hash-based Load-Sharing

 o Enforcing infrastructure ACLs

 o DDoS Management and Customer Requests for Filtering


While the IPv6 standard assumes that routers only look at the address
flow-id fields, the aforementioned operational requirements results in
the aforementioned devices having to parse the IPv6 extension header
chain. In such scenarios, extension headers poses a challenge to these
devices, which have implementation limits in the lengths of the
extension chains they are able to process, or the performance with which
they can process the EH chains. In that sense, the IPv6 design is
actually a departure from IPv4, whose header format makes it easy to
skip over the option field and assess the "five tuple".
[gont-v6ops-ipv6-ehs-packet-drops] contains further discussion of these
issues.
---- cut here ----


Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492