According to my limited understanding, IPSec authenticates peers and encapsulates/encrypts IP packets in tunnel mode.
On another hand, L2TP itself does not offer authentication/encryption, but offers encapsulation, which is already achieved by IPSec.
In my application, I would like to secure end-to-end data transfer using IPSec. I am also considering "L2TP/IPSec" but cannot figure out which L2TP feature is not offered by IPSec? Why would I choose to use L2TP/IPSec rather than IPSec alone?
The reason people use L2TP/IPsec, rather than plain IPsec in tunnel mode, is to have a user-level authentication layer in addition to the host-level authentication provided by IPsec.
Ref: http://seclists.org/basics/2005/Apr/139
Related
In the NetworkExtensions framework on macOS, the only 2 protocols available in configuration are TCP and UDP.
For example, to write a firewall, apple recommends using NEFilterRule and NENetworkRule. An NENetworkRule takes a protocol as an argument, and the only available values are TCP or UDP.
What happens if a rogue application on the machine with the firewall tries to communicate with the outside world via another protocol? Maybe a custom protocol with no clear rules. Does the NetworkExtension framework allow filtering these cases?
VPNs like Cisco any-connect normally route all traffic through their own network interface.
Would such VPNs still be able to route all traffic even if one binds a socket(client socket in my case) from an app to another network interface.
There are many ways to make a VPN, but you can view most of them as having three primary components
A tunnel interface - a virtual network interface that is listed along with your real network interfaces (on linux you should see in ip link show). The interface implements a protocol that abstracts all the links between the VPN client and server to make it seem like they are on a simpler network
A routing rule - a routing rule that tells your computer what data to send through the tunneling interface and what packets to send through your normal network interfaces. This rule can be as simple as send all packets through the tunneling interface
A cryptographic algorithm - the method of making sure the packets are encrypted and is normally abstracted by the tunneling interface
So to answer your question, you still have access to the other network interfaces. As long you you can bind to it (layer 2 API calls) or listen to it (layer 3 routing rules) then you can access it in a useful way. I recommend looking at your routing table after the VPN is established to get a better idea of what is going on.
I am going to launch new messenger service. However, it is not XMPP based. Instead I am using my own protocol (for certain reasons).
What I am not able to decide on is what port shall I use for this service. A typical XMPP based messenger uses port 5222. Shall I use the same or different port?
Here are pros and cons I can think of...
If I use same port 5222 like other XMPP messengers, being standard port for messenger service my service will also use same port (But are there any cons here for my protocol being non-XMPP?)
If I use some other port, I fear that many firewalls will not allow traffic on non-standard port. Also anti-spywares too might flag my application as suspicious.
Please I need advice from experts.
Just wrap your protocol into TLS connection on 443 port: it will be never blocked by firewalls (just because https connections uses this in the same way) and TLS traffic cannot be identified by "anti-spyware" software
OpenFlow protocol (1.0 and 1.1) does not define any mechanism about encrypt network traffic (traffic between switches)..
Is it possible to encrypt network traffic on SDN networks.. (like, run IpSEC on top of SDN switches )
Openflow protocol is defined between switches and the controller(Floodlight, Ryu, ODL etc). Openflow uses TLS encryption and it does not specify anything regarding the communication between the switches. The communication between the switches still has to be handled by the switches themselves. Hence what ever encryption the switches support they can be configured on those ports where encryption is required. Openflow protocol is not related to this
It is not done yet, however a research is being carried out in order to standardize it with NETCONF protocol. Here is the IETF draft:
IPSec & SDN Standard
I'm writing a client/server program which needs to create a secure network pipe between two machines, identifying them both using certificates. The SSH protocol seems like a perfect match for this - its built-in security, support for authenticating both sides, and maturity being big plusses. It can also multiplex connections by using one open connection to connect many generic ports.
The idea is to create an always-on connection (these programs have a dedicated line between the client and server), and to open a port whenever I need one. Can the SSH protocol be used this way? How would I go about incorporating libssh into my programs to support that?
You can do that using libssh. You create a ssh session and for each port you can open a channel for port forwarding. See
http://api.libssh.org/stable/libssh_tutor_forwarding.html
You can even try out this kind functionality with OpenSSH's -M/ControlMaster function.
Both libssh and libssh2 support this functionality.
A little nit: SSH doesn't use certificates, it uses private/public keys.