Networks

Malicious node aware wireless multi hop networks: a systematic review of the literature and recommendations for future research

Wireless communication provides great advantages that are not available through their wired counterparts such as flexibility, ease of deployment and use, cost reductions, and convenience. Wireless multi-hop networks (WMN) do not have any centralized management infrastructure. Wireless multi-hop networks have many benefits since proposed. In such networks when a node wants to send a packet to a destination where is not in the transmission range, depend on some intermediate nodes. In this type of networks packet sending is in the form of multiple hop until destination and this work is dynamic. Lack of centralized management cause that some nodes show malicious function. Malicious nodes are that receive packets and drop them maliciously. These malicious nodes could have many reasons such as hardware failure, software failure or lack of power. Such nodes make multiple packets drop from the network and the performance of network strongly decreases. As a result, the throughput of the network decrease, increase end-to-end delay and increase overhead. Therefore, we must aware from presence of malicious node in the network and do routing based on this awareness. Therefore, this paper aims to study and review the present malicious node detection methods that proposed in literatures. We categorized networks in groups, including ad hoc networks, MANET, DTN, Opportunistic networks, WSN, VANET and other wireless networks and compare malicious node detection met

• dnsmadeeasy
• ddns rout53
• www.changeip.com

Wherever possible, we use RFC 2136, to the primary authoritative name server. pfSense firewalls, for example, support RFC 2136 for Dynamic DNS (tracking the WAN IP when DHCP changes it) and for Acme Certificates (demonstrate control of the FQDN). RFC 2136 is also a nice method for internal devices to get Let's Encrypt certs.

But you're not going to find RFC 2136 support very common. You probably won't find it on many NVR units or cheap Netgear routers.

Another from the email list (2022/04/22):

systemd-resolved is broken in many ways. I doubt it can forward correctly TSIG or SIG(0). If you have a proper DNS server running on your machine, there is not many reasons to run also systemd-resolved. If you need it, I suggest to write fixed /etc/resolv.conf pointing to 127.0.0.1 or ::1. Consider chattr +i /etc/resolv.conf afterwards. Do not use stub resolver provided by systemd if you have better caching server running on the same machine. I would even recommend to uninstall it on Fedora, where it is possible. Unless you use mdns on selected networks only, I don't think systemd-resolved provides you any benefit.

systemd-resolved strips in default configuration even DNSSEC signatures. I would doubt it can handle key signatures or even updates.

A solution:

    sudo systemctl disable systemd-resolved.service
    sudo service systemd-resolved stop

And then mask: systemd masking

From an email list 2022/04/21:

Geofeed is specified in RFC 8805. Finding and using Geofeed data is described in RFC 9092.

Example in the wild:

    $ whois -h whois.ripe.net 146.75.0.0 | fgrep geofeed:
    geofeed:        https://ip-geolocation.fastly.com/

Another example below, in this instance the geofeed information is stored in a 'remarks:' attribute. Unfortunately this particular RIR does not (yet?) properly support the native RPSL geofeed attribute for IPv6 /48 PI blocks.

    $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep geofeed
    remarks:        Geofeed https://sobornost.net/geofeed.csv

Both approaches work.

----

Besides geofeed, there are also geoidx records in IRRs but whether geolocation services actually use geofeed or geoidx remains to be seen. You can see some geoidx: at this IRR entry in TC: bgp.net example

----

A helpful resource: Geo & VPN Services - the RFC only works if they're pulling your feed and they'd only know that if you contact them in the first place.

----

• RFC 3693: Geopriv Requirements
• RFC 5870: A Uniform Resource Identifier for Geographic Locations
• RFC 6288: URN Namespace for the Defence Geospatial Information Working Group (DGIWG)
• RFC 6397: Multi-Threaded Routing Toolkit (MRT) BGP Routing Information Export Format with Geo-Location Extensions
• RFC 6772: Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
• RFC 7942: The GeoJSON Format
• RFC 8142: GeoJSON Text Sequences
• RFC 8805: A Format for Self-Published IP Geolocation Feeds
• RFC 9092: Finding and Using Geofeed Data

Heard on an email list:

There are public and commercial offerings for "DNS based protection".

e.g. 9.9.9.9 automatically generates NXDomains for suspected malicious DNS Names even in their free service.

They have a page where you can check if you have been blacklisted (see Threat blocking).

Seen on a mailing list, some comments regarding local preference vs MED.

Unfortunately, the reason crazy-long prepends actually propagate so widely in the internet core is because most of those decisions to prefer your peer's customers are done using a relatively big and heavy hammer.

> IOW if your peer or customer has prepended 5 times or more, dont LOCAL_PREF or maybe even de-LOCAL_PREF it

LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most of the networks out there seem to have settled on, to the point of having published BGP communities to use for controlling the LOCAL_PREF setting on received routes: https://onestep.net/communities/

I've long practiced, and advocated for, the use of MEDs or tweaking origin codes as a better way to nudge traffic towards customers, peers, customers of peers, etc., because it still allows as-path to be a factor in nudging traffic away. Prepend inbound 3 times on routes learned from your transit provider, but not on your peers, listen to MEDs from your peers, and enable always-compare-med and deterministic-med to allow values to be compared across different pathways.

That way, someone trying to say "don't use this path" can do a simple triple-prepend, and see their traffic shift. In our current world of using LOCAL_PREF, however, the poor customer keeps prepending more and more, and never sees their traffic shift. In desperation, they prepend the maximum number of times allowed, hoping that maybe this will somehow do the trick...not understanding that no matter what they do in the prepend realm, so long as their upstreams are using the LOCAL_PREF hammer, their prepends will fall on deaf ears.

For the most part--if you think LOCAL_PREF is the right knob to use for moving traffic, it probably means you need to go back and rethink your traffic engineering approach.

• Does One Need DHCP(v6)?
• Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

For future reference:

When writing a about DNSSEC, I need to reference the RFC. But it's three RFCs (4033, 4034, and 4035), and possibly another (6840). It would be awfully nice to refer to "DNSSEC" with a single reference like "BCP 250".

Negative Trust Anchors - https://datatracker.ietf.org/doc/rfc7646/

In case of DNSSEC validation failures, don't switch resolvers - https://datatracker.ietf.org/doc/draft-livingood-dnsop-dont-switch-resolvers/

Added 2022/04/11

BIND 9.16 has dnssec-policy that makes algorithm rollover much easier. I recommend you start using that. Read more on migrating to dnssec-policy here: DNSSEC Key and Signing Policy

Additional links:

• bind9 DNSSEC Guide

Added 2022/05/05 - DNSSEC algorithm rollover HOWTO - some notes on how to upgrade a zone's DNSSEC algorithm using BIND.

A Survey on DNS Encryption: Current Development, Malware Misuse, and Inference Techniques

The domain name system (DNS) that maps alphabetic names to numeric Internet Protocol (IP) addresses plays a foundational role for Internet communications. By default, DNS queries and responses are exchanged in unencrypted plaintext, and hence, can be read and/or hijacked by third parties. To protect user privacy, the networking community has proposed standard encryption technologies such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) for DNS communications, enabling clients to perform secure and private domain name lookups. We survey the DNS encryption literature published since 2016, focusing on its current landscape and how it is misused by malware, and highlighting the existing techniques developed to make inferences from encrypted DNS traffic. First, we provide an overview of various standards developed in the space of DNS encryption and their adoption status, performance, benefits, and security issues. Second, we highlight ways that various malware families can exploit DNS encryption to their advantage for botnet communications and/or data exfiltration. Third, we discuss existing inference methods for profiling normal patterns and/or detecting malicious encrypted DNS traffic. Several directions are presented to motivate future research in enhancing the performance and security of DNS encryption.

Full replacement of existing branch office functionality: Modern branch routers provide a wide range of functionality include QoS, IPSec VPNs, dynamic routing, NetFlow, SNMP, logs, access control lists, event management, support for protocols like BGP and OSPF. The SD-WAN needs to be able to do all of that, plus.

Transport Independence: The SD-WAN should be able to leverage high-speed bandwidth across multiple transports, including MPLS, Internet, 3G/4G/LTE and 5G.

Path control: The ability to use multiple active paths for bandwidth efficiency, resiliency and failover is critical. The system needs to be able to dynamically steer traffic based on policies in response to changing network conditions, such as packet loss, latency, and jitter.

Application Optimization: The true benefit of SD-WAN is the ability to optimize application performance. The systems must be able to recognize all of the applications in my portfolio and be able to actively monitor application performance as traffic moves across the WAN, including voice and video traffic, as well as SaaS applications.

Encryption: If you’re reducing reliance on VPN technology, the SD-WAN must be able to encrypt WAN traffic based on policy. In addition, automated key rotation is important so that encryption keys can be swapped out on a regular basis?

Security: Since the SD-WAN topology now connects the branch office directly with the public Internet (rather than funneling traffic back to the central office), security must be distributed to each branch office site. Look for an integrated next-generation, application-aware firewall that offers anti-virus, anti-malware, URL/content filtering, data loss prevention, segmentation, IDS/IPS, and sandboxing.

Zero-touch deployment: With zero-touch deployment, an SD-WAN box can be sent out to a branch office and a non-technical person can simply connect it to power and the WAN links, and the device will phone home and configure itself.

Automation and Orchestration: Management of SD-WAN services should be automated, and the overlay software should be able to orchestrate monitoring, troubleshooting, reporting, and other functions across the entire WAN.

Microsegmentation: Opening up two-way traffic between the Internet and branch offices creates a potential security vulnerability in which an attacker gains access to a branch office device and uses that as a launching pad to attack data center resources. Microsegmentation allows the company to restrict hacker movement by limiting lateral movement.

Service Chaining: Centralized models and de-centralized models each have their pros and cons. SD-WAN replaces the centralized MPLS model, but it does create a level of complexity because now the enterprise is managing so many distributed devices, each handling multiple functions. Service chaining is a middle ground technique that enables enterprises to re-route and aggregate traffic in order to reduce branch office clutter and improve efficiency. For example, a company could use the SD-WAN for routing and optimization, but send traffic to a cloud-based service provider who handles all of the security functionality before allowing traffic to hit the open Internet.

For many companies, implementing SD-WAN is part of a larger digital transformation initiative that moves application development functions, mission critical applications, storage, backups, disaster recovery, and data analytics in the cloud. SD-WAN is focused on giving branch office employees a way to access those cloud resources quickly, securely and efficiently. But the industry is moving onto a broader product category called SASE, or secure access service edge, which puts more functionality directly in the cloud and enables secure access from all endpoints, including home offices.

Another way to think of a SASE architecture is that it combines SD-WAN with cloud access security brokers (CASB), firewalls-as-a-service (FWaaS) and Zero Trust network access in a cloud-based service.

From SD-WAN buyers guide: Key questions to ask vendors (and yourself)

Design of a Scalable 4G Portable Network Using Low Cost SDR And Raspberry Pi

Of late, Software Defined Radio (SDR) approach has become an effective means to design high data rate wireless systems for a range of applications. There are methods with which low cost SDR based 4th generation (4G) or long term evolution (LTE) systems can be designed. Using low cost Raspberry Pi systems, the SDR aided 4G systems can be designed for high data rate communication. The work is related to the design of a 4G wireless system using low cost SDR solutions and integrated to a programmable controller based on a Raspberry Pi. Experimental results show that the system is effective in a range of conditions.

ORPHEUS: Living Labs for End-to-End Data Infrastructures for Digital Agriculture

IoT networks are being used to collect, analyze, and utilize sensor data. There are still some key requirements to leverage IoT networks in digital agriculture, e.g., design and deployment of energy saving and ruggedized sensor nodes (SN), reliable and long-range wireless network connectivity, end-to-end data collection pipelines for batch and streaming data. Thus, we introduce our living lab ORPHEUS and its design and implementation trajectory to showcase our orchestrated testbed of IoT sensors, data connectivity, database orchestration, and visualization dashboard. We deploy light-weight energy saving SNs in the field to collect data, using LoRa (Long Range wireless) to transmit data from the SNs to the Gateway node, upload all the data to the database server, and finally visualize the data. For future exploration, we also built a testbed of embedded devices using four different variants of NVIDIA Jetson development modules (Nano, TX2, Xavier NX, AGX Xavier) to benchmark the potential upgrade choices for SNs in ORPHEUS. Based on our deployment in multiple farms in a 3-county region around Purdue University, and on the Purdue University campus, we present analyses from our living lab deployment and additional components of the next-generation IoT farm.

Multi-sided Matching for the Association of Space-Air-Ground Integrated Systems

Space-air-ground integrated networks (SAGINs) will play a key role in 6G communication systems. They are considered a promising technology to enhance the network capacity in highly dense agglomerations and to provide connectivity in rural areas. The multi-layer and heterogeneous nature of SAGINs necessitates an innovative design of their multi-tier associations. We propose a modeling of the SAGINs association problem using multi-sided matching theory. Our aim is to provide a reliable, asynchronous and fully distributed approach that associates nodes across the layers so that the total end-to-end rate of the assigned agents is maximized. To this end, our problem is modeled as a multi-sided many-to-one matching game. A randomized matching algorithm with low information exchange is proposed. The algorithm is shown to reach an efficient and stable association between nodes in adjacent layers. Our simulation results show that the proposed approach achieves significant gain compared to the greedy and distance-based algorithms.

Moving the Network to the Cloud: the Cloud Central Office Revolution and its Implications for the Optical Layer

SDN and NFV have recently changed the way we operate networks. By decoupling control and data plane operations and virtualising their components, they have opened up new frontiers towards reducing network ownership costs and improving usability and efficiency. Recently, their applicability has moved towards public telecommunications networks, with concepts such as the cloud-CO that have pioneered its use in access and metro networks: an idea that has quickly attracted the interest of network operators. By merging mobile, residential and enterprise services into a common framework, built around commoditised data centre types of architectures, future embodiments of this CO virtualisation concept could achieve significant capital and operational cost savings, while providing customised network experience to high-capacity and low-latency future applications. This tutorial provides an overview of the various frameworks and architectures outlining current network disaggregation trends that are leading to the virtualisation/cloudification of central offices. It also provides insight on the virtualisation of the access-metro network, showcasing new software functionalities like the virtual \ac{DBA} mechanisms for \acp{PON}. In addition, we explore how it can bring together different network technologies to enable convergence of mobile and optical access networks and pave the way for the integration of disaggregated ROADM networks. Finally, this paper discusses some of the open challenges towards the realisation of networks capable of delivering guaranteed performance, while sharing resources across multiple operators and services.

Commodity Wi-Fi Sensing in 10 Years: Current Status, Challenges, and Opportunities

The prevalence of WiFi devices and ubiquitous coverage of WiFi networks provide us the opportunity to extend WiFi capabilities beyond communication, particularly in sensing the physical environment. In this paper, we survey the evolution of WiFi sensing systems utilizing commodity devices over the past decade. It groups WiFi sensing systems into three main categories: activity recognition (large-scale and small-scale), object sensing, and localization. We highlight the milestone work in each category and the underline techniques they adopted. Next, this work presents the challenges faced by existing WiFi sensing systems. Lastly, we comprehensively discuss the future trending of commodity WiFi sensing.

• USGv6-Revision-1 to define the specification
• USGv6 Tested Registry

A while ago, there is/was an article called Gartner Says SDN Has Left the Building – Say Hello to Network Automation. I'm wondering if that is a patato/potato semantics problem: both things say the same thing. Mostly.

One might say that SDN (Software Defined Network) may have been shoehorned into a corner with the era associated technologies such as OpenFlow and the heavy Java tooling used to manage it.

In a similar vein, Network Automation has, in my mind, mostly simple meaning: push out configs programmatically rather than pounding them in with a keyboard. At that level, conceptually you have the identical problem of managing individual configs, but having a faster way of doing things. It does provide config version control management from a push perspective rather than a post gatherer with Rancid.

On the other hand, in the comments following the article, there was a third addition to the typical data/control plane terms: management plane. It is in the management plane where the fun begins. And this isn't in terms of human managers, this is in the auto-collection of network wide data to automatically define operational configurations for devices which push packets. Google's network is such an animal: with metrics backfeeding configuration, they can reach link utilization of over 90% without congestion issues.

NAT exists in IPv6:

• IPv6-to-IPv6 Network Prefix Translation exists (RFC 6296, June 2011).

NATing between IPv6 and IPv4:

• Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (RFC 6146, April 2011)
• Mapping of Address and Port using Translation (MAP-T) (RFC 7599, July 2015)

Delivering a virtual IPv4 link over IPv6:

• Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (RFC 6333, August 2011)
• 464XLAT: Combination of Stateful and Stateless Translation (RFC 6877, April 2013)
• Mapping of Address and Port with Encapsulation (MAP-E) (RFC 7597, July 2015)

As for firewalls see:

• Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (RFC 6092, January 2011)
• Thousands of ISP’s are using these RFCs to deliver working IPv4 and IPv6 to their customers today. Often the customer doesn’t even know they are using them.

If you don’t want to do a forklift upgrade deploy routers which support these RFCs as the old ones die and slowly migrate to a IPv6-only IPV4AAS model. Nobody has ever said that forklift upgrades where required.

Seen 2021/09/14 mailing list

• cloudflare 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
• comodo: 8.26.56.26 8.20.247.20
• dyn: 216.146.35.35 216.146.36.36
• google: 8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
• level3: 4.2.2.2 4.2.2.1
• norton: 199.85.126.10 199.85.127.10
• opendns: 208.67.222.222 208.67.220.220
• quad9: 9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9
• ultradns: 156.154.71.1 156.154.70.1

A reference to Open DNS Resolvers, whether they are meant to be or not: public-dns.info

Another interesting resolvers.

And from a definition perspective: wikipedia.

Unrelated, but kinda a DNS question:

Is there a tool that would allow me to identify all the DNS servers on our networks that are using dnsmasq?

Response: github.com/kirei/fpdns, which was derived in reference to determining versions of DNSMasq due to the dnspooq attack.