netdev - Re: [PATCH net-next] net/gtp: Add udp source port generation according to flow hash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Feb 2017 08:35:13 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Andreas Schultz <aschultz@...p.net>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        laforge <laforge@...monks.org>, netdev <netdev@...r.kernel.org>,
        timo lindhorst <timo.lindhorst@...velping.com>
Subject: Re: [PATCH net-next] net/gtp: Add udp source port generation
 according to flow hash

On Thu, Feb 23, 2017 at 6:00 AM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
> On Thu, Feb 23, 2017 at 10:35:56AM +0100, Andreas Schultz wrote:
>> ----- On Feb 22, 2017, at 10:47 PM, Tom Herbert tom@...bertland.com wrote:
> [...]
>> > This shouldn't be taken as a HW requirement and it's unlikely we'd add
>> > explicit GTP support in flow_dissector. If we can't get entropy in the
>> > UDP source port then IPv6 flow label is a potential alternative (so
>> > that should be supported in NICs for RSS).
>> >
>> > I'll also reiterate my previous point about the need for GTP testing--
>> > in order for us to be able to evaluate the GTP datapath for things
>> > like performance or how they withstand against DDOS we really need an
>> > easy way to isolate the datapath.
>>
>> GTP as specified is very unsecure by definition. It is meant to be run
>> only on *private* mobile carrier and intra mobile carrier EPC networks.
>> Running it openly on the public internet would be extremly foolish.
>>
>> There are some mechanisms in GTPv1-C on how to handle overload and
>> more extensive mechanisms in GTPv2-C for overload handling. The basic
>> guiding principle is to simply drop any traffic that it can't handle.
>>
>> Anyhow, I havn't seen anything in 3GPP or GSMA documents that deals
>> with DDOS.
>>
>> There are guidelines like the GSMA's IR.88 that describe how the intra
>> carrier roaming should work and what security measures should be
>> implemented.
>>
>> Traffic coming in at Gi/SGi or form the UE could create a DDOS on tunnel.
>> However, on the UE side you still have the RAN (eNODE, SGSN, S-GW) or
>> an ePDG that has to apply QoS and thereby limit traffic. On the Gi/SGi
>> side side you have the PCEF that does the same.
>>
>> So in a complete 3GPP node (GGSN, P-GW) that uses the GTP tunnel
>> implementation, malicious traffic should be blocked before it can reach
>> the tunnel.
>>
>> And as I stated before, the GTP tunnel module is not supposed to be
>> use without any of those components. So the DDOS concern should not
>> be handled at the tunnel level.
>
> I think that Tom's point is that this tunnel driver will have to deal
> with DDOS scenarios anyway, because reality is that you can't always
> block it before it can reach the tunnel.
>
Right, if only we had a dime for every time someone thought their
perimeter security was sufficient only to be proven wrong!