bmullan/ciab.full-mesh.vpn.wireguard.frr.bgp.vxlan.internet.overlay.architecture

CIAB Full Mesh VPN Internet Overlay Implemented using Wireguard, FRR, BGP, BGP-VRFs, VXLAN and LXD VMs and Containers

ciab.full-mesh.vpn.wireguard.frr.bgp.vxlan.internet.overlay.architecture's Issues

Feature: Automating FRR network expansion

Thanks for your effort in making this demo. As well as making it open source.

I wonder if the following would work?

Appreciate any insights or suggestions.

It would seem to simplify the FRR configuration file, but also appear to make the CIAB network "grow" automagically as new nodes are added - the list of node in FRR config don't need to be updated which appears to be the case now.

Of course the WireGuard configuration would need to be updated, but one could work around this by configuring WG for the maximum expected number of nodes.

The same workaround (pre-listing all possible future IPs) is possible for FRR and this snippet seems to (from reading docs) eliminate the need for the FRR workaround.

router bgp 64512
  bgp router-id 172.20.10.193
  bgp cluster-id 172.20.10.193
  bgp log-neighbor-changes
  no bgp default ipv4-unicast
  neighbor ciab peer-group
  neighbor ciab remote-as 64512
  neighbor ciab capability extended-nexthop
  neighbor ciab update-source 172.20.10.193
  bgp listen range 172.20.10/24 peer-group ciab
  !
  address-family l2vpn evpn
   neighbor ciab activate
   neighbor ciab route-reflector-client
  exit-address-family
  !
!

This would replace the two sections with extensive listings:

neighbor 172.20.10.200 remote-as 64512
neighbor 172.20.10.147 remote-as 64512
neighbor 172.20.10.102 remote-as 64512
....
neighbor 172.20.10.200 route-reflector-client
neighbor 172.20.10.147 route-reflector-client
neighbor 172.20.10.102 route-reflector-client
neighbor 172.20.10.108 route-reflector-client

Hardening: neighbor <VTEP> remote-as <NNN> -> neighbor <VTEP> remote-as internal

From the FRR v7.5 docs:

neighbor PEER remote-as internal: Create a peer as you would when you specify an ASN, except that if the peers ASN is different than mine as specified under the router bgp ASN command the connection will be denied.

Similarly issue #2 should reflect this change.

Doc: FRR note in Step 10 belongs in Step 11

This note in step 10 appears to belong in step 11:

Note:  When you installed FRR in Step 2 it would have created /etc/frr

Doc: Description in context of service-meshes - cloud-meshnet

This needs more thought, but here is a first stab at trying to put this in a broader context. The aim is to help non-network developers appreciate the role of your approach by putting it in a context for which they already have a mental model of the technology (operations layer) and a mental model of the business (application layer).

Thinking in terms of the "Service-Mesh" (a fluid framework/definition), what is going on here is network layer counterpart - some degree of "Network-Mesh", say psuedo-meshnet, or quasi-meshnet in established network parlance.

Maybe a cloud-meshnet encapsulates both the domain, and the constraints that domain imposes. Any incompleteness in terms of a meshnet definition is not by design nor configuration choices, but rather is imposed by the constraints of the cloud environment.

Issue #2 allows the FRR managed layer to be dynamic.

WireGuard provides the peerless property but leaves the dynamic property to some external process(es) - the re-resolver scripts and services.

CIAB is a specific implementation of a cloud-meshnet.

This implementation is characterized by the choice of software stack and not by the functionality offered.

None the less, done properly, I think this should help contextualized and motivate a use case that is quite general: provide the "Service-Meshes" ( Istio, Linkerd, AWS App Mesh, HashiCorp Consul Connect, Open Service Mesh) a network layer that abstracts insecurely connected, ephemeral cloud instances running across cloud vendors wih heterogeneous cloud models and APIs.

Feature: Script distribution via release archives

Not sure if you'd be open to any PR's changing any of the following:

1. Extract scripts to scripts folder: Allows issue reports and PR's to the scripts.
2. Extract PDF to Markdown: Allows issue reports and PR's to the documentation, see issue #3.
3. Alter install instructions to download a release archive.

Doc: Step 10 - FRR instead of WireGuard

I think the FRR reference is a typo in step 10, where this:

Example:  Use vwgen to extract each Node’s FRR config file from the Master config file.

should be

Example:  Use vwgen to extract each Node’s WireGuard config file from the Master config file.

Doc: Define Layer 2 & 3 Network

These terms are used. It may be useful for readers who are not network-SME's have a succinct definition. Even if it is definition by example.
The inter-webs should have a existing one we can reference.

Doc: Github pages or some such

Progress on PoC can be viewed on the forked repo github pages.

https://bbros-dev.github.io/ciab

If the PR lands or is rejected I'll disable our forked github pages.

This should help lift the various search engine rankings.

VxLAN Network Model

Feature: Hardening BGP

Place holder to track initial scope and references.

Issues:

• Are there any standards guidance on the 'special'/private networks CIAB utilizes.
• What additional security/functionality is added for CIAB use cases - or is the value educational alone - which is enough (IMO).
  • [/] Route-Origin-Validation (ROV): RPKI
    • Without RPKI ".. deliberately or accidentally, networks are able to advertise more specific prefix routing information for address space controlled by other networks to their peers over BGP, which causes that traffic to flow through their network instead of to the intended recipient"[1]. No definite source that says BGP hard-codes protection for private address spaces against this type of "deliberately or accidentally" occurring event.
      • Use-case: In addition to external "deliberately or accidentally" occurring events; segmenting development/test/staging/production networks.
      • RPKI to Route (RTR) implementations:
        • Routinater: Recommended.[2]
        • RIPE NCC Validator
        • Cloudflare OktoRPKI
        • FORT
  • BGPSec
• MANRS: Mutually Agreed Norms for Routing Security
  • Review MANRS implementation guide for compliance and suggestions.

References:

• RPKI and BGPSec
• RPKI to Router (RTR): Routinator
• 1
• 2