<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 4, 2015 at 8:18 AM, Ca By <span dir="ltr"><<a href="mailto:cb.list6@gmail.com" target="_blank">cb.list6@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 4, 2015 at 8:03 AM, Dominik Bay <span dir="ltr"><<a href="mailto:db@rrbone.net" target="_blank">db@rrbone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 06/04/2015 04:00 PM, Yannis Nikolopoulos wrote:<br>
> On 06/04/2015 01:08 PM, <a href="mailto:michalis.bersimis@hq.cyta.gr" target="_blank">michalis.bersimis@hq.cyta.gr</a> wrote:<br>
</span><span>>>> From our side we have seen lots of IPv4 traffic from sources<br>
>>> originated from AS15169 (UDP port 443) .We are using netflow to<br>
>>> identify the traffic.<br>
><br>
> You're right,<br>
><br>
> We can also see the relevant IPv4/IPv6 traffic via Netflow, as it enters<br>
> our network, It's just weird that we don't see logs for the denied<br>
> matched IPv4 packets further down the network, as we do for IPv6...<br></span></blockquote></div></div></div></div></div></blockquote><div><br></div><div>Random guess: All your traffic to Google is over IPv6, and that's why you don't see IPv4?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>Why are you blocking QUIC traffic anyway?<span><font color="#888888"><br>
</font></span></blockquote></div><br></div></div></div><div class="gmail_extra">This is an IPv6 list, and there is no reason to block quic on IPv6.</div><div class="gmail_extra"><br>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.... </div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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...</div></div></blockquote><div><br></div><div>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 provider.</div><div><br></div><div>Damian</div></div></div></div>