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
Related
Why was UDP used as the standard protocol in NFS systems up to version 3 and TCP in version 4? Unfortunately, I have not yet found anything about the motives that led to this.
The Red Hat NFS documentation provides some insight about why UDP was preferred:
When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks.
...and why the move to allow and eventually require TCP was made:
However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFS server.
The current RFC also notes that TCP facilitates transport security without needing to tunnel:
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The registered port 2049 [RFC3232] for the NFS protocol SHOULD be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as described in [RFC1833]; this will allow NFS to transit firewalls.
Why TCP specifically? Actually, the RFC says SCTP is also acceptable (though TCP support is mandatory):
Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP). To enhance the possibilities for interoperability, an NFSv4 implementation MUST support operation over the TCP transport protocol.
Finally, addressing performance, the original reason UDP was chosen, the RFC says:
If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short-lived connections and will improve performance for the Wide Area Network (WAN) environment by eliminating the need for SYN handshakes.
Ultimately, only the engineers at Sun Microsystems (as the creators of NFS) know the exact reasons UDP was chosen and only the IETF working group for NFS (as the maintainers) know why the switch to TCP was made.
I've read that:
Gateways are basically protocol converters, facilitating compatibility
between two protocols and operating on any layer of the open systems
interconnection (OSI) model.
I don't understand what protocols gateway converts. Why is it important to convert protocols? Isn't TCP/IP protocol stack common for all devices that take part in network transmission of data?
"Gateway" is a broad term which is used in different ways in different contexts. "Protocol" is a similar broad term with context specific meanings.
What you cite would for example apply to gateways translating between IPv4 and IPv6 (different IP protocols), between SIP, POTS or H.323 (different telephony protocols), between HTTP/2 and HTTP/1 (different versions of HTTP protocol), WebSockets and plain TCP sockets (different protocols for bidirectional communication) etc.
Note that other common uses of the term Gateway in the context of network don't involve converting protocols. For example Secure Web Gateway or Secure Mail Gateway keep the application protocol but inspect the protocol payload. For even more meanings see Wikipedia: Gateway.
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?
We are investigating adding the Kaa client to our products and using the Kaa server operationally, and we have some questions in the networking and protocol area. Our main concern is having the IoT device access the IoT server through the Internet without being blocked by the firewall at the IoT device in a "typical" environment. For this reason we see that HTTP/HTTPS using port 80/443 is often used.
Do you believe that most of the IoT device will communicate because most firewalls allow all outgoing traffic?
Or do you think that most end users will have to explicitly configure a firewall rule for the IoT device?
What was the rationale for using the port numbers 9889/9888 and 9999/9997?
Can these port numbers be reasonablely modified? If so, where and how?
Is there a specification of the Kaa TCP protocol?
Thank You
Keith Krajewski
About Kaa TCP protocol use official documentation page
you can change ports of bootstrap and operations services in this files:
bootstrap-http-transport.config
bootstrap-tcp-transport.config
operations-http-transport.config
operations-tcp-transport.config
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