IPv6 QUIC traffic
damian at google.com
Thu Jun 4 19:28:45 CEST 2015
On Thu, Jun 4, 2015 at 8:18 AM, Ca By <cb.list6 at gmail.com> wrote:
> On Thu, Jun 4, 2015 at 8:03 AM, Dominik Bay <db at rrbone.net> wrote:
>> On 06/04/2015 04:00 PM, Yannis Nikolopoulos wrote:
>> > On 06/04/2015 01:08 PM, michalis.bersimis at hq.cyta.gr wrote:
>> >>> From our side we have seen lots of IPv4 traffic from sources
>> >>> originated from AS15169 (UDP port 443) .We are using netflow to
>> >>> identify the traffic.
>> > You're right,
>> > We can also see the relevant IPv4/IPv6 traffic via Netflow, as it enters
>> > our network, It's just weird that we don't see logs for the denied
>> > matched IPv4 packets further down the network, as we do for IPv6...
Random guess: All your traffic to Google is over IPv6, and that's why you
don't see IPv4?
Why are you blocking QUIC traffic anyway?
> This is an IPv6 list, and there is no reason to block quic on IPv6.
> But, i definitely rate limit UDP ipv4 since that vast majority of UDP is
> DDoS traffic... I have suggested to the QUIC folks to use a new protocol
> number so they are not guilty by association with other UDP service... but
> they think broken CPE are a bigger problem. I think DDoS from UDP (NTP,
> DNS, SSDP, CHARGEN, SNMP ...) is a bigger problem....
You don't need to block all UDP to filter DDoS traffic. Rate-limiting
traffic from the specific ports you mentioned (123, 53, 1900, 19, 161) is
sufficient. Given QUIC traffic always uses a high-numbered ephemeral port,
there's little risk of impact to it if you rate-limit only those ports
commonly used for amplification.
I guess Google will just have to deal with QUIC not working on IPv4 in my
> network. Or they can use a new L4 protocol number and use the proven fall
> back strategy they already have with TCP to apply here as well...
I'm not sure your users will agree with your choice, especially as more
sites start to support QUIC, but I suppose they can always move to another
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ipv6-ops