IPv6 QUIC traffic

[Ca By]

On Thu, Jun 4, 2015 at 10:28 AM, Damian Menscher <damian at google.com> wrote:

> 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.
>
>
UDP 80 and 443 are very commonly associated with DDoS in my experience.  I
think it is common used as a reflection source port.


> 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
> provider.
>
>
Cute.  And helpful.  QUIC can just fall back. Or QUIC can use a new L4
protocol.  That's why we have protocol numbers.  I provided my feedback to
the QUIC team.


> Damian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20150604/fed72307/attachment.htm>