src/vnet/sr/ietf_draft_05.txt

   1 Network Working Group                                    S. Previdi, Ed.
   2 Internet-Draft                                               C. Filsfils
   3 Intended status: Standards Track                     Cisco Systems, Inc.
   4 Expires: August 5, 2017                                         B. Field
   5                                                                  Comcast
   6                                                                 I. Leung
   7                                                    Rogers Communications
   8                                                               J. Linkova
   9                                                                   Google
  10                                                                 E. Aries
  11                                                                 Facebook
  12                                                                T. Kosugi
  13                                                                      NTT
  14                                                                E. Vyncke
  15                                                      Cisco Systems, Inc.
  16                                                                D. Lebrun
  17                                         Universite Catholique de Louvain
  18                                                         February 1, 2017
  19
  20
  21                    IPv6 Segment Routing Header (SRH)
  22                draft-ietf-6man-segment-routing-header-05
  23
  24 Abstract
  25
  26    Segment Routing (SR) allows a node to steer a packet through a
  27    controlled set of instructions, called segments, by prepending an SR
  28    header to the packet.  A segment can represent any instruction,
  29    topological or service-based.  SR allows to enforce a flow through
  30    any path (topological, or application/service based) while
  31    maintaining per-flow state only at the ingress node to the SR domain.
  32
  33    Segment Routing can be applied to the IPv6 data plane with the
  34    addition of a new type of Routing Extension Header.  This draft
  35    describes the Segment Routing Extension Header Type and how it is
  36    used by SR capable nodes.
  37
  38 Requirements Language
  39
  40    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  41    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  42    document are to be interpreted as described in RFC 2119 [RFC2119].
  43
  44 Status of This Memo
  45
  46    This Internet-Draft is submitted in full conformance with the
  47    provisions of BCP 78 and BCP 79.
  48
  49
  50
  51
  52 Previdi, et al.          Expires August 5, 2017                 [Page 1]
  53
  54 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
  55
  56
  57    Internet-Drafts are working documents of the Internet Engineering
  58    Task Force (IETF).  Note that other groups may also distribute
  59    working documents as Internet-Drafts.  The list of current Internet-
  60    Drafts is at http://datatracker.ietf.org/drafts/current/.
  61
  62    Internet-Drafts are draft documents valid for a maximum of six months
  63    and may be updated, replaced, or obsoleted by other documents at any
  64    time.  It is inappropriate to use Internet-Drafts as reference
  65    material or to cite them other than as "work in progress."
  66
  67    This Internet-Draft will expire on August 5, 2017.
  68
  69 Copyright Notice
  70
  71    Copyright (c) 2017 IETF Trust and the persons identified as the
  72    document authors.  All rights reserved.
  73
  74    This document is subject to BCP 78 and the IETF Trust's Legal
  75    Provisions Relating to IETF Documents
  76    (http://trustee.ietf.org/license-info) in effect on the date of
  77    publication of this document.  Please review these documents
  78    carefully, as they describe your rights and restrictions with respect
  79    to this document.  Code Components extracted from this document must
  80    include Simplified BSD License text as described in Section 4.e of
  81    the Trust Legal Provisions and are provided without warranty as
  82    described in the Simplified BSD License.
  83
  84 Table of Contents
  85
  86    1.  Segment Routing Documents . . . . . . . . . . . . . . . . . .   3
  87    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  88      2.1.  Data Planes supporting Segment Routing  . . . . . . . . .   4
  89      2.2.  Segment Routing (SR) Domain . . . . . . . . . . . . . . .   4
  90        2.2.1.  SR Domain in a Service Provider Network . . . . . . .   5
  91        2.2.2.  SR Domain in a Overlay Network  . . . . . . . . . . .   6
  92    3.  Segment Routing Extension Header (SRH)  . . . . . . . . . . .   7
  93      3.1.  SRH TLVs  . . . . . . . . . . . . . . . . . . . . . . . .   9
  94        3.1.1.  Ingress Node TLV  . . . . . . . . . . . . . . . . . .  10
  95        3.1.2.  Egress Node TLV . . . . . . . . . . . . . . . . . . .  11
  96        3.1.3.  Opaque Container TLV  . . . . . . . . . . . . . . . .  11
  97        3.1.4.  Padding TLV . . . . . . . . . . . . . . . . . . . . .  12
  98        3.1.5.  HMAC TLV  . . . . . . . . . . . . . . . . . . . . . .  13
  99      3.2.  SRH and RFC2460 behavior  . . . . . . . . . . . . . . . .  14
 100    4.  SRH Procedures  . . . . . . . . . . . . . . . . . . . . . . .  14
 101      4.1.  Source SR Node  . . . . . . . . . . . . . . . . . . . . .  14
 102      4.2.  Transit Node  . . . . . . . . . . . . . . . . . . . . . .  15
 103      4.3.  SR Segment Endpoint Node  . . . . . . . . . . . . . . . .  16
 104    5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
 105
 106
 107
 108 Previdi, et al.          Expires August 5, 2017                 [Page 2]
 109
 110 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 111
 112
 113      5.1.  Threat model  . . . . . . . . . . . . . . . . . . . . . .  17
 114        5.1.1.  Source routing threats  . . . . . . . . . . . . . . .  17
 115        5.1.2.  Applicability of RFC 5095 to SRH  . . . . . . . . . .  17
 116        5.1.3.  Service stealing threat . . . . . . . . . . . . . . .  18
 117        5.1.4.  Topology disclosure . . . . . . . . . . . . . . . . .  18
 118        5.1.5.  ICMP Generation . . . . . . . . . . . . . . . . . . .  18
 119      5.2.  Security fields in SRH  . . . . . . . . . . . . . . . . .  19
 120        5.2.1.  Selecting a hash algorithm  . . . . . . . . . . . . .  20
 121        5.2.2.  Performance impact of HMAC  . . . . . . . . . . . . .  21
 122        5.2.3.  Pre-shared key management . . . . . . . . . . . . . .  21
 123      5.3.  Deployment Models . . . . . . . . . . . . . . . . . . . .  22
 124        5.3.1.  Nodes within the SR domain  . . . . . . . . . . . . .  22
 125        5.3.2.  Nodes outside of the SR domain  . . . . . . . . . . .  22
 126        5.3.3.  SR path exposure  . . . . . . . . . . . . . . . . . .  23
 127        5.3.4.  Impact of BCP-38  . . . . . . . . . . . . . . . . . .  23
 128    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
 129    7.  Manageability Considerations  . . . . . . . . . . . . . . . .  24
 130    8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  24
 131    9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
 132    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
 133      10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
 134      10.2.  Informative References . . . . . . . . . . . . . . . . .  25
 135    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27
 136
 137 1.  Segment Routing Documents
 138
 139    Segment Routing terminology is defined in
 140    [I-D.ietf-spring-segment-routing].
 141
 142    Segment Routing use cases are described in [RFC7855] and
 143    [I-D.ietf-spring-ipv6-use-cases].
 144
 145    Segment Routing protocol extensions are defined in
 146    [I-D.ietf-isis-segment-routing-extensions], and
 147    [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
 148
 149 2.  Introduction
 150
 151    Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing],
 152    allows a node to steer a packet through a controlled set of
 153    instructions, called segments, by prepending an SR header to the
 154    packet.  A segment can represent any instruction, topological or
 155    service-based.  SR allows to enforce a flow through any path
 156    (topological or service/application based) while maintaining per-flow
 157    state only at the ingress node to the SR domain.  Segments can be
 158    derived from different components: IGP, BGP, Services, Contexts,
 159    Locators, etc.  The list of segment forming the path is called the
 160    Segment List and is encoded in the packet header.
 161
 162
 163
 164 Previdi, et al.          Expires August 5, 2017                 [Page 3]
 165
 166 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 167
 168
 169    SR allows the use of strict and loose source based routing paradigms
 170    without requiring any additional signaling protocols in the
 171    infrastructure hence delivering an excellent scalability property.
 172
 173    The source based routing model described in
 174    [I-D.ietf-spring-segment-routing] is inherited from the ones proposed
 175    by [RFC1940] and [RFC2460].  The source based routing model offers
 176    the support for explicit routing capability.
 177
 178 2.1.  Data Planes supporting Segment Routing
 179
 180    Segment Routing (SR), can be instantiated over MPLS
 181    ([I-D.ietf-spring-segment-routing-mpls]) and IPv6.  This document
 182    defines its instantiation over the IPv6 data-plane based on the use-
 183    cases defined in [I-D.ietf-spring-ipv6-use-cases].
 184
 185    This document defines a new type of Routing Header (originally
 186    defined in [RFC2460]) called the Segment Routing Header (SRH) in
 187    order to convey the Segment List in the packet header as defined in
 188    [I-D.ietf-spring-segment-routing].  Mechanisms through which segment
 189    are known and advertised are outside the scope of this document.
 190
 191    A segment is materialized by an IPv6 address.  A segment identifies a
 192    topological instruction or a service instruction.  A segment can be
 193    either:
 194
 195    o  global: a global segment represents an instruction supported by
 196       all nodes in the SR domain and it is instantiated through an IPv6
 197       address globally known in the SR domain.
 198
 199    o  local: a local segment represents an instruction supported only by
 200       the node who originates it and it is instantiated through an IPv6
 201       address that is known only by the local node.
 202
 203 2.2.  Segment Routing (SR) Domain
 204
 205    We define the concept of the Segment Routing Domain (SR Domain) as
 206    the set of nodes participating into the source based routing model.
 207    These nodes may be connected to the same physical infrastructure
 208    (e.g.: a Service Provider's network) as well as nodes remotely
 209    connected to each other (e.g.: an enterprise VPN or an overlay).
 210
 211    A non-exhaustive list of examples of SR Domains is:
 212
 213    o  The network of an operator, service provider, content provider,
 214       enterprise including nodes, links and Autonomous Systems.
 215
 216
 217
 218
 219
 220 Previdi, et al.          Expires August 5, 2017                 [Page 4]
 221
 222 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 223
 224
 225    o  A set of nodes connected as an overlay over one or more transit
 226       providers.  The overlay nodes exchange SR-enabled traffic with
 227       segments belonging solely to the overlay routers (the SR domain).
 228       None of the segments in the SR-enabled packets exchanged by the
 229       overlay belong to the transit networks
 230
 231    The source based routing model through its instantiation of the
 232    Segment Routing Header (SRH) defined in this document equally applies
 233    to all the above examples.
 234
 235    It is assumed in this document that the SRH is added to the packet by
 236    its source, consistently with the source routing model defined in
 237    [RFC2460].  For example:
 238
 239    o  At the node originating the packet (host, server).
 240
 241    o  At the ingress node of an SR domain where the ingress node
 242       receives an IPv6 packet and encapsulates it into an outer IPv6
 243       header followed by a Segment Routing header.
 244
 245 2.2.1.  SR Domain in a Service Provider Network
 246
 247    The following figure illustrates an SR domain consisting of an
 248    operator's network infrastructure.
 249
 250      (-------------------------- Operator 1 -----------------------)
 251      (                                                             )
 252      (  (-----AS 1-----)  (-------AS 2-------)  (----AS 3-------)  )
 253      (  (              )  (                  )  (               )  )
 254  A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1
 255      (  ( /|\  /|\  /| )  ( |\  /|\  /|\  /| )  ( |\  /|\  /| \ )  )
 256  A2--(--(/ | \/ | \/ | )  ( | \/ | \/ | \/ | )  ( | \/ | \/ |  \)--)--Z2
 257      (  (  | /\ | /\ | )  ( | /\ | /\ | /\ | )  ( | /\ | /\ |   )  )
 258      (  (  |/  \|/  \| )  ( |/  \|/  \|/  \| )  ( |/  \|/  \|   )  )
 259  A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3
 260      (  (              )  (                  )  (               )  )
 261      (  (--------------)  (------------------)  (---------------)  )
 262      (                                                             )
 263      (-------------------------------------------------------------)
 264
 265                    Figure 1: Service Provider SR Domain
 266
 267    Figure 1 describes an operator network including several ASes and
 268    delivering connectivity between endpoints.  In this scenario, Segment
 269    Routing is used within the operator networks and across the ASes
 270    boundaries (all being under the control of the same operator).  In
 271    this case segment routing can be used in order to address use cases
 272    such as end-to-end traffic engineering, fast re-route, egress peer
 273
 274
 275
 276 Previdi, et al.          Expires August 5, 2017                 [Page 5]
 277
 278 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 279
 280
 281    engineering, data-center traffic engineering as described in
 282    [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and
 283    [I-D.ietf-spring-resiliency-use-cases].
 284
 285    Typically, an IPv6 packet received at ingress (i.e.: from outside the
 286    SR domain), is classified according to network operator policies and
 287    such classification results into an outer header with an SRH applied
 288    to the incoming packet.  The SRH contains the list of segment
 289    representing the path the packet must take inside the SR domain.
 290    Thus, the SA of the packet is the ingress node, the DA (due to SRH
 291    procedures described in Section 4) is set as the first segment of the
 292    path and the last segment of the path is the egress node of the SR
 293    domain.
 294
 295    The path may include intra-AS as well as inter-AS segments.  It has
 296    to be noted that all nodes within the SR domain are under control of
 297    the same administration.  When the packet reaches the egress point of
 298    the SR domain, the outer header and its SRH are removed so that the
 299    destination of the packet is unaware of the SR domain the packet has
 300    traversed.
 301
 302    The outer header with the SRH is no different from any other
 303    tunneling encapsulation mechanism and allows a network operator to
 304    implement traffic engineering mechanisms so to efficiently steer
 305    traffic across his infrastructure.
 306
 307 2.2.2.  SR Domain in a Overlay Network
 308
 309    The following figure illustrates an SR domain consisting of an
 310    overlay network over multiple operator's networks.
 311
 312        (--Operator 1---)  (-----Operator 2-----)  (--Operator 3---)
 313        (               )  (                    )  (               )
 314    A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1
 315        ( /|\  /|\  /|  )  (  |\  /|\  /|\  /|  )  ( |\  /|\  /| \ )
 316    A2--(/ | \/ | \/ |  )  (  | \/ | \/ | \/ |  )  ( | \/ | \/ |  \)--C2
 317        (  | /\ | /\ |  )  (  | /\ | /\ | /\ |  )  ( | /\ | /\ |   )
 318        (  |/  \|/  \|  )  (  |/  \|/  \|/  \|  )  ( |/  \|/  \|   )
 319    A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3
 320        (               )  (  |    |         |  )  (               )
 321        (---------------)  (--|----|---------|--)  (---------------)
 322                              |    |         |
 323                              B1   B2        B3
 324
 325                         Figure 2: Overlay SR Domain
 326
 327
 328
 329
 330
 331
 332 Previdi, et al.          Expires August 5, 2017                 [Page 6]
 333
 334 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 335
 336
 337    Figure 2 describes an overlay consisting of nodes connected to three
 338    different network operators and forming a single overlay network
 339    where Segment routing packets are exchanged.
 340
 341    The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3.
 342    These nodes are connected to their respective network operator and
 343    form an overlay network.
 344
 345    Each node may originate packets with an SRH which contains, in the
 346    segment list of the SRH or in the DA, segments identifying other
 347    overlay nodes.  This implies that packets with an SRH may traverse
 348    operator's networks but, obviously, these SRHs cannot contain an
 349    address/segment of the transit operators 1, 2 and 3.  The SRH
 350    originated by the overlay can only contain address/segment under the
 351    administration of the overlay (e.g. address/segments supported by A1,
 352    A2, A3, B1, B2, B3, C1,C2 or C3).
 353
 354    In this model, the operator network nodes are transit nodes and,
 355    according to [RFC2460], MUST NOT inspect the routing extension header
 356    since they are not the DA of the packet.
 357
 358    It is a common practice in operators networks to filter out, at
 359    ingress, any packet whose DA is the address of an internal node and
 360    it is also possible that an operator would filter out any packet
 361    destined to an internal address and having an extension header in it.
 362
 363    This common practice does not impact the SR-enabled traffic between
 364    the overlay nodes as the intermediate transit networks never see a
 365    destination address belonging to their infrastructure.  These SR-
 366    enabled overlay packets will thus never be filtered by the transit
 367    operators.
 368
 369    In all cases, transit packets (i.e.: packets whose DA is outside the
 370    domain of the operator's network) will be forwarded accordingly
 371    without introducing any security concern in the operator's network.
 372    This is similar to tunneled packets.
 373
 374 3.  Segment Routing Extension Header (SRH)
 375
 376    A new type of the Routing Header (originally defined in [RFC2460]) is
 377    defined: the Segment Routing Header (SRH) which has a new Routing
 378    Type, (suggested value 4) to be assigned by IANA.
 379
 380    The Segment Routing Header (SRH) is defined as follows:
 381
 382
 383
 384
 385
 386
 387
 388 Previdi, et al.          Expires August 5, 2017                 [Page 7]
 389
 390 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 391
 392
 393      0                   1                   2                   3
 394      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 395     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 396     | Next Header   |  Hdr Ext Len  | Routing Type  | Segments Left |
 397     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 398     | First Segment |     Flags     |           RESERVED            |
 399     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 400     |                                                               |
 401     |            Segment List[0] (128 bits IPv6 address)            |
 402     |                                                               |
 403     |                                                               |
 404     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 405     |                                                               |
 406     |                                                               |
 407                                   ...
 408     |                                                               |
 409     |                                                               |
 410     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 411     |                                                               |
 412     |            Segment List[n] (128 bits IPv6 address)            |
 413     |                                                               |
 414     |                                                               |
 415     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 416     //                                                             //
 417     //         Optional Type Length Value objects (variable)       //
 418     //                                                             //
 419     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 420
 421    where:
 422
 423    o  Next Header: 8-bit selector.  Identifies the type of header
 424       immediately following the SRH.
 425
 426    o  Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH
 427       header in 8-octet units, not including the first 8 octets.
 428
 429    o  Routing Type: TBD, to be assigned by IANA (suggested value: 4).
 430
 431    o  Segments Left.  Defined in [RFC2460], it contains the index, in
 432       the Segment List, of the next segment to inspect.  Segments Left
 433       is decremented at each segment.
 434
 435    o  First Segment: contains the index, in the Segment List, of the
 436       first segment of the path which is in fact the last element of the
 437       Segment List.
 438
 439    o  Flags: 8 bits of flags.  Following flags are defined:
 440
 441
 442
 443
 444 Previdi, et al.          Expires August 5, 2017                 [Page 8]
 445
 446 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 447
 448
 449           0 1 2 3 4 5 6 7
 450          +-+-+-+-+-+-+-+-+
 451          |U|P|O|A|H|  U  |
 452          +-+-+-+-+-+-+-+-+
 453
 454          U: Unused and for future use.  SHOULD be unset on transmission
 455          and MUST be ignored on receipt.
 456
 457          P-flag: Protected flag.  Set when the packet has been rerouted
 458          through FRR mechanism by an SR endpoint node.
 459
 460          O-flag: OAM flag.  When set, it indicates that this packet is
 461          an operations and management (OAM) packet.
 462
 463          A-flag: Alert flag.  If present, it means important Type Length
 464          Value (TLV) objects are present.  See Section 3.1 for details
 465          on TLVs objects.
 466
 467          H-flag: HMAC flag.  If set, the HMAC TLV is present and is
 468          encoded as the last TLV of the SRH.  In other words, the last
 469          36 octets of the SRH represent the HMAC information.  See
 470          Section 3.1.5 for details on the HMAC TLV.
 471
 472    o  RESERVED: SHOULD be unset on transmission and MUST be ignored on
 473       receipt.
 474
 475    o  Segment List[n]: 128 bit IPv6 addresses representing the nth
 476       segment in the Segment List.  The Segment List is encoded starting
 477       from the last segment of the path.  I.e., the first element of the
 478       segment list (Segment List [0]) contains the last segment of the
 479       path while the last segment of the Segment List (Segment List[n])
 480       contains the first segment of the path.  The index contained in
 481       "Segments Left" identifies the current active segment.
 482
 483    o  Type Length Value (TLV) are described in Section 3.1.
 484
 485 3.1.  SRH TLVs
 486
 487    This section defines TLVs of the Segment Routing Header.
 488
 489    Type Length Value (TLV) contain optional information that may be used
 490    by the node identified in the DA of the packet.  It has to be noted
 491    that the information carried in the TLVs is not intended to be used
 492    by the routing layer.  Typically, TLVs carry information that is
 493    consumed by other components (e.g.: OAM) than the routing function.
 494
 495    Each TLV has its own length, format and semantic.  The code-point
 496    allocated (by IANA) to each TLV defines both the format and the
 497
 498
 499
 500 Previdi, et al.          Expires August 5, 2017                 [Page 9]
 501
 502 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 503
 504
 505    semantic of the information carried in the TLV.  Multiple TLVs may be
 506    encoded in the same SRH.
 507
 508    The "Length" field of the TLV is primarily used to skip the TLV while
 509    inspecting the SRH in case the node doesn't support or recognize the
 510    TLV codepoint.  The "Length" defines the TLV length in octets and not
 511    including the "Type" and "Length" fields.
 512
 513    The primary scope of TLVs is to give the receiver of the packet
 514    information related to the source routed path (e.g.: where the packet
 515    entered in the SR domain and where it is expected to exit).
 516
 517    Additional TLVs may be defined in the future.
 518
 519 3.1.1.  Ingress Node TLV
 520
 521    The Ingress Node TLV is optional and identifies the node this packet
 522    traversed when entered the SR domain.  The Ingress Node TLV has
 523    following format:
 524
 525     0                   1                   2                   3
 526     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 527    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 528    |      Type     |    Length     |   RESERVED    |     Flags     |
 529    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 530    |                                                               |
 531    |                 Ingress Node (16 octets)                      |
 532    |                                                               |
 533    |                                                               |
 534    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 535
 536    where:
 537
 538    o  Type: to be assigned by IANA (suggested value 1).
 539
 540    o  Length: 18.
 541
 542    o  RESERVED: 8 bits.  SHOULD be unset on transmission and MUST be
 543       ignored on receipt.
 544
 545    o  Flags: 8 bits.  No flags are defined in this document.
 546
 547    o  Ingress Node: 128 bits.  Defines the node where the packet is
 548       expected to enter the SR domain.  In the encapsulation case
 549       described in Section 2.2.1, this information corresponds to the SA
 550       of the encapsulating header.
 551
 552
 553
 554
 555
 556 Previdi, et al.          Expires August 5, 2017                [Page 10]
 557
 558 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 559
 560
 561 3.1.2.  Egress Node TLV
 562
 563    The Egress Node TLV is optional and identifies the node this packet
 564    is expected to traverse when exiting the SR domain.  The Egress Node
 565    TLV has following format:
 566
 567     0                   1                   2                   3
 568     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 569    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 570    |      Type     |    Length     |   RESERVED    |     Flags     |
 571    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 572    |                                                               |
 573    |                  Egress Node (16 octets)                      |
 574    |                                                               |
 575    |                                                               |
 576    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 577
 578    where:
 579
 580    o  Type: to be assigned by IANA (suggested value 2).
 581
 582    o  Length: 18.
 583
 584    o  RESERVED: 8 bits.  SHOULD be unset on transmission and MUST be
 585       ignored on receipt.
 586
 587    o  Flags: 8 bits.  No flags are defined in this document.
 588
 589    o  Egress Node: 128 bits.  Defines the node where the packet is
 590       expected to exit the SR domain.  In the encapsulation case
 591       described in Section 2.2.1, this information corresponds to the
 592       last segment of the SRH in the encapsulating header.
 593
 594 3.1.3.  Opaque Container TLV
 595
 596    The Opaque Container TLV is optional and has the following format:
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612 Previdi, et al.          Expires August 5, 2017                [Page 11]
 613
 614 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 615
 616
 617     0                   1                   2                   3
 618     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 619    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 620    |      Type     |    Length     |   RESERVED    |     Flags     |
 621    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 622    |                                                               |
 623    |             Opaque Container (16 octets)                      |
 624    |                                                               |
 625    |                                                               |
 626    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 627
 628    where:
 629
 630    o  Type: to be assigned by IANA (suggested value 3).
 631
 632    o  Length: 18.
 633
 634    o  RESERVED: 8 bits.  SHOULD be unset on transmission and MUST be
 635       ignored on receipt.
 636
 637    o  Flags: 8 bits.  No flags are defined in this document.
 638
 639    o  Opaque Container: 128 bits of opaque data not relevant for the
 640       routing layer.  Typically, this information is consumed by a non-
 641       routing component of the node receiving the packet (i.e.: the node
 642       in the DA).
 643
 644 3.1.4.  Padding TLV
 645
 646    The Padding TLV is optional and with the purpose of aligning the SRH
 647    on a 8 octet boundary.  The Padding TLV has the following format:
 648
 649     0                   1                   2                   3
 650     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 651    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 652    |     Type      |    Length     |      Padding (variable)       |
 653    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 654    //                    Padding (variable)                       //
 655    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 656
 657    where:
 658
 659    o  Type: to be assigned by IANA (suggested value 4).
 660
 661    o  Length: 1 to 7
 662
 663
 664
 665
 666
 667
 668 Previdi, et al.          Expires August 5, 2017                [Page 12]
 669
 670 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 671
 672
 673    o  Padding: from 1 to 7 octets of padding.  Padding bits have no
 674       semantic.  They SHOULD be set to 0 on transmission and MUST be
 675       ignored on receipt.
 676
 677    The following applies to the Padding TLV:
 678
 679    o  Padding TLV is optional and MAY only appear once in the SRH.  If
 680       present, it MUST have a length between 1 and 7 octets.
 681
 682    o  The Padding TLV is used in order to align the SRH total length on
 683       the 8 octet boundary.
 684
 685    o  When present, the Padding TLV MUST appear as the last TLV before
 686       the HMAC TLV (if HMAC TLV is present).
 687
 688    o  When present, the Padding TLV MUST have a length from 1 to 7 in
 689       order to align the SRH total lenght on a 8-octet boundary.
 690
 691    o  When a router inspecting the SRH encounters the Padding TLV, it
 692       MUST assume that no other TLV (other than the HMAC) follow the
 693       Padding TLV.
 694
 695 3.1.5.  HMAC TLV
 696
 697    HMAC TLV is optional and contains the HMAC information.  The HMAC TLV
 698    has the following format:
 699
 700     0                   1                   2                   3
 701     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 702    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 703    |      Type     |     Length    |          RESERVED             |
 704    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 705    |                      HMAC Key ID (4 octets)                   |
 706    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 707    |                                                              //
 708    |                      HMAC (32 octets)                        //
 709    |                                                              //
 710    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 711
 712    where:
 713
 714    o  Type: to be assigned by IANA (suggested value 5).
 715
 716    o  Length: 38.
 717
 718    o  RESERVED: 2 octets.  SHOULD be unset on transmission and MUST be
 719       ignored on receipt.
 720
 721
 722
 723
 724 Previdi, et al.          Expires August 5, 2017                [Page 13]
 725
 726 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 727
 728
 729    o  HMAC Key ID: 4 octets.
 730
 731    o  HMAC: 32 octets.
 732
 733    o  HMAC and HMAC Key ID usage is described in Section 5
 734
 735    The Following applies to the HMAC TLV:
 736
 737    o  When present, the HMAC TLV MUST be encoded as the last TLV of the
 738       SRH.
 739
 740    o  If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set.
 741
 742    o  When the H-flag is set in the SRH, the router inspecting the SRH
 743       MUST find the HMAC TLV in the last 38 octets of the SRH.
 744
 745 3.2.  SRH and RFC2460 behavior
 746
 747    The SRH being a new type of the Routing Header, it also has the same
 748    properties:
 749
 750       SHOULD only appear once in the packet.
 751
 752       Only the router whose address is in the DA field of the packet
 753       header MUST inspect the SRH.
 754
 755    Therefore, Segment Routing in IPv6 networks implies that the segment
 756    identifier (i.e.: the IPv6 address of the segment) is moved into the
 757    DA of the packet.
 758
 759    The DA of the packet changes at each segment termination/completion
 760    and therefore the final DA of the packet MUST be encoded as the last
 761    segment of the path.
 762
 763 4.  SRH Procedures
 764
 765    In this section we describe the different procedures on the SRH.
 766
 767 4.1.  Source SR Node
 768
 769    A Source SR Node can be any node originating an IPv6 packet with its
 770    IPv6 and Segment Routing Headers.  This include either:
 771
 772       A host originating an IPv6 packet.
 773
 774       An SR domain ingress router encapsulating a received IPv6 packet
 775       into an outer IPv6 header followed by an SRH.
 776
 777
 778
 779
 780 Previdi, et al.          Expires August 5, 2017                [Page 14]
 781
 782 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 783
 784
 785    The mechanism through which a Segment List is derived is outside of
 786    the scope of this document.  As an example, the Segment List may be
 787    obtained through:
 788
 789       Local path computation.
 790
 791       Local configuration.
 792
 793       Interaction with a centralized controller delivering the path.
 794
 795       Any other mechanism.
 796
 797    The following are the steps of the creation of the SRH:
 798
 799       Next Header and Hdr Ext Len fields are set according to [RFC2460].
 800
 801       Routing Type field is set as TBD (to be allocated by IANA,
 802       suggested value 4).
 803
 804       The Segment List is built with the FIRST segment of the path
 805       encoded in the LAST element of the Segment List.  Subsequent
 806       segments are encoded on top of the first segment.  Finally, the
 807       LAST segment of the path is encoded in the FIRST element of the
 808       Segment List.  In other words, the Segment List is encoded in the
 809       reverse order of the path.
 810
 811       The final DA of the packet is encoded as the last segment of the
 812       path (encoded in the first element of the Segment List).
 813
 814       The DA of the packet is set with the value of the first segment
 815       (found in the last element of the segment list).
 816
 817       The Segments Left field is set to n-1 where n is the number of
 818       elements in the Segment List.
 819
 820       The First Segment field is set to n-1 where n is the number of
 821       elements in the Segment List.
 822
 823       The packet is sent out towards the first segment (i.e.:
 824       represented in the packet DA).
 825
 826       HMAC TLV may be set according to Section 5.
 827
 828 4.2.  Transit Node
 829
 830    According to [RFC2460], the only node who is allowed to inspect the
 831    Routing Extension Header (and therefore the SRH), is the node
 832    corresponding to the DA of the packet.  Any other transit node MUST
 833
 834
 835
 836 Previdi, et al.          Expires August 5, 2017                [Page 15]
 837
 838 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 839
 840
 841    NOT inspect the underneath routing header and MUST forward the packet
 842    towards the DA and according to the IPv6 routing table.
 843
 844    In the example case described in Section 2.2.2, when SR capable nodes
 845    are connected through an overlay spanning multiple third-party
 846    infrastructure, it is safe to send SRH packets (i.e.: packet having a
 847    Segment Routing Header) between each other overlay/SR-capable nodes
 848    as long as the segment list does not include any of the transit
 849    provider nodes.  In addition, as a generic security measure, any
 850    service provider will block any packet destined to one of its
 851    internal routers, especially if these packets have an extended header
 852    in it.
 853
 854 4.3.  SR Segment Endpoint Node
 855
 856    The SR segment endpoint node is the node whose address is in the DA.
 857    The segment endpoint node inspects the SRH and does:
 858
 859    1.   IF DA = myself (segment endpoint)
 860    2.      IF Segments Left > 0 THEN
 861               decrement Segments Left
 862               update DA with Segment List[Segments Left]
 863    3.      ELSE continue IPv6 processing of the packet
 864                 End of processing.
 865    4.   Forward the packet out
 866
 867 5.  Security Considerations
 868
 869    This section analyzes the security threat model, the security issues
 870    and proposed solutions related to the new Segment Routing Header.
 871
 872    The Segment Routing Header (SRH) is simply another type of the
 873    routing header as described in RFC 2460 [RFC2460] and is:
 874
 875    o  Added by an SR edge router when entering the segment routing
 876       domain or by the originating host itself.  The source host can
 877       even be outside the SR domain;
 878
 879    o  inspected and acted upon when reaching the destination address of
 880       the IP header per RFC 2460 [RFC2460].
 881
 882    Per RFC2460 [RFC2460], routers on the path that simply forward an
 883    IPv6 packet (i.e. the IPv6 destination address is none of theirs)
 884    will never inspect and process the content of the SRH.  Routers whose
 885    one interface IPv6 address equals the destination address field of
 886    the IPv6 packet MUST parse the SRH and, if supported and if the local
 887    configuration allows it, MUST act accordingly to the SRH content.
 888
 889
 890
 891
 892 Previdi, et al.          Expires August 5, 2017                [Page 16]
 893
 894 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 895
 896
 897    According to RFC2460 [RFC2460], the default behavior of a non SR-
 898    capable router upon receipt of an IPv6 packet with SRH destined to an
 899    address of its, is to:
 900
 901    o  ignore the SRH completely if the Segment Left field is 0 and
 902       proceed to process the next header in the IPv6 packet;
 903
 904    o  discard the IPv6 packet if Segment Left field is greater than 0,
 905       it MAY send a Parameter Problem ICMP message back to the Source
 906       Address.
 907
 908 5.1.  Threat model
 909
 910 5.1.1.  Source routing threats
 911
 912    Using an SRH is similar to source routing, therefore it has some
 913    well-known security issues as described in RFC4942 [RFC4942] section
 914    2.1.1 and RFC5095 [RFC5095]:
 915
 916    o  amplification attacks: where a packet could be forged in such a
 917       way to cause looping among a set of SR-enabled routers causing
 918       unnecessary traffic, hence a Denial of Service (DoS) against
 919       bandwidth;
 920
 921    o  reflection attack: where a hacker could force an intermediate node
 922       to appear as the immediate attacker, hence hiding the real
 923       attacker from naive forensic;
 924
 925    o  bypass attack: where an intermediate node could be used as a
 926       stepping stone (for example in a De-Militarized Zone) to attack
 927       another host (for example in the datacenter or any back-end
 928       server).
 929
 930 5.1.2.  Applicability of RFC 5095 to SRH
 931
 932    First of all, the reader must remember this specific part of section
 933    1 of RFC5095 [RFC5095], "A side effect is that this also eliminates
 934    benign RH0 use-cases; however, such applications may be facilitated
 935    by future Routing Header specifications.".  In short, it is not
 936    forbidden to create new secure type of Routing Header; for example,
 937    RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a
 938    specific application confined in a single network.
 939
 940    In the segment routing architecture described in
 941    [I-D.ietf-spring-segment-routing] there are basically two kinds of
 942    nodes (routers and hosts):
 943
 944
 945
 946
 947
 948 Previdi, et al.          Expires August 5, 2017                [Page 17]
 949
 950 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
 951
 952
 953    o  nodes within the SR domain, which is within one single
 954       administrative domain, i.e., where all nodes are trusted anyway
 955       else the damage caused by those nodes could be worse than
 956       amplification attacks: traffic interception, man-in-the-middle
 957       attacks, more server DoS by dropping packets, and so on.
 958
 959    o  nodes outside of the SR domain, which is outside of the
 960       administrative segment routing domain hence they cannot be trusted
 961       because there is no physical security for those nodes, i.e., they
 962       can be replaced by hostile nodes or can be coerced in wrong
 963       behaviors.
 964
 965    The main use case for SR consists of the single administrative domain
 966    where only trusted nodes with SR enabled and configured participate
 967    in SR: this is the same model as in RFC6554 [RFC6554].  All non-
 968    trusted nodes do not participate as either SR processing is not
 969    enabled by default or because they only process SRH from nodes within
 970    their domain.
 971
 972    Moreover, all SR nodes ignore SRH created by outsiders based on
 973    topology information (received on a peering or internal interface) or
 974    on presence and validity of the HMAC field.  Therefore, if
 975    intermediate nodes ONLY act on valid and authorized SRH (such as
 976    within a single administrative domain), then there is no security
 977    threat similar to RH-0.  Hence, the RFC 5095 [RFC5095] attacks are
 978    not applicable.
 979
 980 5.1.3.  Service stealing threat
 981
 982    Segment routing is used for added value services, there is also a
 983    need to prevent non-participating nodes to use those services; this
 984    is called 'service stealing prevention'.
 985
 986 5.1.4.  Topology disclosure
 987
 988    The SRH may also contains IPv6 addresses of some intermediate SR-
 989    nodes in the path towards the destination, this obviously reveals
 990    those addresses to the potentially hostile attackers if those
 991    attackers are able to intercept packets containing SRH.  On the other
 992    hand, if the attacker can do a traceroute whose probes will be
 993    forwarded along the SR path, then there is little learned by
 994    intercepting the SRH itself.
 995
 996 5.1.5.  ICMP Generation
 997
 998    Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e.
 999    where the destination address is one of theirs) receive a Routing
1000    Header with unsupported Routing Type, the required behavior is:
1001
1002
1003
1004 Previdi, et al.          Expires August 5, 2017                [Page 18]
1005
1006 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1007
1008
1009    o  If Segments Left is zero, the node must ignore the Routing header
1010       and proceed to process the next header in the packet.
1011
1012    o  If Segments Left is non-zero, the node must discard the packet and
1013       send an ICMP Parameter Problem, Code 0, message to the packet's
1014       Source Address, pointing to the unrecognized Routing Type.
1015
1016    This required behavior could be used by an attacker to force the
1017    generation of ICMP message by any node.  The attacker could send
1018    packets with SRH (with Segment Left set to 0) destined to a node not
1019    supporting SRH.  Per RFC2460 [RFC2460], the destination node could
1020    generate an ICMP message, causing a local CPU utilization and if the
1021    source of the offending packet with SRH was spoofed could lead to a
1022    reflection attack without any amplification.
1023
1024    It must be noted that this is a required behavior for any unsupported
1025    Routing Type and not limited to SRH packets.  So, it is not specific
1026    to SRH and the usual rate limiting for ICMP generation is required
1027    anyway for any IPv6 implementation and has been implemented and
1028    deployed for many years.
1029
1030 5.2.  Security fields in SRH
1031
1032    This section summarizes the use of specific fields in the SRH.  They
1033    are based on a key-hashed message authentication code (HMAC).
1034
1035    The security-related fields in the SRH are instantiated by the HMAC
1036    TLV, containing:
1037
1038    o  HMAC Key-id, 32 bits wide;
1039
1040    o  HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not
1041       0).
1042
1043    The HMAC field is the output of the HMAC computation (per RFC 2104
1044    [RFC2104]) using a pre-shared key identified by HMAC Key-id and of
1045    the text which consists of the concatenation of:
1046
1047    o  the source IPv6 address;
1048
1049    o  First Segment field;
1050
1051    o  an octet of bit flags;
1052
1053    o  HMAC Key-id;
1054
1055    o  all addresses in the Segment List.
1056
1057
1058
1059
1060 Previdi, et al.          Expires August 5, 2017                [Page 19]
1061
1062 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1063
1064
1065    The purpose of the HMAC TLV is to verify the validity, the integrity
1066    and the authorization of the SRH itself.  If an outsider of the SR
1067    domain does not have access to a current pre-shared secret, then it
1068    cannot compute the right HMAC field and the first SR router on the
1069    path processing the SRH and configured to check the validity of the
1070    HMAC will simply reject the packet.
1071
1072    The HMAC TLV is located at the end of the SRH simply because only the
1073    router on the ingress of the SR domain needs to process it, then all
1074    other SR nodes can ignore it (based on local policy) because they
1075    trust the upstream router.  This is to speed up forwarding operations
1076    because SR routers which do not validate the SRH do not need to parse
1077    the SRH until the end.
1078
1079    The HMAC Key-id field allows for the simultaneous existence of
1080    several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
1081    well as pre-shared keys.  The HMAC Key-id field is opaque, i.e., it
1082    has neither syntax nor semantic except as an index to the right
1083    combination of pre-shared key and hash algorithm and except that a
1084    value of 0 means that there is no HMAC field.  Having an HMAC Key-id
1085    field allows for pre-shared key roll-over when two pre-shared keys
1086    are supported for a while when all SR nodes converged to a fresher
1087    pre-shared key.  It could also allow for interoperation among
1088    different SR domains if allowed by local policy and assuming a
1089    collision-free HMAC Key Id allocation.
1090
1091    When a specific SRH is linked to a time-related service (such as
1092    turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are
1093    identical, then it is important to refresh the shared-secret
1094    frequently as the HMAC validity period expires only when the HMAC
1095    Key-id and its associated shared-secret expires.
1096
1097 5.2.1.  Selecting a hash algorithm
1098
1099    The HMAC field in the HMAC TLV is 256 bit wide.  Therefore, the HMAC
1100    MUST be based on a hash function whose output is at least 256 bits.
1101    If the output of the hash function is 256, then this output is simply
1102    inserted in the HMAC field.  If the output of the hash function is
1103    larger than 256 bits, then the output value is truncated to 256 by
1104    taking the least-significant 256 bits and inserting them in the HMAC
1105    field.
1106
1107    SRH implementations can support multiple hash functions but MUST
1108    implement SHA-2 [FIPS180-4] in its SHA-256 variant.
1109
1110    NOTE: SHA-1 is currently used by some early implementations used for
1111    quick interoperations testing, the 160-bit hash value must then be
1112
1113
1114
1115
1116 Previdi, et al.          Expires August 5, 2017                [Page 20]
1117
1118 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1119
1120
1121    right-hand padded with 96 bits set to 0.  The authors understand that
1122    this is not secure but is ok for limited tests.
1123
1124 5.2.2.  Performance impact of HMAC
1125
1126    While adding an HMAC to each and every SR packet increases the
1127    security, it has a performance impact.  Nevertheless, it must be
1128    noted that:
1129
1130    o  the HMAC field is used only when SRH is added by a device (such as
1131       a home set-up box) which is outside of the segment routing domain.
1132       If the SRH is added by a router in the trusted segment routing
1133       domain, then, there is no need for an HMAC field, hence no
1134       performance impact.
1135
1136    o  when present, the HMAC field MUST only be checked and validated by
1137       the first router of the segment routing domain, this router is
1138       named 'validating SR router'.  Downstream routers may not inspect
1139       the HMAC field.
1140
1141    o  this validating router can also have a cache of <IPv6 header +
1142       SRH, HMAC field value> to improve the performance.  It is not the
1143       same use case as in IPsec where HMAC value was unique per packet,
1144       in SRH, the HMAC value is unique per flow.
1145
1146    o  Last point, hash functions such as SHA-2 have been optimized for
1147       security and performance and there are multiple implementations
1148       with good performance.
1149
1150    With the above points in mind, the performance impact of using HMAC
1151    is minimized.
1152
1153 5.2.3.  Pre-shared key management
1154
1155    The field HMAC Key-id allows for:
1156
1157    o  key roll-over: when there is a need to change the key (the hash
1158       pre-shared secret), then multiple pre-shared keys can be used
1159       simultaneously.  The validating routing can have a table of <HMAC
1160       Key-id, pre-shared secret> for the currently active and future
1161       keys.
1162
1163    o  different algorithms: by extending the previous table to <HMAC
1164       Key-id, hash function, pre-shared secret>, the validating router
1165       can also support simultaneously several hash algorithms (see
1166       section Section 5.2.1)
1167
1168    The pre-shared secret distribution can be done:
1169
1170
1171
1172 Previdi, et al.          Expires August 5, 2017                [Page 21]
1173
1174 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1175
1176
1177    o  in the configuration of the validating routers, either by static
1178       configuration or any SDN oriented approach;
1179
1180    o  dynamically using a trusted key distribution such as [RFC6407]
1181
1182    The intent of this document is NOT to define yet-another-key-
1183    distribution-protocol.
1184
1185 5.3.  Deployment Models
1186
1187 5.3.1.  Nodes within the SR domain
1188
1189    An SR domain is defined as a set of interconnected routers where all
1190    routers at the perimeter are configured to add and act on SRH.  Some
1191    routers inside the SR domain can also act on SRH or simply forward
1192    IPv6 packets.
1193
1194    The routers inside an SR domain can be trusted to generate SRH and to
1195    process SRH received on interfaces that are part of the SR domain.
1196    These nodes MUST drop all SRH packets received on an interface that
1197    is not part of the SR domain and containing an SRH whose HMAC field
1198    cannot be validated by local policies.  This includes obviously
1199    packet with an SRH generated by a non-cooperative SR domain.
1200
1201    If the validation fails, then these packets MUST be dropped, ICMP
1202    error messages (parameter problem) SHOULD be generated (but rate
1203    limited) and SHOULD be logged.
1204
1205 5.3.2.  Nodes outside of the SR domain
1206
1207    Nodes outside of the SR domain cannot be trusted for physical
1208    security; hence, they need to request by some trusted means (outside
1209    of the scope of this document) a complete SRH for each new connection
1210    (i.e. new destination address).  The received SRH MUST include an
1211    HMAC TLV which is computed correctly (see Section 5.2).
1212
1213    When an outside node sends a packet with an SRH and towards an SR
1214    domain ingress node, the packet MUST contain the HMAC TLV (with a
1215    Key-id and HMAC fields) and the the destination address MUST be an
1216    address of an SR domain ingress node .
1217
1218    The ingress SR router, i.e., the router with an interface address
1219    equals to the destination address, MUST verify the HMAC TLV.
1220
1221    If the validation is successful, then the packet is simply forwarded
1222    as usual for an SR packet.  As long as the packet travels within the
1223    SR domain, no further HMAC check needs to be done.  Subsequent
1224
1225
1226
1227
1228 Previdi, et al.          Expires August 5, 2017                [Page 22]
1229
1230 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1231
1232
1233    routers in the SR domain MAY verify the HMAC TLV when they process
1234    the SRH (i.e. when they are the destination).
1235
1236    If the validation fails, then this packet MUST be dropped, an ICMP
1237    error message (parameter problem) SHOULD be generated (but rate
1238    limited) and SHOULD be logged.
1239
1240 5.3.3.  SR path exposure
1241
1242    As the intermediate SR nodes addresses appears in the SRH, if this
1243    SRH is visible to an outsider then he/she could reuse this knowledge
1244    to launch an attack on the intermediate SR nodes or get some insider
1245    knowledge on the topology.  This is especially applicable when the
1246    path between the source node and the first SR domain ingress router
1247    is on the public Internet.
1248
1249    The first remark is to state that 'security by obscurity' is never
1250    enough; in other words, the security policy of the SR domain MUST
1251    assume that the internal topology and addressing is known by the
1252    attacker.  A simple traceroute will also give the same information
1253    (with even more information as all intermediate nodes between SID
1254    will also be exposed).  IPsec Encapsulating Security Payload
1255    [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP
1256    header must appear after any routing header (including SRH).
1257
1258    To prevent a user to leverage the gained knowledge by intercepting
1259    SRH, it it recommended to apply an infrastructure Access Control List
1260    (iACL) at the edge of the SR domain.  This iACL will drop all packets
1261    from outside the SR-domain whose destination is any address of any
1262    router inside the domain.  This security policy should be tuned for
1263    local operations.
1264
1265 5.3.4.  Impact of BCP-38
1266
1267    BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks
1268    whether the source address of packets received on an interface is
1269    valid for this interface.  The use of loose source routing such as
1270    SRH forces packets to follow a path which differs from the expected
1271    routing.  Therefore, if BCP-38 was implemented in all routers inside
1272    the SR domain, then SR packets could be received by an interface
1273    which is not expected one and the packets could be dropped.
1274
1275    As an SR domain is usually a subset of one administrative domain, and
1276    as BCP-38 is only deployed at the ingress routers of this
1277    administrative domain and as packets arriving at those ingress
1278    routers have been normally forwarded using the normal routing
1279    information, then there is no reason why this ingress router should
1280
1281
1282
1283
1284 Previdi, et al.          Expires August 5, 2017                [Page 23]
1285
1286 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1287
1288
1289    drop the SRH packet based on BCP-38.  Routers inside the domain
1290    commonly do not apply BCP-38; so, this is not a problem.
1291
1292 6.  IANA Considerations
1293
1294    This document makes the following registrations in the Internet
1295    Protocol Version 6 (IPv6) Parameters "Routing Type" registry
1296    maintained by IANA:
1297
1298    Suggested            Description             Reference
1299      Value
1300    ----------------------------------------------------------
1301       4         Segment Routing Header (SRH)    This document
1302
1303    In addition, this document request IANA to create and maintain a new
1304    Registry: "Segment Routing Header Type-Value Objects".  The following
1305    code-points are requested from the registry:
1306
1307    Registry: Segment Routing Header Type-Value Objects
1308
1309    Suggested         Description            Reference
1310      Value
1311    -----------------------------------------------------
1312       1         Ingress Node TLV          This document
1313       2         Egress Node  TLV          This document
1314       3         Opaque Container TLV      This document
1315       4         Padding TLV               This document
1316       5         HMAC TLV                  This document
1317
1318 7.  Manageability Considerations
1319
1320    TBD
1321
1322 8.  Contributors
1323
1324    Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra
1325    Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James
1326    Connolly, Aloys Augustin contributed to the content of this document.
1327
1328 9.  Acknowledgements
1329
1330    The authors would like to thank Ole Troan, Bob Hinden, Fred Baker,
1331    Brian Carpenter, Alexandru Petrescu and Punit Kumar Jaiswal for their
1332    comments to this document.
1333
1334
1335
1336
1337
1338
1339
1340 Previdi, et al.          Expires August 5, 2017                [Page 24]
1341
1342 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1343
1344
1345 10.  References
1346
1347 10.1.  Normative References
1348
1349    [FIPS180-4]
1350               National Institute of Standards and Technology, "FIPS
1351               180-4 Secure Hash Standard (SHS)", March 2012,
1352               <http://csrc.nist.gov/publications/fips/fips180-4/
1353               fips-180-4.pdf>.
1354
1355    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1356               Requirement Levels", BCP 14, RFC 2119,
1357               DOI 10.17487/RFC2119, March 1997,
1358               <http://www.rfc-editor.org/info/rfc2119>.
1359
1360    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
1361               (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
1362               December 1998, <http://www.rfc-editor.org/info/rfc2460>.
1363
1364    [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
1365               RFC 4303, DOI 10.17487/RFC4303, December 2005,
1366               <http://www.rfc-editor.org/info/rfc4303>.
1367
1368    [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
1369               of Type 0 Routing Headers in IPv6", RFC 5095,
1370               DOI 10.17487/RFC5095, December 2007,
1371               <http://www.rfc-editor.org/info/rfc5095>.
1372
1373    [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
1374               of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
1375               October 2011, <http://www.rfc-editor.org/info/rfc6407>.
1376
1377 10.2.  Informative References
1378
1379    [I-D.ietf-isis-segment-routing-extensions]
1380               Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
1381               Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
1382               "IS-IS Extensions for Segment Routing", draft-ietf-isis-
1383               segment-routing-extensions-09 (work in progress), October
1384               2016.
1385
1386    [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
1387               Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
1388               Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
1389               Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
1390               segment-routing-extensions-07 (work in progress), October
1391               2016.
1392
1393
1394
1395
1396 Previdi, et al.          Expires August 5, 2017                [Page 25]
1397
1398 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1399
1400
1401    [I-D.ietf-spring-ipv6-use-cases]
1402               Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and
1403               R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring-
1404               ipv6-use-cases-08 (work in progress), January 2017.
1405
1406    [I-D.ietf-spring-resiliency-use-cases]
1407               Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
1408               "Resiliency use cases in SPRING networks", draft-ietf-
1409               spring-resiliency-use-cases-08 (work in progress), October
1410               2016.
1411
1412    [I-D.ietf-spring-segment-routing]
1413               Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
1414               and R. Shakir, "Segment Routing Architecture", draft-ietf-
1415               spring-segment-routing-10 (work in progress), November
1416               2016.
1417
1418    [I-D.ietf-spring-segment-routing-mpls]
1419               Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
1420               Litkowski, S., Horneffer, M., Shakir, R.,
1421               jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
1422               with MPLS data plane", draft-ietf-spring-segment-routing-
1423               mpls-06 (work in progress), January 2017.
1424
1425    [RFC1940]  Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
1426               Zappala, "Source Demand Routing: Packet Format and
1427               Forwarding Specification (Version 1)", RFC 1940,
1428               DOI 10.17487/RFC1940, May 1996,
1429               <http://www.rfc-editor.org/info/rfc1940>.
1430
1431    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1432               Hashing for Message Authentication", RFC 2104,
1433               DOI 10.17487/RFC2104, February 1997,
1434               <http://www.rfc-editor.org/info/rfc2104>.
1435
1436    [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
1437               Defeating Denial of Service Attacks which employ IP Source
1438               Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
1439               May 2000, <http://www.rfc-editor.org/info/rfc2827>.
1440
1441    [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
1442               Co-existence Security Considerations", RFC 4942,
1443               DOI 10.17487/RFC4942, September 2007,
1444               <http://www.rfc-editor.org/info/rfc4942>.
1445
1446
1447
1448
1449
1450
1451
1452 Previdi, et al.          Expires August 5, 2017                [Page 26]
1453
1454 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1455
1456
1457    [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
1458               Routing Header for Source Routes with the Routing Protocol
1459               for Low-Power and Lossy Networks (RPL)", RFC 6554,
1460               DOI 10.17487/RFC6554, March 2012,
1461               <http://www.rfc-editor.org/info/rfc6554>.
1462
1463    [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
1464               Litkowski, S., Horneffer, M., and R. Shakir, "Source
1465               Packet Routing in Networking (SPRING) Problem Statement
1466               and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
1467               2016, <http://www.rfc-editor.org/info/rfc7855>.
1468
1469 Authors' Addresses
1470
1471    Stefano Previdi (editor)
1472    Cisco Systems, Inc.
1473    Via Del Serafico, 200
1474    Rome  00142
1475    Italy
1476
1477    Email: sprevidi@cisco.com
1478
1479
1480    Clarence Filsfils
1481    Cisco Systems, Inc.
1482    Brussels
1483    BE
1484
1485    Email: cfilsfil@cisco.com
1486
1487
1488    Brian Field
1489    Comcast
1490    4100 East Dry Creek Road
1491    Centennial, CO  80122
1492    US
1493
1494    Email: Brian_Field@cable.comcast.com
1495
1496
1497    Ida Leung
1498    Rogers Communications
1499    8200 Dixie Road
1500    Brampton, ON  L6T 0C1
1501    CA
1502
1503    Email: Ida.Leung@rci.rogers.com
1504
1505
1506
1507
1508 Previdi, et al.          Expires August 5, 2017                [Page 27]
1509
1510 Internet-Draft      IPv6 Segment Routing Header (SRH)      February 2017
1511
1512
1513    Jen Linkova
1514    Google
1515    1600 Amphitheatre Parkway
1516    Mountain View, CA 94043
1517    US
1518
1519    Email: furry@google.com
1520
1521
1522    Ebben Aries
1523    Facebook
1524    US
1525
1526    Email: exa@fb.com
1527
1528
1529    Tomoya Kosugi
1530    NTT
1531    3-9-11, Midori-Cho Musashino-Shi,
1532    Tokyo  180-8585
1533    JP
1534
1535    Email: kosugi.tomoya@lab.ntt.co.jp
1536
1537
1538    Eric Vyncke
1539    Cisco Systems, Inc.
1540    De Kleetlaann 6A
1541    Diegem  1831
1542    Belgium
1543
1544    Email: evyncke@cisco.com
1545
1546
1547    David Lebrun
1548    Universite Catholique de Louvain
1549    Place Ste Barbe, 2
1550    Louvain-la-Neuve, 1348
1551    Belgium
1552
1553    Email: david.lebrun@uclouvain.be
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564 Previdi, et al.          Expires August 5, 2017                [Page 28]