On Thu, Feb 23, 2017 at 6:00 AM, Pablo Neira Ayuso <pa...@netfilter.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 t...@herbertland.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!
