Hi guys,
Please, let me introduce myself. My name is Manuel Munoz, Computer Scientist, looking for a topic for my project/undergrad thesis at Universidad de Leon, Spain. I am evaluating these days the possibility to do something interesting which could be used as my project and also to put my bit for the OpenGGSN project.
Some more about me. I am 36, have been working for +10 years in IT (sysadmin, php developer, plsql developer, datacenters...). I can speak English and Spanish and hold a 3 years bachelor degree. Not long ago I worked for two years for providers of 2G/3G network monitoring systems, so I have some knowledge about those topics. Also quite fluent in C, wireshark, unix scripting...
This weekend I have been doing a quick research and refreshing my mind about both security and mobile networks, and also took a look to OpenGGSN code.
Long story short, what about me implementing IPSec for GTP-C in OpenGGSN? Do you think it could be useful? Feasible?
3GPP Protect GTP signalling messages by IPSec ( http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_14_Oslo/Docs/PDF/S3-000421... ) 3GPP Use IPSec to secure GTP messages ( http://www.3gpp.org/ftp/tsg_sa/wg3_security/tsgs3_13_yokohama/docs/PDF/S3-00... )
Maybe some other security-oriented feature you want to be implemented?
I would love to hear your thoughts!
Thanks for your time, Manuel
Hi Manuel,
On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel José Muñoz Calero wrote:
I am evaluating these days the possibility to do something interesting which could be used as my project and also to put my bit for the OpenGGSN project.
thanks for reaching out about this.
Long story short, what about me implementing IPSec for GTP-C in OpenGGSN? Do you think it could be useful? Feasible?
I've quickly looked at the documents you linked, and they don't really state anything beyond "use IPsec for GTP". Specifically, the do not specify how to do key distribution, how to set up the SAs, whether they use a standard IKEv2 or something else, ...
As Linux has a fairly complete IPsec implementation consisting of the kernel-level IPsec transforms with its netlink interface and e.g. the Strongswan userland, I don't really think there is anything that would need to be done in addition to configuring both this IPsec stack and OpenGGSN.
So what exactly would you want to do? Am I missing something?
Well, the idea was to use libipsec to integrate IPSec functionality into OpenGGSN code, so OpenGGSN itself could set IPSec parameters and start connection.
Maybe it has no sense or it is not an improvement, this is why I am asking you. I am no expert as you can see.
What about writting a GTP traffic open source analyzer? I started writting it a couple of years ago. I used tcpdump output and parsed it with awk and got statistics about many things (especially errors, packets per protocols counting...). It could be written in C this time.
Could be interesting doing it properly?
2016-03-21 17:18 GMT+01:00 Harald Welte laforge@gnumonks.org:
Hi Manuel,
On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel José Muñoz Calero wrote:
I am evaluating these days the possibility to do something interesting which could be used as my project and also to put my bit for the OpenGGSN project.
thanks for reaching out about this.
Long story short, what about me implementing IPSec for GTP-C in OpenGGSN? Do you think it could be useful? Feasible?
I've quickly looked at the documents you linked, and they don't really state anything beyond "use IPsec for GTP". Specifically, the do not specify how to do key distribution, how to set up the SAs, whether they use a standard IKEv2 or something else, ...
As Linux has a fairly complete IPsec implementation consisting of the kernel-level IPsec transforms with its netlink interface and e.g. the Strongswan userland, I don't really think there is anything that would need to be done in addition to configuring both this IPsec stack and OpenGGSN.
So what exactly would you want to do? Am I missing something?
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Manuel,
On Tue, Mar 22, 2016 at 02:18:48AM +0100, Manuel José Muñoz Calero wrote:
Well, the idea was to use libipsec to integrate IPSec functionality into OpenGGSN code, so OpenGGSN itself could set IPSec parameters and start connection.
I don't think this is a good idea at all, sorry.
IPsec is a feature provided by the operating system, and it is very well (and efficiently) handled by doing all the per-packet operations inside the kernel itself. Only the control (key handshake) is done in userspace, and three are several implementations of the IKEv1/IKEv2 protocols out there. There's no need to replicat that functionality in OpenGGSN.
What about writting a GTP traffic open source analyzer? I started writting it a couple of years ago. I used tcpdump output and parsed it with awk and got statistics about many things (especially errors, packets per protocols counting...). It could be written in C this time.
I suggest you to have a look at the wireshark infastructure in the 'Statistics' / 'Telephony' menus. They do pretty nice for other protocols like TCP or SIP.
Fair enough. Thanks for your time and comments. El 22/3/2016 15:15, "Harald Welte" laforge@gnumonks.org escribió:
Hi Manuel,
On Tue, Mar 22, 2016 at 02:18:48AM +0100, Manuel José Muñoz Calero wrote:
Well, the idea was to use libipsec to integrate IPSec functionality into OpenGGSN code, so OpenGGSN itself could set IPSec parameters and start connection.
I don't think this is a good idea at all, sorry.
IPsec is a feature provided by the operating system, and it is very well (and efficiently) handled by doing all the per-packet operations inside the kernel itself. Only the control (key handshake) is done in userspace, and three are several implementations of the IKEv1/IKEv2 protocols out there. There's no need to replicat that functionality in OpenGGSN.
What about writting a GTP traffic open source analyzer? I started writting it a couple of years ago. I used tcpdump output and parsed it with awk and got statistics about
many
things (especially errors, packets per protocols counting...). It could be written in C this time.
I suggest you to have a look at the wireshark infastructure in the 'Statistics' / 'Telephony' menus. They do pretty nice for other protocols like TCP or SIP.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi.
Thanks for your interest. Are you looking into OpenGGSN only or you might be interested in other parts of the stack as well?
On 03/21/2016 04:00 PM, Manuel José Muñoz Calero wrote:
Hi guys,
Please, let me introduce myself. My name is Manuel Munoz, Computer Scientist, looking for a topic for my project/undergrad thesis at Universidad de Leon, Spain. I am evaluating these days the possibility to do something interesting which could be used as my project and also to put my bit for the OpenGGSN project.
Some more about me. I am 36, have been working for +10 years in IT (sysadmin, php developer, plsql developer, datacenters...). I can speak English and Spanish and hold a 3 years bachelor degree. Not long ago I worked for two years for providers of 2G/3G network monitoring systems, so I have some knowledge about those topics. Also quite fluent in C, wireshark, unix scripting...
This weekend I have been doing a quick research and refreshing my mind about both security and mobile networks, and also took a look to OpenGGSN code.
Long story short, what about me implementing IPSec for GTP-C in OpenGGSN? Do you think it could be useful? Feasible?
3GPP Protect GTP signalling messages by IPSec (http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_14_Oslo/Docs/PDF/S3-000421...) 3GPP Use IPSec to secure GTP messages (http://www.3gpp.org/ftp/tsg_sa/wg3_security/tsgs3_13_yokohama/docs/PDF/S3-00...)
Maybe some other security-oriented feature you want to be implemented?
I would love to hear your thoughts!
Thanks for your time, Manuel
On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel José Muñoz Calero wrote:
I am evaluating these days the possibility to do something interesting which could be used as my project and also to put my bit for the OpenGGSN project.
Well, my opinion is that OpenGGSN has fairly bad code structuring. It has heavy use of code duplication and the code layers aren't separated well (e.g. I can't use libgtp to decode messages without also using its tx/rx).
So a proper audit and spring cleaning might be a nice project, if not necessarily super exciting, at least it is well defined in that OpenGGSN should not (or hardly) change behavior while making the code safer / easier to maintain / more versatile to re-use. You could analyse the code structures and/or security holes, academically argue why they are bad and come up with improvements, while using and/or writing tests to ensure correctness. If you know your stuff, all OpenGGSN users would arguably benefit from that.
I'd like to do that if I had the time, but that will probably never be the case. I'm too busy writing new bugs for 3G :P
That's just my sixpence -- good speed for your project, whichever you chose! :)
~Neels
Hi guys,
I will do my project about some other topic. But it has been nice to find this project so I will gladly work in making OpenGGSN code better.
I will come back with my findings and plan.
Regards, Manuel
2016-03-22 16:12 GMT+01:00 Neels Hofmeyr nhofmeyr@sysmocom.de:
On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel José Muñoz Calero wrote:
I am evaluating these days the possibility to do something interesting which could be used as my project and also to put my bit for the OpenGGSN project.
Well, my opinion is that OpenGGSN has fairly bad code structuring. It has heavy use of code duplication and the code layers aren't separated well (e.g. I can't use libgtp to decode messages without also using its tx/rx).
So a proper audit and spring cleaning might be a nice project, if not necessarily super exciting, at least it is well defined in that OpenGGSN should not (or hardly) change behavior while making the code safer / easier to maintain / more versatile to re-use. You could analyse the code structures and/or security holes, academically argue why they are bad and come up with improvements, while using and/or writing tests to ensure correctness. If you know your stuff, all OpenGGSN users would arguably benefit from that.
I'd like to do that if I had the time, but that will probably never be the case. I'm too busy writing new bugs for 3G :P
That's just my sixpence -- good speed for your project, whichever you chose! :)
~Neels
osmocom-net-gprs@lists.osmocom.org
-
Harald Welte -
Manuel José Muñoz Calero -
Max -
Neels Hofmeyr