[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

spring                                                        C. Perkins
Internet-Draft                                                 Futurewei
Intended status: Standards Track                            July 1, 2019
Expires: January 2, 2020


            Security Considerations for Networks Using SRv6
                      draft-perkins-sr-security-00

Abstract

   This document identifies various threats to networks employing
   segment routing over an IPv6 transport.  Segment Routing inherits
   potential security vulnerabilities from source routing in general,
   and from label-switching approaches such as MPLS.  The document
   discusses how common security vulnerabilities may be present in SRv6
   networks, depending on the security policies that are imposed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 2, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Perkins                  Expires January 2, 2020                [Page 1]


Internet-Draft                 SR-security                     July 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Types of Vulnerabilities in SR Networks . . . . . . . . . . .   6
     4.1.  Loss of Confidentiality . . . . . . . . . . . . . . . . .   6
     4.2.  Tampering with Packet Data  . . . . . . . . . . . . . . .   6
     4.3.  Loss of Connectivity  . . . . . . . . . . . . . . . . . .   6
     4.4.  Identity Theft  . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Hijacking . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.6.  Denial of Origination . . . . . . . . . . . . . . . . . .   7
     4.7.  Packet/Segment Replay . . . . . . . . . . . . . . . . . .   7
     4.8.  Distributed DoS . . . . . . . . . . . . . . . . . . . . .   7
     4.9.  Malicious Packet Data in SR Networks  . . . . . . . . . .   7
   5.  Mechanisms for Misuse of Source Routed Networks . . . . . . .   7
     5.1.  SR insertion  . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  SR deletion . . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  SR swapping . . . . . . . . . . . . . . . . . . . . . . .   8
     5.4.  SID tampering . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Effects of the above on SR Use Cases  . . . . . . . . . . . .   8
     6.1.  Threats to SRv6 in the Small Office . . . . . . . . . . .   9
     6.2.  Threats to SRv6 in the Access Network . . . . . . . . . .   9
     6.3.  Threats to SRv6 in Data Center  . . . . . . . . . . . . .  10
     6.4.  Threats to SRv6 in Content Delivery Networks  . . . . . .  10
     6.5.  Threats to SRv6 in Core Networks  . . . . . . . . . . . .  10
     6.6.  Threats to SRv6 in Mobile User Plane  . . . . . . . . . .  11
   7.  Some Trust Models . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Trusted Domain  . . . . . . . . . . . . . . . . . . . . .  12
     7.2.  Closed Domain . . . . . . . . . . . . . . . . . . . . . .  12
     7.3.  Ingress Domain  . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Appendix A.  Ameliorations  . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document identifies various threats to networks employing
   segment routing.  Segment Routing inherits potential security
   vulnerabilities from source routing in general, and also from label-
   switching approaches such as MPLS.  The document discusses how common



Perkins                  Expires January 2, 2020                [Page 2]


Internet-Draft                 SR-security                     July 2019


   security vulnerabilities may be present in SRv6 networks, depending
   on the security policies that are imposed.

   o  SR is a descendent of IPv6 routing header, and consequently its
      security properties need to be understood in light of previous
      work [RFC5095].

   o  SRv6 inherits some insecurities from label-switching architecture.
      Some of the consequences have been outlined in [RFC8341].

   SRv6 is envisioned for use in a number of important kinds of network
   deployments (see [RFC8354], [I-D.ietf-dmm-srv6-mobile-uplane]):

      SRv6 in the Small Office

      SRv6 in the Access Network

      SRv6 in Data Center

      SRv6 in Content Delivery Networks

      SRv6 in Core Networks

      SRv6 for user-plane in mobile networks

   Segments are currently being designed and applied to exploit SRv6 for
   the above use cases (see [RFC8402],
   [I-D.ietf-dmm-srv6-mobile-uplane]).  Some of these segments are as
   follows:

   o  IGP-Prefix

   o  IGP-Node

   o  IGP-Anycast

   o  IGP Adjacencies

   o  BGP-Prefix

   o  BGP Peering

   o  IGP Mirroring Context

   o  IGP-Prefix

   o  Args.Mob.Session




Perkins                  Expires January 2, 2020                [Page 3]


Internet-Draft                 SR-security                     July 2019


   o  End.M.GTP6.E (GTP encapsulation)

   o  End.M.GTP6.D (GTP decapsulation)

   o  End.Limit

   During the discussion in the following sections, the above segments
   may be useful for more concrete understanding of the vulnerabilities.

   In this document, we will consider the dangers from the following
   kinds of threats:

   o  Loss of Confidentiality

   o  Tampering with Packet Data

   o  Packet data intending to cause harm

   o  Denial of Origination

   o  Packet Replay

   o  Loss of Connectivity

   o  Identity Theft

   o  Hijacking

   o  DoS, Distributed DoS

   o

   In the rest of this document, applicability for Segment Routing and
   for the details of the security observations will first be described.
   Then the terminology will be presented, followed by a review of
   threats and network vulnerabilities as recently discussed at IETF
   meetings.  Some new mechanisms introduced by SR that can threaten
   network security are outlined.  Then, in order to have more concrete
   understanding, some use cases envisioned for Segment Routing
   architectures will be reviewed according to the descriptions in other
   cited documents.  Afterwards, several kinds of security policies
   relevant to SR network administration will be outlined.  This
   collection of security policies is not intended to be comprehensive,
   but at least representative of possible SR networks.  Finally, some
   ameliorations for some of the threats will be described as well as
   known gaps in an effort to motivate future work.





Perkins                  Expires January 2, 2020                [Page 4]


Internet-Draft                 SR-security                     July 2019


2.  Applicability

   "Segment Routing Architecture" [RFC8402] recommends that SR should be
   restricted to operation within a trusted domain.  In other words, the
   SR routers in the domain are presumed to be operating without
   malicious intent and also to conform to specification for the
   protocols that they use.

   A network's vulnerability to each threat depends substantially on
   whether or not the network border routers accept incoming packets
   with segments.  On the other hand, there are use cases for which an
   incoming source route can be quite useful (e.g., for Mobile IP
   [RFC6275]), and advances in SRv6 security would be beneficial to such
   use cases.

   It also has to be specified whether or not all routers in the network
   (not just SR-capable) are all trusted.  A network might allow
   intermediate routers to handle interconnections between SRv6 routers.
   These intermediate routers would not require any SRv6 capability, or
   security associations with SRv6 routers.  They would be configured so
   that they would never insert or delete any SID.

   It has been noted that AH and ESP are not directly applicable to
   reducing the vulnerabilities of SR routing, due to the presence of
   mutable fields in the SR Header.  Future work to improve security in
   SRv6 networks will be to include a new design so that SRv6 mutable
   fields can be authenticated separately while still allowing use of
   these basic IPv6 functions.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] and [RFC8174].

   This document uses the terminology defined in [RFC8402] and
   [RFC5095].  In addition, the following definitions are used.

   trusted domain:  A network in which all routers are known to be
             trustworthy.

   closed domain:  A network in which border routers reject any incoming
             packet that includes a SRv6 header.

   ingress domain:  A network in which border routers may accept certain
             incoming packets that include a SRv6 header.




Perkins                  Expires January 2, 2020                [Page 5]


Internet-Draft                 SR-security                     July 2019


4.  Types of Vulnerabilities in SR Networks

   Each vulnerability in the previous section requires particular
   attention and evaluation within the context of the various security
   policies for SRv6 considered in this document.

4.1.  Loss of Confidentiality

   As with practically all except the simplest networks, intermediate
   routers and transit points might be able to eavesdrop on traffic in
   an SR network unless measures are taken to hide the data in the
   packet.

   However, in the case of SR networks, the segments in the segment
   stack are often used to express and carry out routing policies, which
   can be tailored to the needs of individual flows.  Allowing
   inspection of the segments might allow a malicious party to infer
   policy information which is not intended for distribution to
   unauthorized parties.

4.2.  Tampering with Packet Data

   Packet data in an SR network is vulnerable to tampering unless all
   intermediate routers and transit points are trustworthy.

4.3.  Loss of Connectivity

   SRv6 networks that make use of a centralized control plane may be
   threatened by loss of connectivity (whether accidental or malicious)
   between the central controller and the network nodes.  This is
   important since such networks depend on centralized controllers (PCE,
   etc.) to calculate flow paths and resulting SID lists, and the
   installation of the SID lists in edge/border routers.

4.4.  Identity Theft

   Does SRv6 create new vulnerability to Identity Theft in the network?

4.5.  Hijacking

   One of the main dangers from a compromised SR network router is that
   data in the network can be hijacked and sent to an unintended
   destination.  Or, equally, selected data can be prevented from
   reaching an intended destination, or may be sent along a path that
   was not originally intended.






Perkins                  Expires January 2, 2020                [Page 6]


Internet-Draft                 SR-security                     July 2019


4.6.  Denial of Origination

   In many situations, it is important to prove whether or not the
   apparent source of a packet in fact originated that packet.
   Otherwise, for example, the true source may claim that the packet was
   forged and decline responsibility for a completed transaction.  The
   segments used in an SRv6 deployment should be analyzed to see if this
   vulnerability is introduced.

4.7.  Packet/Segment Replay

   Replaying packets, to deceive the destination into thinking that the
   source has repeated a transaction, is an ever-present danger.  In SR
   networks, there is the further danger of "replaying" segments from
   previous packets without otherwise modifying the payload of the new
   packet.

4.8.  Distributed DoS

   Distributed denial of service (DDoS) attacks take many forms and can
   effectively crash an entire network, or any part of the network.  If
   malicious segments could be configured into the SR routers, say for a
   sensitive destination, then all such configured routers could be
   triggered with instructions to repeatedly bombard that destination
   while at the same time causing other network traffic to cease.

4.9.  Malicious Packet Data in SR Networks

   Suppose that an SRv6 network's infrastructure is known to be
   vulnerable to particular sequences of network elements -- say,
   because an adversary has discovered that the release of the SRv6
   router's operating system has certain bugs, or poor configuration.
   In this case, the SR network may be vulnerable to insertion of
   segments tailored to trigger bugs in a nonlocal SRv6 router.

5.  Mechanisms for Misuse of Source Routed Networks

   As a packet traverses a SRv6 network, it visits a path of SRv6
   routers.  The path is determined by the placement of SRv6 segments on
   the segment stack in the IPv6 SRv6 header.  The following malicious
   behaviors are related to the operation of SRv6 networks.

   o  SR insertion: hijacking, loss of confidentiality, packet drops,
      man-in-the-middle.

   o  SR deletion: defeats traffic management

   o  SR swapping: defeats traffic management



Perkins                  Expires January 2, 2020                [Page 7]


Internet-Draft                 SR-security                     July 2019


   o  Address modification: DoS, otherwise same threats as insertion

5.1.  SR insertion

   By inserting an unauthorized segment in the segment stack, an
   attacker could cause the packet to be routed for processing by an
   unaware or compromised router.  If the spurious segment were placed
   farther down in the segment stack, the effect of the insertion would
   be non-local, and thus detection of the malicious node would be more
   difficult.  Since the SID also determines the processing steps that
   are taken by an SRv6 router, an attacker that is aware of the meaning
   of the SIDs at any particular point along the segment path, could
   insert particular unwanted processing steps for the packet.  For
   instance, unauthorized traffic handling or charging could be applied
   to the packet.

5.2.  SR deletion

   By deleting a segment in the segment stack, an attacker could cause
   the packet to avoid various processing steps including inspection or
   accounting.  If the deleted segment was placed farther down in the
   segment stack, the effect of the deletion would be non-local, and
   thus detection of the malicious node would be more difficult.

5.3.  SR swapping

   Segment swapping can be accomplished by deletion and subsequent
   reinsertion, possibly done twice.  Such swapping would not be
   detectable by any non-cryptographic checksum mechanism.

5.4.  SID tampering

   Every router along the routing path of a packet in an SRv6 network
   has the opportunity to tamper with the segments that are present in
   the segment stack.  This is possible even for routers that are not
   SRv6 routers, because each such router could inspect the IPv6 packet
   header to determine whether or not the SR header is present.

   By tampering with the Segment ID or the data associated with the
   Segment ID, each such router along the path could cause unwanted
   processing steps, or defeat traffic management for the packet.

6.  Effects of the above on SR Use Cases

   In the following sections we describe the effects of the above-
   mentioned threats in terms of applicability statement and the use
   cases given in [RFC8354] and [I-D.ietf-dmm-srv6-mobile-uplane].




Perkins                  Expires January 2, 2020                [Page 8]


Internet-Draft                 SR-security                     July 2019


      SRv6 in the Small Office

      SRv6 in the Access Network

      SRv6 in Data Center

      SRv6 in Content Delivery Networks

      SRv6 in Core Networks

      SRv6 in Mobile User Plane [I-D.ietf-dmm-srv6-mobile-uplane]

   Almost by the very nature of Segment Routing, hijacking of traffic
   flows is possible by inserting an unauthorized segment into an
   existing segment stack, or by modifying the destination address of
   one of the segments already on the stack.  This threat has to be
   considered for each one of these use cases.  In fact, almost all
   networks are vulnerable to hijacking attacks if one of the routers is
   compromised.  What is new with SRv6 networks, is that the actual
   hijacking can occur at a point in the routing path that is
   arbitrarily distant from the point at which the unauthorized segment
   was inserted.  This could complicate attempts to identify the source
   of the attack.

6.1.  Threats to SRv6 in the Small Office

   According to [RFC8354], "A SPRING-enabled SOHO provides the ability
   to steer traffic into a specific path from end hosts in the SOHO or
   from a customer edge router in the SOHO".

   A malicious node might be able to steer particular traffic flows into
   a more favorable or less favorable path.  This could include sending
   packets originated by an end host within the SOHO out through an
   unauthorized edge router.

6.2.  Threats to SRv6 in the Access Network

   Access networks are typically required to provide efficient service
   to a wide variety of traffic flows.  Some flows may consume only a
   small amount of network capacity, but require very low latency for
   packet delivery.  Other flows may be resilient against packet loss
   but have requirement for high capacity.  There may be regulatory
   requirements in place, and sometimes the nature of traffic between
   two endpoints can change, requiring a dynamic readjustment for
   handling by the service provider.

   A malicious node might be able to disrupt the orderly classification
   or modify the segment path through the access network.  This could



Perkins                  Expires January 2, 2020                [Page 9]


Internet-Draft                 SR-security                     July 2019


   enable particular flows to evade regulatory requirements, or to avoid
   proper billing for use of resources.

6.3.  Threats to SRv6 in Data Center

   SRv6 is attractive for use by data center operators in order to
   provide a scalable platform for multiple (or many) tenants.  The path
   taken by information through the data center interconnection can be
   closely controlled by segment routing and tailored to the needs of
   specific tenants.

   A malicious node might be able to divert traffic from one tenant
   network into a different routing space.  It would also be possible to
   divert traffic to take advantage of resources that are paid for by
   some other tenant, and have the next segment on the segment stack
   restore the packet to its original path after making unauthorized use
   of the other tenant's resources.

6.4.  Threats to SRv6 in Content Delivery Networks

   Content Delivery Networks (CDNs) have placed new requirements for
   supplying video traffic to consumers across operator networks and
   infrastructure.  Some of the traffic is real time; for example,
   television programming, news, and sports events.  Other traffic may
   require higher bandwidth but also allow more buffering for resilience
   against temporary bottlenecks, such as high definition movies.  In
   the future, the requirements for special handling of video content
   will only increase, especially as virtual and augmented reality
   applications become more popular.

   Caching is an important technique for delivering video content to
   many customers at the same time.  The caches can be provisioned
   hierarchically.  In such a system, segment routing can be designed
   for beneficial use to proceed along a path of cached data in the
   hierarchy until a cache hit provides the desired content.

   A malicious node might be able to cause major disruption and service
   outage to many paying customers by misdirection of cache requests
   along the service hierarchy.  Other threats are similar to those
   listed against SRv6 deployment in access networks.

6.5.  Threats to SRv6 in Core Networks

   In order to meet the divergent demands for different kinds of
   service, network operators have been buying more specialized
   equipment for deployment within their core infrastructure.  Some of
   the equipment has extremely high bandwidth compared to existing
   equipment, so that the network as a whole supports network paths with



Perkins                  Expires January 2, 2020               [Page 10]


Internet-Draft                 SR-security                     July 2019


   widely varying capacities.  Some lower-bandwidth paths through the
   core infrastructure may be connected to allow very low-latency
   communications.  Some portions of the network may be set up to handle
   very predictable traffic in a more efficient manner.  Detnet
   [RFC8557], [RFC8558] is likely to create new requirements for
   diversity, resilience, and low latency.

   A malicious node that could make changes to a segment path through a
   core network would be able to cause major damage to the network and
   to perhaps millions of customers.  By inserting unauthorized
   segments, diversion to a hostile node could be accomplished for
   traffic analysis, delay, hijacking, or almost arbitrary disruption to
   the customers' network communications.  By the nature of segment
   handling, this disruption could occur in places of the network not
   immediately traceable to the malicious device inserting the
   unauthorized segment.

6.6.  Threats to SRv6 in Mobile User Plane

   It has been proposed to use Segment Routing to gain tenant isolation
   and support traffic management for user plane architectures designed
   for 5G mobile networks [I-D.ietf-dmm-srv6-mobile-uplane]).  In
   particular, segments have been defined to allow re-use of existing
   user=plane equipment by instructing the segment router to perform GTP
   encapsulation and decapsulation steps.  Other mobility-related
   activities are possible to support rapid handover.  Moreover, even
   within an IPv6-only mobile infrastructure, there will be a long-
   standing need for support of IPv4 GTP tunneling.

   A malicious node might be able to change the endpoint for
   decapsulation of GTP traffic, or target particular mobile devices for
   eavesdropping or mismanagement.  Since many people use their mobile
   devices for financial transactions and personal data, this would
   represent a major loss of privacy and financial risk for all such
   customers.

7.  Some Trust Models

   Depending upon the trust model enforced by the administration of the
   SRv6 network, the previously mentioned threats may be largely
   countered and/or prevented.  In this section, some observations will
   be offered about specific effects of the trust model.  Some
   recommendations will be made about work that might be undertaken to
   further diminish the dangers from those threats.







Perkins                  Expires January 2, 2020               [Page 11]


Internet-Draft                 SR-security                     July 2019


7.1.  Trusted Domain

   Many of the threats to a trusted domain Section 3 are effectively
   nullified by the tight administration required to configure and
   maintain the security associations between all the routing elements
   in the domain.

   Since all of the routing elements are presumed to not be malicious,
   none of them will attempt to hijack the traffic.

   Also, since the routing elements are presumed to not be malicious,
   there is no danger that the routers would tamper with the packet data
   or the segment stack in the SR header.

   There might still be a danger of loss of confidentiality, if packets
   are visible to other nodes on the subnets upon which the routers
   reside.

7.2.  Closed Domain

   In a closed domain Section 3 all of the known Segment Routers are
   presumed not to be malicious, but some of the other routers may have
   a lesser level of assurance against compromise.

   Unfortunately, a non-SR router might misperform by pretending to be
   an SR-router.  In that case, the compromised router could attempt to
   modify the contents of the segment stack in some arbitrary manner.
   This could leave the closed domain vulnerable to most of the threats
   described in Section 4.

   In particular there are the dangers of hijacking, packet replay, and
   loss of confidentiality.  The first two can be triggered "remotely",
   so that none of the routers adjacent to the malicious action can be
   identified as responsible for executing the threat.

7.3.  Ingress Domain

   In an ingress domain Section 3 some of the border routers are
   configured to accept incoming packets that already contain an IPv6 SR
   header.

   In such domains, it is important to exert tight control over the
   types of segments that may be included in the incoming packet.  The
   syntax and semantics of any such incoming segment has to be well
   specified and conformant with the routing policy of the ingress
   domain.  For example, source routes used for the purposes of Mobile
   IP [RFC6275] have very specific restrictions and are not intended to
   be forwarded past the target of the incoming source route.  The



Perkins                  Expires January 2, 2020               [Page 12]


Internet-Draft                 SR-security                     July 2019


   destinations reachable by way of the SR header in the incoming packet
   should also be tightly controlled so that random internal targets are
   not visible except by careful prearrangement.

   If sufficient control is not exerted over the type or the intended
   destination of a source route, then many of the threats in Section 4
   might become viable and, even worse, established by malicious agents
   external to the domain.  Such external agents are typically not at
   all under the control of the SR network administrator.

8.  Security Considerations

   The subject of this draft is to improve understanding of the security
   model and vulnerabilities associated with Segment Routing.

9.  Acknowledgements

   Thanks to Andy Malis for his early review of this document.

10.  References

10.1.  Normative References

   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
              daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
              IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
              uplane-04 (work in progress), March 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              DOI 10.17487/RFC5095, December 2007,
              <https://www.rfc-editor.org/info/rfc5095>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.





Perkins                  Expires January 2, 2020               [Page 13]


Internet-Draft                 SR-security                     July 2019


   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8354]  Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
              Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
              Routing in Networking (SPRING)", RFC 8354,
              DOI 10.17487/RFC8354, March 2018,
              <https://www.rfc-editor.org/info/rfc8354>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8557]  Finn, N. and P. Thubert, "Deterministic Networking Problem
              Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
              <https://www.rfc-editor.org/info/rfc8557>.

   [RFC8558]  Hardie, T., Ed., "Transport Protocol Path Signals",
              RFC 8558, DOI 10.17487/RFC8558, April 2019,
              <https://www.rfc-editor.org/info/rfc8558>.

10.2.  Informative References

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.

Appendix A.  Ameliorations

   This section lists ameliorations for the previosly mentioned list of
   threats.  It is likely to be deleted prior to publication.  The
   purpose is simply to open up discussion about known approaches to
   minimize the threats listed in this document.

   o  Ameliorations in core networks.

   o  Ameliorations in RAN.




Perkins                  Expires January 2, 2020               [Page 14]


Internet-Draft                 SR-security                     July 2019


   o  Ameliorations in transit networks.

   o  The use of ACLs.

   o  How many security associations are needed if the SR network is not
      a "trusted domain"?

   o  Classes of security associations.

   o  Danger of segment stack exhaustion.

Author's Address

   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   Unites States

   Email: charlie.perkins@futurewei.com































Perkins                  Expires January 2, 2020               [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/