netdev - Re: [PATCH net-next v1 0/3] Flow Based GTP Tunneling

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]

Message-ID: <AAC8ECB0-A089-4308-989D-65E18B9EFAB7@fb.com>
Date:   Thu, 13 Jul 2017 22:54:10 +0000
From:   Jiannan Ouyang <ouyangj@...com>
To:     Joe Stringer <joe@....org>, Harald Welte <laforge@...monks.org>
CC:     "osmocom-net-gprs@...ts.osmocom.org" 
        <osmocom-net-gprs@...ts.osmocom.org>,
        netdev <netdev@...r.kernel.org>, ovs dev <dev@...nvswitch.org>,
        "Pablo Neira Ayuso" <pablo@...filter.org>,
        Pravin B Shelar <pshelar@...ira.com>,
        "Wieger IJntema" <wieger.ijntema.tno@...il.com>,
        "Yang, Yi Y" <yi.y.yang@...el.com>,
        Amar Padmanabhan <amarpadmanabhan@...com>
Subject: Re: [PATCH net-next v1 0/3] Flow Based GTP Tunneling

Hi Harald and Jeo,

Thank you for the code review. They are really helpful!

> On 7/13/17, 11:14 AM, "Joe Stringer" <joe@....org> wrote:
> 
    > On 13 July 2017 at 00:12, Harald Welte <laforge@...monks.org> wrote:
    >> I'm not familiar with the details here, but does this imply that you
    >> are matching on the outer (transport layer) source IP address? If so,
    >> please note this is in violation of the 3GPP specifications for GTP,
    >> which require explicitly that the TEID is the *only* criteria for
    >> matching an encapsulated packet to the tunnel.  Basically anyone can
    >> send you an encapsulated packet from any random source IP, just as long
    >> as the TEID matches a tunnel, it will be decapsulated.
    >>
    >> This is [presumably] in order to take care of mobility, as the
    >> subscribers' phone moves around different MME/S-GW/SGSN, each having
    >> different source IP addresses.
    >
    > I think that this will be hard to avoid; the several existing tunnel
    > implementations that OVS plugs into all allow matching on the outer
    > addresses/ports, I don't see a good way to restrict it without
    > introducing completely new metadata_dst paths for GTP. I'd prefer not
    > to introduce something like this if we can avoid it; several tunnels
    > currently share all of the same metadata_dst code and that's proven
    > sufficient for all cases so far. If someone wishes to implement the
    > 3GPP standard correctly then they should not create matches like this.
    > In quite a few cases, OVS tends to take the approach that we give the
    > user the tools to do what they need to do, but if they wish to shoot
    > themselves in the foot then that's up to them. We can of course work
    >  towards ensuring the OVS userspace guides users in the right direction
    > though.
    
The flow listed out here is an example for the nature of the match
that can be performed, but the actual match rule that is programmed
 by the control plane should wildcard the tun_src as noted by Harald. 

It is the control plane’s responsibility to enforce the 3GPP Specifications, 
e.g. creating flow rules to make TEID the only criteria for matching an 
encapsulated packet to the tunnel.  

I will provide a 3GPP compliant example in the next version, thank Harald
 for pointing it out.

-Jiannan