One document matched: draft-vyncke-6man-segment-routing-security-02.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">
<!ENTITY RFC6554 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6554.xml">
<!-- IETF drafts -->
<!ENTITY I-D.ietf-spring-problem-statement PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-problem-statement.xml">
<!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.ietf-spring-segment-routing PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-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.ietf-ospf-ospfv3-segment-routing-extensions PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-ospfv3-segment-routing-extensions.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-02"
ipr="trust200902">
<front>
<title abbrev="Pv6 Segment Routing Security Considerations">IPv6 Segment
Routing Security Considerations</title>
<author fullname="Eric Vyncke" initials="E." role="editor"
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>
<author fullname="David Lebrun" initials="D." surname="Lebrun">
<organization>Universite Catholique de Louvain</organization>
<address>
<postal>
<street>Place Ste Barbe, 2</street>
<city>Louvain-la-Neuve, 1348</city>
<country>Belgium</country>
</postal>
<email>david.lebrun@uclouvain.be</email>
</address>
</author>
<date day="25" month="February" year="2015"/>
<workgroup>6man 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 document
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="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 with an IPv6 data plane.</t>
<t>The Segment Routing Header (SRH) is simply another type 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 originating 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>Per <xref target="RFC2460">RFC2460</xref>, 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 content of SRH. Routers
whose one interface IPv6 address equals the destination address field of
the IPv6 packet MUST to parse the SRH and, if supported and if the local
configuration allows it, MUST act accordingly to the SRH content.</t>
<t>According to <xref target="RFC2460">RFC2460</xref>, the default
behavior of a non SR-capable router upon receipt of an IPv6 packet with
SRH destined to an address of its, is to:<list style="symbols">
<t>ignore the SRH completely if the Segment Left field is 0 and
proceed to process the next header in the IPv6 packet;</t>
<t>discard the IPv6 packet if Segment Left field is greater than 0,
it MAY send a Parameter Problem ICMP message back to the Source
Address.</t>
</list></t>
<section anchor="SRDOCS" title="Segment Routing Documents">
<t>Segment Routing terminology is defined in <xref
target="I-D.ietf-spring-segment-routing"/> and in <xref
target="I-D.ietf-spring-problem-statement"/>. Segment Routing use
cases are described in <xref
target="I-D.filsfils-spring-segment-routing-use-cases"/>. Segment
Routing protocol extensions are defined in <xref
target="I-D.ietf-isis-segment-routing-extensions"/>, and <xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t>
<t>Segment Routing IPv6 use cases are described in <xref
target="I-D.ietf-spring-ipv6-use-cases"/>. And the IPv6 Segment
Routing header is described in <xref
target="I-D.previdi-6man-segment-routing-header"/>.</t>
</section>
</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">RFC4942</xref> section 2.1.1 and <xref
target="RFC5095">RFC5095</xref>:<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>
</section>
<section anchor="APPSRH" title="Applicability of RFC 5095 to SRH">
<t>First of all, the reader must remember this specific part of
section 1 of <xref target="RFC5095">RFC5095</xref>, "A side effect is
that this also eliminates benign RH0 use-cases; however, such
applications may be facilitated by future Routing Header
specifications.". In short, it is not forbidden to create new secure
type of Routing Header; for example, <xref target="RFC6554">RFC 6554
(RPL)</xref> also creates a new Routing Header type for a specific
application confined in a single network.</t>
<t>In the segment routing architecture described in <xref
target="I-D.ietf-spring-segment-routing"/> there are basically two
kinds of nodes (routers and hosts):<list style="symbols">
<t>nodes within the SR 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 SR 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 main use case for SR consists of the single administrative
domain where only trusted nodes with SR enabled and configured
participate in SR: this is the same model as in <xref
target="RFC6554">RFC6554</xref>. All non-trusted nodes do not
participate as either SR processing is not enabled by default or
because they only process SRH from nodes within their domain.</t>
<t>Moreover, all SR nodes ignore SRH created by outsiders based on
topology information (received on a peering or internal interface) or
on presence and validity of the HMAC field. 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. Hence, the <xref target="RFC5095">RFC 5095</xref> attacks are
not applicable.</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 may also contains IPv6 addresses of some intermediate
SR-nodes in the path towards the destination, this obviously reveals
those addresses to the potentially hostile attackers if those
attackers are able to intercept packets containing SRH. On the other
hand, if the attacker can do a traceroute whose probes will be
forwarded along the SR path, then there is little learned by
intercepting the SRH itself. Also the clean-bit of SRH can help by
removing the SRH before forwarding the packet to potentially a
non-trusted part of the network.</t>
</section>
<section title="ICMP Generation">
<t>Per section 4.4 of <xref target="RFC2460">RFC2460</xref>, when
destination nodes (i.e. where the destination address is one of
theirs) receive a Routing Header with unsupported Routing Type, the
required behavior is:<list style="symbols">
<t>If Segments Left is zero, the node must ignore the Routing
header and proceed to process the next header in the packet.</t>
<t>If Segments Left is non-zero, the node must discard the packet
and send an ICMP Parameter Problem, Code 0, message to the
packet's Source Address, pointing to the unrecognized Routing
Type.</t>
</list></t>
<t>This required behavior could be used by an attacker to force the
generation of ICMP message by any node. The attacker could send
packets with SRH (with Segment Left set to 0) destined to a node not
supporting SRH. Per <xref target="RFC2460">RFC2460</xref>, the
destination node could generate an ICMP message, causing a local CPU
utilization and if the source of the offending packet with SRH was
spoofed could lead to a reflection attack without any
amplification.</t>
<t>It must be noted that this is a required behavior for any
unsupported Routing Type and not limited to SRH packets. So, it is not
specific to SRH and the usual rate limiting for ICMP generation is
required anyway for any IPv6 implementation and has been implemented
and deployed for many years.</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>First 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 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 and assuming a
collision-free Key Id allocation.</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.</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>The intent of this document 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 SRH 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 SR packets could
be received by an interface which is not expected one and the packets
could be dropped.</t>
<t>As a SR domain is usually a subset of one 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. Routers inside the domain commonly do not
apply BCP-38; so, this is not a problem.</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 Stewart Bryant 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-problem-statement;
&I-D.ietf-spring-segment-routing;
&I-D.filsfils-spring-segment-routing-use-cases;
&I-D.ietf-isis-segment-routing-extensions;
&I-D.ietf-ospf-ospfv3-segment-routing-extensions;
&I-D.ietf-spring-ipv6-use-cases;
&I-D.previdi-6man-segment-routing-header;
&RFC2104;
&RFC2827;
&RFC4942;
&RFC6554;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:21:33 |