Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

[Ole Troan <[e-mail]>]

Steinar,

>> Protecting the control plane can be done by the receiving host
>> (destination router).
> 
> This is a fundamental disagreement. Protecting the control plane needs
> to be done by *all* intermediate routers in today's somewhat hostile
> Internet environment. That also includes some traffic not explicitly
> addressed to the routers themselves (for instance traceroute to a
> destination reached *through* the routers). Only looking at traffic
> addressed to the routers themselves is not sufficient.

assuming we’re talking about a transit provider and transit traffic.
to help those of us who are lacking operational clue, could you expand on the cases where this is necessary?

>> Protecting the network as a whole is useful, and may involve some level
>> of DPI - or may not. If the traffic is encrypted, then only the
>> destination router can protect itself anyway. But dropping the packets
>> because of EH use just makes the filtering router an attacker to the E2E
>> communication between the routers.
> 
> We have some services that are available within our AS, and should not
> be available outside the AS. One such example is DNS resolvers (there
> are others). We have chosen to block such services at the border - by
> having the border routers explicitly blocking UDP/TCP port 53 to the
> resolver addresses. This obviously means the border routers must be
> able to *find* the UDP/TCP header in that part of the IPv6 packet they
> are able to inspect at line rate. This is not "DPI" in any sense of
> the word - it is very basic filtering.
> 
> And here, I assume, is the next disagreement. If the UDP/TCP headers
> cannot be found because IPv6 EHs have pushed them beyond what the
> routers can inspect at line rate - the packet will be dropped.

if you drop packets with DA == your DNS server where you cannot find the L4 information, that seems perfectly fine.
if you drop packets with _any_ DA where you cannot find (or understand) the L4 information then you are offering broken service. again talking about transit here.
to do the former you don’t need to parse deep into the packet, nor deprecate EHs.

> If we can get improved filtering capabilities in our routers as part
> of regular equipment upgrade cycles - great, everybody is happy. But
> we are not likely to buy significantly more expensive routers *just*
> to be able to peek further into the packets (number of customers
> needing this are *many* orders of magnitude too low - if they exist
> at all).

even if you had routers that could parse to the end of the packet, I don’t quite see how that “helps”. the Internet’s success is to a large extent based on being able to route around broken networks, like this would be.

cheers,
Ole