7. Security Considerations

This section reviews security considerations related to the SRH, given the SRH processing and deployment models discussed in this document.

As described in Section 5, it is necessary to filter packets' ingress to the SR domain, destined to SIDs within the SR domain (i.e., bearing a SID in the destination address). This ingress filtering is via an IACL at SR domain ingress border nodes. Additional protection is applied via an IACL at each SR Segment Endpoint node, filtering packets not from within the SR domain, destined to SIDs in the SR domain. ACLs are easily supported for small numbers of seldom changing prefixes, making summarization important.

Additionally, ingress filtering of IPv6 source addresses as recommended in BCP 38 [RFC2827] SHOULD be used.

7.1. SR Attacks

An SR domain implements distributed and per-node protection as described in Section 5.1. Additionally, domains deny traffic with spoofed addresses by implementing the recommendations in BCP 84 [RFC3704].

Full implementation of the recommended protection blocks the attacks documented in [RFC5095] from outside the SR domain, including bypassing filtering devices, reaching otherwise-unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.

Failure to implement distributed and per-node protection allows attackers to bypass filtering devices and exposes the SR domain to these attacks.

Compromised nodes within the SR domain may mount the attacks listed above along with other known attacks on IP networks (e.g., DoS/DDoS, topology discovery, man-in-the-middle, traffic interception/siphoning).

7.2. Service Theft

Service theft is defined as the use of a service offered by the SR domain by a node not authorized to use the service.

Service theft is not a concern within the SR domain, as all SR source nodes and SR segment endpoint nodes within the domain are able to utilize the services of the domain. If a node outside the SR domain learns of segments or a topological service within the SR domain, IACL filtering denies access to those segments.

7.3. Topology Disclosure

The SRH is unencrypted and may contain SIDs of some intermediate SR nodes in the path towards the destination within the SR domain. If packets can be snooped within the SR domain, the SRH may reveal topology, traffic flows, and service usage.

This is applicable within an SR domain, but the disclosure is less relevant as an attacker has other means of learning topology, flows, and service usage.

7.4. ICMP Generation

The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing destination address or SRH in back-to-back packets. An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism.

7.5. Applicability of AH

The SR domain is a trusted domain, as defined in [RFC8402], Sections 2 and 8.2. The SR source is trusted to add an SRH (optionally verified as having been generated by a trusted source via the HMAC TLV in this document), and segments advertised within the domain are trusted to be accurate and advertised by trusted sources via a secure control plane. As such, the SR domain does not rely on the Authentication Header (AH) as defined in [RFC4302] to secure the SRH.

The use of SRH with AH by an SR source node and its processing at an SR segment endpoint node are not defined in this document. Future documents may define use of SRH with AH and its processing.