GRE over IPsec

Point-to-Point Generic Routing Encapsulation over IP Security

 

gre network

 

Generic Routing Encapsulation

Generic Routing Encapsulation (GRE) is a widely used encapsulation protocol in computer networking. It allows the transmission of diverse network protocols over an IP network infrastructure. In this blog post, we’ll delve into the details of the GRE and its significance in modern networking.

GRE acts as a tunneling protocol, encapsulating packets from one network protocol within another. By creating a virtual point-to-point link, it facilitates the transmission of data across different network domains. This enables the interconnection of disparate networks, making GRE a crucial tool for securely building virtual private networks (VPNs) and connecting remote sites.

 

  • GRE Operation

GRE is a layer 3 protocol, meaning it works at the IP level of the network. It enables a router to encapsulate packets of a particular protocol and send them to another router, decapsulated and forwarded to their destination. This is useful for tunneling, where data must traverse multiple networks and different types of hardware.

GRE encapsulates data in a header containing information about the source, destination, and other routing information. The GRE header is then encapsulated in an IP header containing the source and destination IP addresses. When the packet reaches the destination router, the GRE header is stripped off, and the data is sent to its destination.

  • IPsec site-to-site

An IPsec site-to-site VPN, also known as a gateway-to-gateway VPN, is a secure tunnel established between two or more remote networks over the internet. It enables organizations to connect their geographically dispersed offices, data centers, or even cloud networks, creating a unified and secure network infrastructure. By leveraging IPsec, organizations can establish secure communication channels, ensuring confidentiality, integrity, and authentication of transmitted data.

 

 

Before you proceed, you may find the following posts helpful for pre-information:

  1. Dead Peer Detection
  2. IPsec Fault Tolerance
  3. Dynamic Workload Scaling 
  4. Cisco Switch Virtualization
  5. WAN Virtualization
  6. VPNOverview

 

GRE Network

Key Generic Routing Encapsulation Discussion Points:


  • Introduction to Generic Routing Encapsulation and what is involved.

  • Highlighting the details of a GRE network with Head-end architecture

  • .Critical points on the GRE over IPsec

  • Technical details on branch design guides.

 

  • A key point: Video on multi-cloud. An IPsec use case.

The following video you may find helpful is on the multi-cloud. Connecting to the cloud and in multi-cloud scenarios may call for protection with IPsec protection. What differentiates the hybrid cloud from the public & private cloud is the data flow between public and private resources. And Multi-Cloud is a particular case of hybrid cloud computing. One connection method to a multi-cloud could be IPsec tunnels.

 

Technology Brief : Cloud Computing - Introducing Multicloud
Prev 1 of 1 Next
Prev 1 of 1 Next

 

  • A key point: Lab guide on IPsec site to site

In this lesson, we have two Cisco IOS routers to use IPSec in Tunnel mode. This means the original IP packet will be encapsulated in a new IP packet and encrypted before sending it out of the network. For this demonstration, I will be using the following three routers.

R1 and R3 each have a loopback interface behind them with a subnet. We’ll configure the IPsec tunnel between these routers to encrypt traffic from 1.1.1.1/32 to 3.3.3.3/32. R2 is just a router in the middle, so R1 and R3 are not directly connected.

Notice with information 1 we can’t ping the remote LAN. However, once the IPsec tunnel is up, we have reachability. Under the security associations, with have 4 packets that have been encapsulated and encapsulated. However, I sent 5 pings. The first packet is lost to ARP.

ipsec tunnel
Diagram: IPsec Tunnel

 

IPsec relies on encryption and tunneling protocols to establish a secure connection between networks. The two primary components of IPsec are the IPsec tunnel mode and the IPsec transport mode. In tunnel mode, the entire IP packet is encapsulated within another IP packet, adding an extra layer of security. In contrast, the transport mode only encrypts the payload of the IP packet, leaving the original IP header intact.

To initiate a site-to-site VPN connection, the IPsec VPN gateway at each site performs a series of steps. These include negotiating the security parameters, authenticating the participating devices, and establishing a secure tunnel using encryption algorithms such as AES (Advanced Encryption Standard) or 3DES (Triple Data Encryption Standard). Once the tunnel is established, all data transmitted between the sites is encrypted, safeguarding it from unauthorized.

 

Back to basic with GRE tunnels

What is a GRE tunnel?

A GRE tunnel supplies connectivity to a wide variety of network layer protocols. GRE works by encapsulating and forwarding those packets over an IP-based network. The authentic use of GRE tunnels provided a transport mechanism for non-routable legacy protocols such as DECnet and IPX. With GRE, we add header information to a packet when the router encapsulates the packet for transit on the GRE tunnel.

The new header information contains the remote endpoint IP address as the destination. The new IP headers permit the packet to be routed between the two tunnel endpoints, and this is done without inspection of the packet’s payload.

After the packet reaches the remote endpoint, the GRE termination point, the GRE headers are removed, and the original packet is forwarded from the remote router. Both GRE and IPsec tunnels are used in solutions for SD WAN SASE and SD WAN Security. Both of these solutions would abstract the complexity of configuring these technologies.

 

GRE Operation

GRE operates by encapsulating the original packet with a GRE header. This header contains information such as the source and destination IP addresses and additional fields for protocol identification and fragmentation support. Once the packet is encapsulated, it can be transmitted over an IP network, effectively hiding the underlying network details.

When a GRE packet reaches its destination, the receiving end decapsulates it, extracting the original payload. This process allows the recipient to receive the data as if it were sent directly over the underlying network protocol. GRE is a transparent transport mechanism, enabling seamless communication between disparate networks.

 

GRE Tunnel
Diagram: GRE tunnel example. Source is heficed

 

  • Topologies and routing protocol support

Numerous technologies connect remote branch sites to HQ or central hub. P2P Generic Routing Encapsulation ( GRE network ) over IPsec is an alternative design to classic WAN technologies like ATM, Frame Relay, and Leased lines. GRE over IPsec is a standard deployment model to connect several remote branch sites to one or more central sites. Design topologies include the hub-and-spoke, partial mesh, and full mesh.

Both partial and full-mesh topologies experience limitations in routing protocol support. A full mesh design is limited by the overhead required to support a design with a full mesh of tunnels. Following a complete mesh requirement, a popular design option would be to deploy DMVPN. Regarding the context of direct connectivity from branch to hub only, hub-and-spoke is by far the most common design.

 

  • A key point: Lab guide with DMVPN and GRE

The lab guide below shows a DMVPN network based on Generic Routing Encapsulation (GRE). So, GRE is the overlay. Specifically, we use GRE in point-to-point mode, which means deploying DMVPN Phase 1, a true VPN hub and spoke design, where all traffic from the spokes must go via the hub. With the command: show dmvpn, we can see that two spokes are dynamically registered over the GRE tunnel, notice the “D” attribute.

The beauty of using DMPVN as a VPN technology is that the hub site does not need a specific spoke configuration as it uses GRE in multi-point mode. On the other hand, the spokes need to have a hub configuration with the command: IP nhrp nhs 192.168.100.11. IPsec encryption is optional with DMVPN. In the other command snippet, we are running IPsec encryption with the command: tunnel protection ipsec profile DMVPN_IPSEC_PROFILE.

 

DMVPN configuration
Diagram: DMVPN Configuration.

One of the primary use cases of GRE is in creating VPNs. Organizations can securely transmit data across public networks such as the internet by encapsulating traffic within GRE packets. This provides a cost-effective solution for connecting geographically dispersed sites without requiring dedicated leased lines.

Another use of GRE is in network virtualization. By leveraging GRE tunnels, it is possible to create virtual networks isolated from the underlying physical infrastructure. This allows for more efficient resource utilization and improved network scalability.

 

  • DMVPN (Dynamic Multipoint VPN)

DMVPN is based on the principle of dynamic spoke-to-spoke tunneling, allowing for dynamic routing and scalability. It also provides the ability to create a dynamic mesh topology, allowing for multiple paths between remote sites. This allows for increased redundancy and improved performance.

DMVPN also offers the ability to establish a secure tunnel over an untrusted network, such as the Internet. This is achieved with a series of DMVPN phases. DMVPN phase 3 offers better flexibility by using IPSec encryption and authentication, ensuring that all traffic sent over the tunnel is secure. This makes DMVPN an excellent choice for businesses connecting multiple sites over an unsecured network.

Dynamic Multipoint VPN
Diagram: Example with DMVPN. Source is Cisco

 

  • A key point: Video on DMVPN configuration

In this technical demonstration, we will start with the core block of DMVPN, GRE. Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco Systems that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links or point-to-multipoint links over an Internet Protocol network.

 

Cisco DMVPN Configuration
Prev 1 of 1 Next
Prev 1 of 1 Next

 

GRE Network: Head-end Architecture 

Single-tier and dual tier

Head-end architectures include a single-tier head-end where the point-to-point GRE network and crypto functionality co-exist on the same device. Dual-tier designs are where the point-to-point GRE network and crypto functionality are not implemented on the same device. Dual tier designs, the routing and GRE control planes are located on one device while the IPsec control plane is housed on another.

what is generic routing encapsulation
Diagram: What is generic routing encapsulation?

 

Headend

Router

Crypto

Crypto IP

GRE  

GRE IP

Tunnel Protection

Single Tier

Headend

Static or Dynamic

Static

p2p GRE static

Static

Optional 


Branch

Static

Static or Dynamic

p2p GRE static

Static

Optional 

Dual Tier

Headend

Static or Dynamic

Static

p2p GRE static

Static

Not Valid


Branch

Static

Static or Dynamic

p2p GRE static

Static

Not Valid

 

“Tunnel protection” requires the same source and destination IP address for the GRE and crypto tunnels. Implementations of dual-tier separate these functions, resulting in the different IP addresses for the GRE and crypto tunnels. Tunnel protection is invalid with dual-tier mode.

 

GRE over IPsec

GRE (Generic Routing Encapsulation) is a tunneling protocol that encapsulates multiple protocols within IP packets, allowing the transmission of diverse network protocols over an IP network. On the other hand, IPSEC (IP Security) is a suite of protocols that provides secure communication over IP networks by encrypting and authenticating IP packets. Combining these two protocols, GRE over IPSEC provides a secure and flexible solution for transmitting network traffic over public networks.

Benefits of GRE over IPSEC:

Secure Data Transmission:

By leveraging IPSEC’s encryption and authentication capabilities, GRE over IPSEC ensures the confidentiality and integrity of data transmitted over the network. This is particularly crucial when transmitting sensitive information, such as financial data or personal records.

Network Scalability:

GRE over IPSEC allows organizations to create virtual private networks (VPNs) by establishing secure tunnels between remote sites. This enables seamless communication between geographically dispersed networks, enhancing collaboration and productivity.

Protocol Flexibility:

GRE over IPSEC supports encapsulating various network protocols, including IPv4, IPv6, and multicast traffic. This flexibility enables the transmission of diverse data types, ensuring compatibility across different network environments.

 

Preliminary design considerations

Diverse multi-protocol traffic requirements force the use of a Generic Routing Encapsulation ( GRE ) envelope within the IPsec tunnel. The p2p GRE tunnel is encrypted inside the IPsec crypto tunnel. Native IPsec is not multi-protocol and lacks IP multicast or broadcast traffic support. As a result, proper propagation of routing protocol control packets cannot occur in a native IPsec tunnel.

However, OSPF design cases allow you to run OSPF network type non-broadcast and explicitly configure the remote OSPF neighbors, resulting in OSPF over the IPsec tunnel without GRE. With a GRE over IPsec design, all traffic between hub and branch sites is first encapsulated in the p2p GRE packet before encryption.

GRE over IPsec
Diagram: GRE over IPSec.

 

GRE over IPSec Key Points

Redundancy

Redundant designs are implemented with the branch having two or more tunnels to the campus head. The head-end routers can be geographically separated or co-located. Routing protocols are used with redundant tunnels providing high availability with dynamic path selection.

The head-end router can propagate a summary route ( 10.0.0.0/8 ) or a default route ( 0.0.0.0/0 ) to the branch sites, and a preferred routing metric will be used for the primary path. If OSPF is RP, the head-end selection is based on OSPF costs.

 

Recursive Routing

Each branch must add a static route to their respective ISP IP addresses for each head-end. The static avoids recursive routing through the p2p GRE tunnel. Recursive routing occurs when the route to the GRE tunnel source outside the IP address of the opposing router is learned via a route with a next-hop of the inside IP address of the opposing p2p GRE tunnel. Recursive routing causes the tunnel to flap and the p2p GRE packets to route into their p2p GRE tunnel. To overcome recursive routing, my best practice is to ensure that the outside tunnel is routed directly to ISP instead of inside the p2p GRE tunnel.

 

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

 

Recursive routing and outbound interface selection pose significant challenges in tunnel or overlay networks. Therefore, routing protocols should be used with utmost caution over network tunnels. A router can encounter problems if it attempts to reach the remote router’s encapsulating interface (transport IP address) via the tunnel. Typically, this issue occurs when the transport network is advertised into the same routing protocol as the overlay network.

Routers learn the destination IP address for tunnel interfaces through recursive routing. First, the IP address of the tunnel’s destination is removed from the routing table, making it unreachable.

 

Split tunneling

If the head-end advertises a summary route to the branch, split tunneling is enabled on all packets not destined for the summary. Any packets not destined for the summary are split-tunneled to the Internet. For example, split tunneling is not used for the branch sites in a design where the head-end router advertises a default route ( 0.0.0.0/0 ) through the p2p GRE tunnel.

 

  • A key point: Additional information on Split tunneling.

Split tunneling is a networking concept allowing users to selectively route traffic from their local device to a local or remote network. It gives users secure access to corporate networks and other resources from public or untrusted networks. Split tunneling can also be used to reduce network congestion. For example, if a user is on a public network and needs to access a resource on a remote network, the user can set up a split tunnel to send only the traffic that needs to go over the remote network. This reduces the traffic on the public network, allowing it to perform more efficiently.

 

Control plane

Routing protocol HELLO packets initiated from the branch office force the tunnel to establish—routing protocol control plane packets to maintain and keep the tunnel up. HELLO, packets provide a similar function to GRE keepalives. Routing protocol HELLO operates at Layer 3, and GRE keepalives at Layer 2.

 

Branch router considerations

The branch router can have p2p GRE over IPSEC with a static or dynamic public address. The GRE and crypto tunnels are sourced from a static address with a static public IP address. With dynamic address allocation, the GRE is sourced from a loopback address privately assigned (non-routable), and the crypto tunnel is sourced from a dynamically assigned public IP address.

 

Generic routing encapsulation

Key design points

Summary of key design points

  • Deploy IPsec in tunnel mode for flexibility with NAT. The default Tunnel mode adds 20 bytes to the total packet size. However, the transport mode does not work when the crypto tunnel transitions to either a NAT or PAT device.

  • With GRE IPsec tunnel mode, the entire GRE packet ( which includes the original IP header packet ) is encapsulated and encrypted. No part of the GRE tunnel is exposed.

  • Use routing protocols for dynamic redundancy but scaling routing protocols can affect CPU overhead. Keep in mind a higher-end limit to the number of routing protocol peers.

  • Implement GRE for routing protocol support. For example, GRE requires that additional headers are added to the beginning of each packet; the header must also be encrypted, affecting the router's performance.

  • GRE is stateless and, by default, offers limited flow control mechanisms.

  • Configure redundant tunnels for high availability but with scalability limitations. For example, P2P GRE is limited to 2047 tunnels with VPN SPA and 2000 tunnels with SUP720.

  • Implement Triple DES ( 3DES ) or AES for encryption of transmitted data. Even considering AES has a wider key length, there is little or no variation in the performance of these.

  • Implement Dead Peer Detection ( DPD ) to detect loss of ISAKMP peer. Alternatively, IPSEC tunnel protection can be considered for single-tier head architecture.

  • Hardware-accelerated encryption is useful to protect the router's CPU from intensive processing.

  • Set the local Maximum Transmission Unity ( MTU ) and Path MTU to minimize fragmentation.

  • For a small number of sites, one can use pre-shared keys for tunnel authentication. However, large deployments look into Digital Certificates / PKI.

  • Keep CPU at head-end and branch sites around the 65% - 80% mark.

 

generic routing encapsulation

ip routing

Advances of IP routing and Cloud

 

ip routing

 

With the introduction and hype around Software Defined Networking ( SDN ) and Cloud Computing, one would assume that there has been little or no work with the advances in IP routing. You could say that the cloud has clouded the mind of the market. Regardless of the hype around this transformation, routing is still very much alive and makes up a vital part of the main internet statistics you can read. Packets still need to get to their destinations.

 

Advanced in IP Routing

The Internet Engineering Task Force (IETF) develops and promotes voluntary internet standards, particularly those that comprise the Internet Protocol Suite (TCP/IP). The IETF shapes what comes next, and this is where all the routing takes place. It focuses on anything between the physical layer and the application layer. It doesn’t focus on the application itself, but on the technologies used to transport it, for example, HTTP.

In the IETF, no one is in charge, anyone can contribute, and everyone can benefit. As you can see from the chart below, that routing ( RTG ) has over 250 active drafts and is the most popular working group within the IETF.

 

 

IP routinng
Diagram: IETF Work Distribution.

 

The routing area is responsible for ensuring the continuous operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols and developing new protocols, extensions, and bug fixes promptly

The following table illustrates the subgroups of the RTG working group:

Bidirectional Forwarding Detection (BFD) Open Shortest Path First IGP (OSPF)
Forwarding and Control Element Separation (forces) Routing Over Low power and Lossy networks (roll)
Interface to the Routing System (i2rs) Routing Area Working Group (RTGW)
Inter-Domain Routing (IDR) Secure Inter-Domain Routing (SCIDR)
IS-IS for IP Internets (isis) Source Packet Routing in Networking (spring)
Keying and Authentication for Routing Protocols (Karp)
Mobile Ad-hoc Networks (manet)

The chart below displays the number of drafts per subgroup of the routing area. There has been a big increase in the subgroup “roll,” which is second to BGP. “Roll” relates to “Routing Over Low power and Lossy networks” and is driven by the Internet of Everything and Machine-to-Machine communication.

 

IP ROUTING
Diagram: RTG Ongoing Work.

 

OSPF Enhancements

OSPF is a link-state protocol that uses a common database to determine the shortest path to any destination.

Two main areas of interest in the Open Shortest Path First IGP (OSPF) subgroups are OSPFv3 LSA Extendibility and Remote Loop-Free Alternatives ( LFAs ). One benefit IS-IS has over OSPF is its ability to easily introduce new features with the inclusion of Type Length Values ( TLVs ) and sub-TLVs. The IETF draft-IETF-OSPF-ospfv3-lsa-extend extends the LSA format by allowing the optional inclusion of TLVs, making OSPF more flexible and extensible. For example, OSPFv3 uses a new TLV to support intra-area Traffic Engineering ( TE ), while OSPFv2 uses an opaque LSA.

 

TLV for OSPFv3
Diagram: TLV for OSPFv3.

 

Another shortcoming of OSPF is that it does not install a backup route in the routing table by default. Having a pre-installed backup up path greatly improves convergence time. With pre-calculated backup routes already installed in the routing table, the router process does not need to go through the convergence process’s LSA propagation and SPF calculation steps.

 

Loop-free alternatives (LFA)

Loop-Free Alternatives ( LFA ), known as Feasible Successors in EIGRP, are local router decisions to pre-install a backup path.
In the diagram below:

-Router A has a primary ( A-C) and secondary ( A-B-C) path to 10.1.1.0/24
-Link State allows Router A to know the entire topology
-Router A should know that Router B is an alternative path. Router B is a Loop-Free Alternate for destination 10.1.1.0/24

OSPF LFA
Diagram: OSPF LFA.

 

This is not done with any tunneling, and the backup route needs to exist for it to be used by the RIB. If the second path doesn’t exist in the first place, the OSPF process cannot install a Loop-Free Alternative. The LFA process does not create backup routes if they don’t already exist. An LFA is simply an alternative loop-free route calculated at any network router.

A drawback of LFA is that it cannot work in all topologies. This is most notable in RING topologies. The answer is to tunnel and to get the traffic past the point where it will loop. This effectively makes the RING topology a MESH topology. For example, the diagram below recognizes that we must tunnel traffic from A to C. The tunnel type doesn’t matter – it could be a GRE tunnel, an MPLS tunnel, an IP-in-IP tunnel, or just about any other encapsulation.

 

In this network:

-Router A’s best path through E
-Routers C’s best path is through D
-Router A must forward traffic directly to C to prevent packets from looping back.

Remote LFA
Diagram: Remote LFA.

 

In the preceding example, we will look at “Remote LFA,” which leverages an MPLS network and Label Distribution Protocol ( LDP ) for label distribution. If you use Traffic Engineering ( TE ), it’s called “TE Fast ReRoute” and not “Remote LFA.” There is also a hybrid model combining Remote LFA and TE Fast ReRoute, and is used only when the above cannot work efficiently due to a complex topology or corner case scenario.

Remote LFAs extend the LFA space to “tunneled neighbors”.

– Router A runs a constrained SPF and finds C is a valid LFA

– Since C is not directly connected, Router A must tunnel to C

a) Router A uses LDP to configure an MPLS path to C

b) Installs this alternate path as an LFA in the CEF table

– If the A->E link fails.

a) Router A begins forwarding traffic along the LDP path

The total time for convergence usually takes 10ms.

Remote LFA has some topology constraints. For example, they cannot be calculated across a flooding domain boundary, i.e., an ABR in OSPF or L1/L2 boundary is IS-IS. However, they work in about 80% of all possible topologies and 90% of production topologies.

 

BGP Enhancements

BGP is a scalable distance vector protocol that runs on top of TCP. It uses a path algorithm to determine the best path to install in the IP routing table and for IP forwarding.

 

Recap BGP route advertisement:

  • RR client can send to a RR client.
  • RR client can send to a non RR client.
  • A non-RR client cannot send to a non-RR client.

One drawback to the default BGP behavior is that it only advertises the best route. When a BGP Route Reflector receives multiple paths to the same destination, it will advertise only one of those routes to its neighbors.

This can limit the visibility in the network and affect the best path selection used for hot potato routing when you want traffic to leave your AS as quickly as possible. In addition, all paths to exit an AS are not advertised to all peers, basically hiding ( not advertising ) some paths to exit the network.

The diagram below displays default BGP behavior; the RR receives two routes from PE2 and PE3 about destination Z; due to the BGP best path mechanism, it only advertises one of those paths to PE1. 

Route Reflector - Default
Diagram: Route Reflector – Default.

 

In certain designs, you could advertise the destination CE with different Route Distinguishers (RDs), creating two instances for the same destination prefix. This would allow the RR to send two paths to PE.

 

Diverse BGP path distribution

Another new feature is diverse BGP Path distribution, where you can create a shadow BGP session to the RR. It is easy to deploy, and the diverse iBGP session will announce the 2nd best path. Shadow BGP sessions are especially useful in virtualized deployments, where you can create another BGP session to a VM acting as a Route-Reflector. The VM can then be scaled out in a virtualized environment creating numerous BGP sessions. You are allowing the advertisements of multiple paths for each destination prefix.

Route Reflector - Shadow Sessions
Diagram: Route Reflector – Shadow Sessions.

 

BGP Add-path 

A special extension to BGP known as “Add Paths” allows BGP speakers to propagate and accept multiple paths for the same prefix. The BGP Add-Path feature will signal diverse paths, so you don’t need to create shadow BGP sessions. There is a requirement that all Add-Path receiver BGP routers must support the Add-Path capability.

There are two flavors of the Add-Path capability, Add-n-path, and Add-all-path. The “Add-n-path” will add 2 or 3 paths depending on the IOS version. With “Add-all-path,” the route reflector will do the primary best path computation (only on the first path) and then send all paths to the BR/PE. This is useful for large ECMP load balancing, where you need multiple existing paths for hot potato routing.

BGP Add Path
Diagram: BGP Add Path

 

Source packet routing

Another interesting draft the IETF is working on is Source Packet Routing ( spring ). Source Packet Routing is the ability of a node to specify a forwarding path. As the packet arrives in the network, the edge device looks at the application, determines what it needs, and predicts its path throughout the network. Segment routing leverages the MPLS data plane, i.e., push, swap, and pop controls, without needing LDP or RSVP-TE. This avoids millions of labels in the LDP database or TE LSPs in the networks.

 

Application Controls - Network DeliversDiagram: Application Controls – Network Delivers 

The complexity and state are now isolated to the network’s edges, and the middle nodes are only swapping labels. The source routing is based on the notion of a 32-bit segment that can represent any instructions, such as service, context, or IGP-based forwarding construct. This results in an ordered chain of topological and service instructions where the ingress node pushes the segment list on the packet.

 

Prefix Hijacking in BGP

BGP hijacking revolves around locating an ISP that is not filtering advertisements, or its misconfiguration makes it susceptible to a man-in-the-middle attack. Once located, an attacker can advertise any prefix they want, causing some or all traffic to be diverted from the real source towards the attacker.

In February 2008, a large portion of YouTube’s address space was redirected to Pakistan when the Pakistan Telecommunication Authority ( PTA ) decided to restrict access to YouTube.com inside the country but accidentally blackholed the route in the global BGP table.

These events and others have led the Secure-Inter Domain Routing Group ( SIDR ) to address the following two vulnerabilities in BGP:

-Is the AS authorized to originate an IP prefix?

-Is the AS-Path represented in the route the same as the path through which the NLRI traveled?

This lockdown of BGP has three solution components:

 

RPKI Infrastructure Offline repository of verifiable secure objects based on public-key cryptography
Follows resources (IPv4/v6 + ASN) allocation hierarchy to provide “right of use”
BGP Secure Origin AS You only validate the Origin AS of a BGP UPDATE
Solves most frequent incidents (*)
No changes to BGP nor the router’s hardware impact
Standardization is almost finished and running code
BGP PATH Validation BGPSEC proposal under development at IETF
Requires forward signing AS-PATH attribute
Changes in BGP and possible routers

The roll-out and implementation should be gradual and create islands of trust worldwide. These islands of trust will eventually interconnect together, making BGP more secure.

The table below displays the RPKI Deployment State;

RIR Total Valid Invalid Unknown Accuracy RPKI Adoption Rate
AFRINIC 100% .44% .42% 99.14% 51.49% .86%
APNIC 100% .22% .24% 99.5% 48.32% .46%
ARIN 100% .4% .14% 99.46% 74.65% .54%
LACNIC 100% 17.84% 2.01% 80.15% 89.87% 19.85%
RIPE NCC 100% 6.7% 0.59% 92.71% 91.92% 7.29%

Cloud Enhancements – The Intercloud

Today’s clouds have crossed well beyond the initial hype, and applications are now offered as on-demand services ( anything-as-a-service [XaaS] ). These services are making significant cost savings, and the cloud transition is shaping up to be as powerful as the previous one – the Internet. The Intercloud and the Internet of Things are the two new big clouds of the future.

Currently, the cloud market is driven by two spaces – the public cloud ( off-premise ) and the private cloud (on-premise). The intercloud takes the concept of cloud much further and attempts to connect multiple public clouds. A single application that could integrate services and workloads from ten or more clouds would create opportunities and potentially alter the cloud market landscape significantly. Hence, it is important to know and understand the need for cloud migration and its related problems.

We are already beginning to see signs of this in the current market. Various applications, such as Spotify and Google Maps, authenticate unregistered users with their Facebook credentials. Another use case is a cloud IaaS provider could divert incoming workload to another provider if it doesn’t have the resources to serve the incoming requests, essentially cloud bursting from provider to provider. It would also make economic sense to move workload and services between cloud providers based on cooling costs ( follow the moon ). Or maybe dynamically move workloads between providers, so they are closest to the active user base ( follow the sun )

The following diagram displays a Dynamic Workload Migration between two Cloud companies.

 

Intercloud
Diagram: Intercloud.

 

A: Cloud 1 finds Cloud 2 -Naming, Presence
B: Cloud 1 Trusts Cloud 2 -Certificates, Trustsec
C: Both Cloud 1 and 2 negotiate -Security, Policy
D: Cloud 1 sets up Cloud 2 -Placement, Deployment
E: Cloud 1 sends to Cloud 2 -VM runs in cloud-Addressing, configurations

The concept of Intercloud was difficult to achieve with the previous version of vSphere based on the restriction of latency for VMotion to operate efficiently. Now vSphere v6 can tolerate 100 msec of RTT.

InterCloud is still a conceptual framework, and the following questions must be addressed before it can be moved from concept to production.

1) Intercloud security

2) Intercloud SLA management

3) Interoperability across cloud providers.

 

Cisco’s One Platform Kit (onePK)

The One Platform Kit is Cisco’s answer to Software Defined Networking. It aims to provide simplicity and agility to a programmatic network. It’s a set of APIs driven by programming languages, such as C and Java, that are used to program the network. We currently have existing ways to program the network with EEM applets but lack an automation tool that can program multiple devices simultaneously. It’s the same with Performance Routing ( PfR ). PfR can program and traffic engineer the network by remotely changing metrics, but the decisions are still local and not controller-based.

 

Traffic engineering

One useful element of Cisco’s One Platform Kit is its ability to perform “Off box” traffic engineering, i.e., the computation is made outside the local routing device. It allows you to create route paths throughout the network without relying on default routing protocol behavior. For example, the cost is the default metric for route selection for equal-length routes in OSPF. This cannot be changed, which makes the routing decisions very static. In addition, Cisco’s One Platform Kit (onePK) allows you to calculate routes using different variables you set, giving you complete path control.

 

ip routing