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

Hi, we will want to make use of IPv6 EHs (at least Destination Options
and Fragment Header). Are people trying to get rid of them altogether?

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Wednesday, April 22, 2015 10:17 AM
> To: sthaug@nethelp.no
> Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org; v6ops@ietf.org; merike@doubleshotsecurity.com;
> fgont@si6networks.com
> Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
> 
> 
> 
> On 4/21/2015 11:40 PM, sthaug@nethelp.no 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
> >
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops