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

[Joe Touch <[e-mail]>]

On 4/21/2015 11:40 PM, [e-mail] wrote:
> <flame retardant suit on>
...
> 
>> 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.

Sure - so here's the solution:

1) declare that your routers won't accept "host" packets (i.e., to their
interface addresses) that use EHs

	if you want to try, extend that to any AS whose routing
	packets you want to DDOS filter (but they need to think this
	is acceptable)

2) if you want to do DDOS filtering, do so on IP addresses for the
specific routers you are trying to protect

	either rate-limit everything to that address, drop
	anything with an EH, rate-limit/drop based on TCP/UDP
	ports, or any combination thereof

I.e., not using EHs is your prerogative, and not forwarding EHs to
others is *their* prerogative, but castrating IPv6 for the entire
Internet is not necessary.

Joe



> 
>> 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 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).
> 
> Steinar Haug, AS 2116
>