One document matched: draft-vyncke-6man-segment-routing-security-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4942.xml">
<!ENTITY RFC5095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5095.xml">
<!ENTITY RFC6407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6407.xml">
<!-- IETF drafts -->
<!ENTITY I-D.ietf-spring-ipv6-use-cases PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-ipv6-use-cases.xml">
<!ENTITY I-D.filsfils-spring-segment-routing PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-segment-routing.xml">
<!ENTITY I-D.filsfils-spring-segment-routing-use-cases PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-segment-routing-use-cases.xml">
<!ENTITY I-D.previdi-6man-segment-routing-header PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.previdi-6man-segment-routing-header.xml">
<!ENTITY I-D.ietf-isis-segment-routing-extensions PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-segment-routing-extensions.xml">
<!ENTITY I-D.psenak-ospf-segment-routing-ospfv3-extension PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.psenak-ospf-segment-routing-ospfv3-extension.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-vyncke-6man-segment-routing-security-01"
ipr="trust200902">
<front>
<title abbrev="Segment Routing Header (SRH) Security Considerations">IPv6
Segment Routing Header (SRH) Security Considerations</title>
<author fullname="Eric Vyncke" initials="E." surname="Vyncke">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaann 6A</street>
<city>Diegem</city>
<region/>
<code>1831</code>
<country>Belgium</country>
</postal>
<email>evyncke@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Via Del Serafico, 200</street>
<city>Rome</city>
<code>00142</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<date day="27" month="October" year="2014"/>
<workgroup>Network Working Group</workgroup>
<abstract>
<t>Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending a SR
header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through any
path (topological, or application/service based) while maintaining
per-flow state only at the ingress node to the SR domain.</t>
<t>Segment Routing can be applied to the IPv6 data plane with the
addition of a new type of Routing Extension Header. This draft analyzes
the security aspects of the Segment Routing Extension Header (SRH) and
how it is used by SR capable nodes to deliver a secure service.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="SRDOCS" title="Segment Routing Documents">
<t>Segment Routing terminology is defined in <xref
target="I-D.filsfils-spring-segment-routing"/>.</t>
<t>Segment Routing use cases are described in <xref
target="I-D.filsfils-spring-segment-routing-use-cases"/>.</t>
<t>Segment Routing IPv6 use cases are described in <xref
target="I-D.ietf-spring-ipv6-use-cases"/>.</t>
<t>Segment Routing protocol extensions are defined in <xref
target="I-D.ietf-isis-segment-routing-extensions"/>, and <xref
target="I-D.psenak-ospf-segment-routing-ospfv3-extension"/>.</t>
</section>
<section anchor="INTRO" title="Introduction">
<t>This document analyzes the security threat model, the security issues
and proposed solutions related to the new routing header for segment
routing.</t>
<t>The SRH is simply another version of the routing header as described
in <xref target="RFC2460">RFC 2460</xref> and is:<list style="symbols">
<t>inserted by a SR edge router when entering the segment routing
domain or by the source host itself. The source host can even be
outside the SR domain;</t>
<t>inspected and acted upon when reaching the destination address of
the IP header per <xref target="RFC2460">RFC 2460</xref>.</t>
</list></t>
<t>Routers on the path that simply forward an IPv6 packet (i.e. the IPv6
destination address is none of theirs) will never inspect and process
the SRH. Routers whose one interface IPv6 address equals the destination
address field of the SRH will have to parse the SRH and, if supported
and if the local configuration allows it, will act on the SRH.</t>
</section>
<section anchor="THREAT" title="Threat model">
<section title="Source routing threats">
<t>Using a SRH is similar to source routing, therefore it has some
well-known security issues as described in <xref target="RFC4942"/>
section 2.1.1 and <xref target="RFC5095"/>:<list style="symbols">
<t>amplification attacks: where a packet could be forged in such a
way to cause looping among a set of SR-enabled routers causing
unnecessary traffic, hence a Denial of Service (DoS) against
bandwidth;</t>
<t>reflection attack: where a hacker could force an intermediate
node to appear as the immediate attacker, hence hiding the real
attacker from naïve forensic;</t>
<t>bypass attack: where an intermediate node could be used as a
stepping stone (for example in a De-Militarized Zone) to attack
another host (for example in the datacenter or any back-end
server).</t>
</list></t>
<t>These security issues did lead to obsoleting the routing-header
type 0, RH-0, with <xref target="RFC5095"/> because:<list
style="symbols">
<t>it was assumed to be inspected and acted upon by default by
each and every router on the Internet;</t>
<t>it contained multiple segments in the payload.</t>
</list></t>
<t>Therefore, if intermediate nodes ONLY act on valid and authorized
SRH (such as within a single administrative domain), then there is no
security threat similar to RH-0.</t>
</section>
<section anchor="APPSRH" title="Applicability of RFC 5095 to SRH">
<t>In the segment routing architecture described in <xref
target="I-D.filsfils-spring-segment-routing"/> there are basically two
kinds of nodes (routers and hosts):<list style="symbols">
<t>nodes within the segment routing domain, which is within one
single administrative domain, i.e., where all nodes are trusted
anyway else the damage caused by those nodes could be worse than
amplification attacks: traffic interception, man-in-the-middle
attacks, more server DoS by dropping packets, and so on.</t>
<t>nodes outside of the segment routing domain, which is outside
of the administrative segment routing domain hence they cannot be
trusted because there is no physical security for those nodes,
i.e., they can be replaced by hostile nodes or can be coerced in
wrong behaviors.</t>
</list></t>
<t>The use case for segment routing consists of the single
administratuve domain where all non-trusted nodes will not participate
in segment routing and where all segment routing nodes ignore SRH
created by outsides. Hence, the <xref target="RFC5095">RFC 5095</xref>
attacks are not applicable as all participating nodes can be
trusted.</t>
</section>
<section title="Service stealing threat">
<t>Segment routing is used for added value services, there is also a
need to prevent non-participating nodes to use those services; this is
called ‘service stealing prevention’.</t>
</section>
<section title="Topology disclosure">
<t>The SRH also contains all IPv6 addresses of intermediate SR-nodes,
this obviously reveals those addresses to the potentially hostile
attackers if those attackers are able to intercept packets containing
SRH.</t>
</section>
</section>
<section anchor="SECFIELDS" title="Security fields in SRH">
<t>This section summarizes the use of specific fields in the SRH; they
are integral part of <xref
target="I-D.previdi-6man-segment-routing-header"/> and they are again
described here for reader's sake. They are based on a key-hashed message
authentication code (HMAC).</t>
<t>The security-related fields in SRH are:<list style="symbols">
<t>HMAC Key-id, 8 bits wide;</t>
<t>HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not
0).</t>
</list></t>
<t>The HMAC field is the output of the HMAC computation (per <xref
target="RFC2104">RFC 2104</xref>) using a pre-shared key identified by
HMAC Key-id and of the text which consists of the concatenation of:<list
style="symbols">
<t>the source IPv6 address;</t>
<t>last segment field;</t>
<t> an octet whose bit-0 is the clean-up bit flag and others are
0;</t>
<t> HMAC Key-id;</t>
<t> all addresses in the Segment List;</t>
</list></t>
<t>The purpose of the HMAC field is to verify the validity, the
integrity and the authorization of the SRH itself. If an outsider of the
SR domain does not have access to a current pre-shared secret, then it
cannot compute the right HMAC field and the first SR router on the path
processing the SRH and configured to check the validity of the HMAC will
simply reject the packet.</t>
<t>The HMAC field is located at the end of the SRH simply because only
the router on the ingress of the SR domain needs to process it, then all
other SR nodes can ignore it (based on local policy) because they can
trust the upstream router. This is to speed up forwarding operations
because SR routers which do not validate the SRH do not need to parse
the SRH until the end.</t>
<t>The HMAC Key-id field allows for the simultaneous existence of
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as well
as pre-shared keys. This allows for pre-shared key roll-over when two
pre-shared keys are supported for a while when all SR nodes converged to
a fresher pre-shared key. The HMAC Key-id field is opaque, i.e., it has
neither syntax not semantic except as an index to the right combination
of pre-shared key and hash algorithm and except that a value of 0 means
that there is no HMAC field. It could also allow for interoperation
among different SR domains if allowed by local policy.</t>
<t>When a specific SRH is linked to a time-related service (such as
turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are
identical, then it is important to refresh the shared-secret frequently
as the HMAC validity period expires only when the HMAC Key-id and its
associated shared-secret expires. How HMAC Key-ids and pre-shared
secrets are synchronized between participating nodes in the SR domain is
outside of the scope of this document (<xref target="RFC6407">RFC
6407</xref> GDOI could be a basis).</t>
<section anchor="algorithm" title="Selecting a hash algorithm">
<t>The HMAC field in the SRH is 256 bit wide. Therefore, the HMAC MUST
be based on a hash function whose output is at least 256 bits. If the
output of the hash function is 256, then this output is simply
inserted in the HMAC field. If the output of the hash function is
larger than 256 bits, then the output value is truncated to 256 by
taking the least-significant 256 bits and inserting them in the HMAC
field.</t>
<t>SRH implementations can support multiple hash functions but MUST
implement <xref target="FIPS180-4">SHA-2</xref> in its SHA-256
variant.</t>
<t>NOTE: SHA-1 is currently used by some early implementations used
for quick interoperations testing, the 160-bit hash value must then be
right-hand padded with 96 bits set to 0. The authors understand that
this is not secure but is ok for limited tests.</t>
</section>
<section anchor="performance" title="Performance impact of HMAC">
<t>While adding a HMAC to each and every SR packet increases the
security, it has a performance impact. Nevertheless, it must be noted
that:<list style="symbols">
<t>the HMAC field is used only when SRH is inserted by a device
(such as a home set-up box) which is outside of the segment
routing domain. If the SRH is added by a router in the trusted
segment routing domain, then, there is no need for a HMAC field,
hence no performance impact.</t>
<t>when present, the HMAC field MUST only be checked and validated
by the first router of the segment routing domain, this router is
named 'validating SR router'. Downstream routers MAY NOT inspect
the HMAC field.</t>
<t>this validating router can also have a cache of <IPv6 header
+ SRH, HMAC field value> to improve the performance. It is not
the same use case as in IPsec where HMAC value was unique per
packet, in SRH, the HMAC value is unique per flow.</t>
<t>Last point, hash functions such as SHA-2 have been optmized for
security and performance and there are multiple implementations
with good performance.</t>
</list></t>
<t>With the above points in mind, the performance impact of using HMAC
is minimized.</t>
</section>
<section anchor="keymanagement" title="Pre-shared key management">
<t>The field HMAC Key-id allows for:<list style="symbols">
<t>key roll-over: when there is a need to change the key (the hash
pre-shared secret), then multiple pre-shared keys can be used
simultaneously. The validating routing can have a table of
<HMAC Key-id, pre-shared secret> for the currently active
and future keys.</t>
<t>different algorithm: by extending the previous table to
<HMAC Key-id, hash function, pre-shared secret>, the
validating router can also support simultaneously several hash
algorithms (see section <xref target="algorithm"/>)</t>
</list></t>
<t>The pre-shared secret distribution can be done:<list
style="symbols">
<t>in the configuration of the validating routers, either by
static configuration or any SDN oriented approach;</t>
<t>dynamically using a trusted key distribution such as <xref
target="RFC6407"/></t>
</list></t>
<t>NOTE: this section needs more work but the intent is NOT to define
yet-another-key-distribution-protocol.</t>
</section>
</section>
<section anchor="DEPLOYMENT" title="Deployment Models">
<section anchor="NODESINSR" title="Nodes within the SR domain">
<t>A SR domain is defined as a set of interconnected routers where all
routers at the perimeter are configured to insert and act on SRH. Some
routers inside the SR domain can also act on SRH or simply forward
IPv6 packets.</t>
<t>The routers inside a SR domain can be trusted to generate SRH and
to process SRH received on interfaces that are part of the SR domain.
These nodes MUST drop all packets received on an interface that is not
part of the SR domain and containing a SRH whose HMAC field cannot be
validated by local policies. This includes obviously packet with a SRH
generated by a non-cooperative SR domain.</t>
<t>If the validation fails, then these packets MUST be dropped, ICMP
error messages (parameter problem) SHOULD be generated (but rate
limited) and SHOULD be logged.</t>
</section>
<section anchor="NODESOUTSR" title="Nodes outside of the SR domain">
<t>Nodes outside of the SR domain cannot be trusted for physical
security; hence, they need to request by some trusted means (outside
of the scope of this document) a complete SRH for each new connection
(i.e. new destination address). The received SRH MUST include a HMAC
Key-id and HMAC field which is computed correctly (see <xref
target="SECFIELDS"/>).</t>
<t>When an outside node sends a packet with an SRH and towards a SR
domain ingress node, the packet MUST contain the HMAC Key-id and HMAC
field and the the destination address MUST be an address of a SR
domain ingress node .</t>
<t>The ingress SR router, i.e., the router with an interface address
equals to the destination address, MUST verify the HMAC field with
respect to the HMAC Key-id.</t>
<t>If the validation is successful, then the packet is simply
forwarded as usual for a SR packet. As long as the packet travels
within the SR domain, no further HMAC check needs to be done.
Subsequent routers in the SR domain MAY verify the HMAC field when
they process the SRH (i.e. when they are the destination).</t>
<t>If the validation fails, then this packet MUST be dropped, an ICMP
error message (parameter problem) SHOULD be generated (but rate
limited) and SHOULD be logged.</t>
</section>
<section title="SR path exposure">
<t>As the intermediate SR nodes addresses appears in the SRH, if this
SRH is visible to an outsider then he/she could reuse this knowledge
to launch an attack on the intermediate SR nodes or get some insider
knowledge on the topology. This is especially applicable when the path
between the source node and the first SR domain ingress router is on
the public Internet.</t>
<t>The first remark is to state that 'security by obscurity' is never
enough; in other words, the security policy of the SR domain MUST
assume that the internal topology and addressing is known by the
attacker. A simple traceroute will also give the same information
(with even more information as all intermediate nodes between SID will
also be exposed). IPsec Encapsulating Security Payload <xref
target="RFC4303"/> cannot be use to protect the SRH as per RFC4303 the
ESP header must appear after any routing header (including SRH).</t>
<t>To prevent a user to leverage the gained knowledge by intercepting
SRH, it it recommended to apply an infrastructure Access Control List
(iACL) at the edge of the SR domain. This iACL will drop all packets
from outside the SR-domain whose destination is any address of any
router inside the domain. This security policy should be tuned for
local operations.</t>
</section>
<section title="Impact of BCP-38">
<t><xref target="RFC2827">BCP-38</xref>, also known as "Network
Ingress Filtering", checks whether the source address of packets
received on an interface is valid for this interface. The use of loose
source routing such as SRH forces packets to follow a path which
differs from the expected routing. Therefore, if BCP-38 was
implemented in all routers inside the SR domain, then packets with a
SRH could be received by an interface where packets with the source
address are not expected and the packets could be dropped.</t>
<t>As a SR domain is usually a subset of an administrative domain, and
as BCP-38 is only deployed at the ingress routers of this
administrative domain and as packets arriving at those ingress routers
have been normally forwarded using the normal routing information,
then there is no reason why this ingress router should drop the SRH
packet based on BCP-38</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA request or impact in this document.</t>
</section>
<section anchor="Manageability" title="Manageability Considerations">
<t>TBD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security mechanisms applied to Segment Routing over IPv6 networks are
detailed in <xref target="SECFIELDS"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Dave Barach and David Lebrun for
their contributions to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2460;
&RFC4303;
&RFC5095;
&RFC6407;
<reference anchor="FIPS180-4"
target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
<front>
<title>FIPS 180-4 Secure Hash Standard (SHS)</title>
<author>
<organization>National Institute of Standards and
Technology</organization>
</author>
<date month="March" year="2012"/>
</front>
</reference>
</references>
<references title="Informative References">
&I-D.ietf-spring-ipv6-use-cases;
&I-D.filsfils-spring-segment-routing;
&I-D.filsfils-spring-segment-routing-use-cases;
&I-D.previdi-6man-segment-routing-header;
&I-D.ietf-isis-segment-routing-extensions;
&I-D.psenak-ospf-segment-routing-ospfv3-extension;
&RFC2104;
&RFC2827;
&RFC4942;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:12:30 |