[udp] DTLS

Reference:
https://stackoverflow.com/questions/15331294/difference-between-dtls-and-tls

Datagram Transport Layer Security Version 1.2

DTLS uses TLS over UDP

[sigstop] sigstop while kernel TCP stack per process continues to receive package

Reference:

What happens to requests to a service that is stopped with SIGSTOP


From the point of view of any part of the system that isn't concerned with the process's state and stats, a process that is stopped (i.e. won't be scheduled until it receives a SIGCONT) is indistinguishable from a process that's running, but isn't responding to a particular query.

While the process is stopped, there's no such thing as a timeout in the process. There are usually no timeouts in the network stack either: the packet has been received by the machine, even if it hasn't gotten to the machine. As far as e.g. TCP transmission is concerned, the packet has been received and it's up to the application to respond.

If the socket's buffer fills up, the network stack will start dropping packets.

There's no reason why the behavior of the network stack would depend on the process's state. The process could come out of the stopped state at any time. There could be multiple processes listening on a socket, so any decision based on the process state would have to take all of them into account.

[DNS Response Policy Zones][bookmark]

Reference:
https://dnsrpz.info/
http://www.circleid.com/posts/20120103_dns_firewalls_in_action_rpz_vs_spam/

[nmap] tcp/ip layer detection

Recently there's a project started at company which reminds me wrote an nmap fork 8 years ago... :-)

https://github.com/verbalsaint/P538_Project_2

[network] TAP / Linux Bridge

Reference:
https://linux-blog.anracom.com/tag/linux-bridge-linking/
https://docs.docker.com/network/bridge/

Virtual "veth" Ethernet devices are used for connecting virtual containers to virtual bridges like an Linux bridge.

"veth" comes with pair, which is used to connect between linux network namespace.

For security reason, avoid giving a Linux bridge itself an IP.


TAP:
A virtual "tap" device is a single point to point device which can be used by a program in user-space or a virtual machine to send Ethernet packets on layer 2 directly to the kernel or receive packets from it.


Limitations of standard Linux bridges:

• A "tap" device attached to one Linux bridge cannot be attached to another Linux bridge.
• All attached devices are switched into the promiscuous mode.
• The bridge itself (not a tap device at a port!) can get an IP address and may work as a standard Ethernet device. The host can communicate via this address with other guests attached to the bridge.
• You may attach several physical Ethernet devices (without IP !) of the host to a bridge - each as a kind of "uplink" to other physical switches/hubs and connected systems. With the spanning tree protocol activated all physical systems attached to the network behind each physical interface may communicate with physical or virtual guests linked to the bridge by other physical interfaces or virtual ports.
• Properly configured the bridge transfers packets directly between two specific bridge ports related to the communication stream of 2 attached guests - without exposing the communication to other ports and other guests. The bridge may learn and update the relevant association of MAC addresses to bridge ports.
• The virtual bridge device itself - in its role as an Ethernet device - does not work in promiscuous mode. However, packets arriving through one of its ports for (yet) unknown addresses may be flooded to all ports.
• You cannot bridge a Linux bridge directly by or with another Linux bridge (no Linux bridge cascading). You can neither connect a Linux bride to another Linux bridge via a "tap" device.

[QUIC] quick skim over protocol QUIC

So, in order to have HTTP/2 supports multiplexing by using single TCP connection, we need a way to differentiate different request/response pair through single TCP connection, thus we introduce stream ID as the key mapping to request/response.


TCP has it's own sequence number to construct the packets in order on the receiving side.


Thus, the upper HTTP layer will receive the ordered TCP response thus base on stream ID can it builds up the response/request pair.


When the HTTP/2 TCP connection is established,
the client and server exchange SETTINGS frames first,
(like TCP's MSS setting option during init. SYN handshake, can't be changed once connection is established)
which indicates how many streams can be open at a time(or how many parallel requests), how many bytes server is ready to receive for a stream and for the whole connection, and the rate at which data can be delivered or received i.e., window size.


As you can spot there's a performance issue here.
TCP also times-out if missing a package(receiving side) during transfer which triggers sender side to re-send.
(triple ACK, slow start and fast recovery, sliding window/receiving side and congestion window/sender side)


Like VxLAN, UDP comes to the rescue.
(Since it's unreliable protocol, send and forget)
QUIC also based on UDP.


Since UDP is unreliable, QUIC can build it's own flow-control/reliability base on UDP.

QUIC also uses TLS 1.3 to protect data and transport layer
(i.e protocol headers)


Drawbacks:
Since QUIC is deployed in user space, performance is a big issue(for now).
No DMA for NIC like TCP and other optimization tricks done for TCP.


Reference:
QUIC:
https://http3-explained.haxx.se/en/
https://www.fastly.com/blog/why-fastly-loves-quic-http3

QUIC Downsides discussion:
https://news.ycombinator.com/item?id=19461777

Kernel TLS:
https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/

TCP LSO:
https://en.wikipedia.org/wiki/Large_send_offload

HTTP Head-of-line blocking:
https://en.wikipedia.org/wiki/Head-of-line_blocking

HTTP pipelining:
https://en.wikipedia.org/wiki/HTTP_pipelining

HTTP/2 multiplexing:
https://stackoverflow.com/a/36519379
http://qnimate.com/what-is-multiplexing-in-http2/

[network][vxlan] wrap-up

rfc7348: https://tools.ietf.org/html/rfc7348

• VXLAN Tunnel End point(VTEP)
• Head-end Replication
• VxLAN MAC Distribution

( figure orig: http://underlays.blogspot.com/ )

Reference:
https://cn-blogs-prod-alln.cisco.com/datacenter/digging-deeper-into-vxlan
https://cn-blogs-prod-alln.cisco.com/datacenter/vxlan-deep-dive-part-2-looking-at-the-options
https://cn-blogs-prod-alln.cisco.com/datacenter/digging-deeper-in-vxlan-pt-3-more-faqs

[network] masking

Host IP + mask = result_1
Outgoing IP + mask = result_2

if result_1 != result_2
  send to IP routing process.
else
  send ARP obtain layer 2 MAC address.

[paper]Designing and Implementing a Deployable Multipath TCP

Presentation online:

Paper:
nsdi12-final125.pdf

Slides:
Designing and Implementing aDeployable Multipath TCP


Reference:

Multipath TCP Resources

IETF : Charter for Working Group

[network] Books reading

TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition) Kevin R. Fall did a great job in updating this classic book. The 2nd edition not only included IPv6, but updated lots of details in TCP congestion control, alone with ICMP infos. It also gives more details than the 1st edition and make this classic more clear than ever.
Unix Network Programming, Volume 1: The Sockets Networking API (3rd Edition) THE BEST book for network programming. Although there are many chapters talking about SCTP which I don't see else where using it(I am not encountering any, though), the book is GREAT in details.