idnits 2.17.1 draft-francois-dots-ipv6-signal-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As regular signaling from the DOTS client to the DOTS server or the DOTS gateway might be affected by the attack traffic, it is important to maximize the delivering success of the signals by using alternative packets and/or paths to deliver it. As a result, it forces to have intermediate agents, DSRs, able to catch DOTS signals delivered through those auxiliary mechanisms. However, those agents MUST not always forward DOTS signal to the server in order to limit the induced overhead. Only if the regular signal is not received by the server, retrieving the signal from the DSRs is required, which has thus initiated by the DOTS server itself. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In such a particular scenario, DSRs are intermediate routers capable of processing the option. DOTS server MAY also receive IPV6 packets with the Hop-by-Hop option and could thus process it directly. It is till considered as asynchronous since the server MAY NOT receive the initial packet emitted by the client but a copy of the signal in another packet (done by an intermediate DSR/router). Otherwise, it MUST connect to the DSR (section Section 4.1) -- The document date (May 3, 2017) is 2512 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 385 -- Looks like a reference, but probably isn't: '2' on line 387 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-00 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-04 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-requirements (ref. 'I-D.ietf-dots-requirements') == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-01 ** Downref: Normative reference to an Informational draft: draft-krishnan-ipv6-hopbyhop (ref. 'I-D.krishnan-ipv6-hopbyhop') -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS J. Francois 3 Internet-Draft Inria 4 Intended status: Standards Track A. Lahmadi 5 Expires: November 4, 2017 University of Lorraine - LORIA 6 M. Davids 7 G. Moura 8 SIDN Labs 9 May 3, 2017 11 IPv6 DOTS Signal Option 12 draft-francois-dots-ipv6-signal-option-02 14 Abstract 16 DOTS client signal using original signal communication channel can 17 expect service degradation and even service disruption as any other 18 service over Internet but in more severe conditions because the 19 signal may have to be transmitted over congested paths due to the 20 denial-of-service attack. 22 This document specifies a fall-back asynchronous mechanism using an 23 intermediate agent to store DOTS signal information during a limited 24 period of time. This mechanism allows a DOTS server to request a 25 signal information stored by a DOTS client when no heartbeat is 26 received from the DOTS client. This intermediate agent called DOTS 27 Signal Repository have to be connected to the DOTS client and server 28 independently. The repository must be located and/or reached through 29 one or multiple network paths, preferably as most as possible 30 disjoint from regular signal channel, in order to increase its 31 reachability. The document introduces a set of support protocols to 32 build the asynchronous communication between the DOTS cient, server 33 and the repository. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 4, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Asynchronous DOTS signaling . . . . . . . . . . . . . . . . . 4 72 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Asynchronous process . . . . . . . . . . . . . . . . . . 5 75 2.4. Protocol requirements . . . . . . . . . . . . . . . . . . 6 76 3. DOTS Signal Repository . . . . . . . . . . . . . . . . . . . 7 77 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. Between DSR and DOTS server . . . . . . . . . . . . . . . 7 79 4.2. Between DSR and DOTS client . . . . . . . . . . . . . . . 7 80 4.2.1. Opportunistic DOTS signaling . . . . . . . . . . . . 8 81 4.2.1.1. Hop-by-Hop option encoding . . . . . . . . . . . 9 82 4.2.1.2. DOTS signal Option attributes . . . . . . . . . . 10 83 4.2.1.3. Example . . . . . . . . . . . . . . . . . . . . . 11 84 4.2.1.4. Option Processing . . . . . . . . . . . . . . . . 12 85 4.2.1.5. Deployment considerations . . . . . . . . . . . . 14 86 4.2.1.6. Impact on existing IP layer implementations . . . 15 87 4.2.2. IPv6 SRH . . . . . . . . . . . . . . . . . . . . . . 15 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 8.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 1.1. Overview 101 A distributed denial-of-service (DDoS) attack aims at rendering 102 machines or network resources unavailable. These attacks have grown 103 in frequency, intensity and target diversity 104 [I-D.ietf-dots-requirements]. Moreover, several protocols have been 105 utilized to amplify the intensity of the attacks [kuhrer2014exit], 106 peaking at several hundred gigabits per second. 108 DDoS Open Threat Signaling (DOTS) aims at defining a common and open 109 protocol to signal DDoS attacks to facilitate a coordinated response 110 to these attacks. This document specifies an asynchronous signaling 111 method that MAY be used between a DOTS client and server instead of 112 relying on purely synchronous communication as specified in 113 [I-D.ietf-dots-signal-channel]. Indeed initial signaling should be 114 done in real-time through connections between DOTS clients and severs 115 such that a client can forward signal information as soon as the 116 attack is detected. However, the signaling messages may have to be 117 forwarded through paths impacted by the attack itself, i.e. highly 118 congested. Asynchronous signaling in this document is an additional 119 mechanism which MAY propagate signal information in a less reactive 120 manner due to the use of an asynchronous communication channel but 121 through alternative paths in the network. It increases the 122 reachability of the DOTS server which will then in charge of 123 requesting the mitigation. 125 The proposed mechanism constitutes an additional signaling channel 126 but MUST NOT replace the original signaling channel used between DOTS 127 client and servers as the one defined in 128 [I-D.ietf-dots-signal-channel]. 130 To perform asynchronous communication, this document introduces DOTS 131 Signals Repository (DSR) which represents datastores where DOTS 132 clients can send signal information. This information is then stored 133 and the DOTS server can request it. In addition to provide a general 134 process for achieving asynchronous signaling, this document 135 introduces also a set of protocols which can support it. 137 1.2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The terms DOTS client, DOTS server, DOTS gateway, DOTS agents refers 144 to the terminology introduced in [I-D.ietf-dots-architecture]. 146 The following terms are introduced: 148 o DSR (DOTS signal repository): intermediate agent able to store 149 signal from clients during a limited period of time and which can 150 be requested by DOTS servers. 152 o Opportunistic DOTS signal: an IPv6 packet containing the signaling 153 attributes of an attack within the Hop-by-Hop extension header. 154 The purpose is the same as the DOTS signal. It is used to request 155 help for mitigating the attack. 157 o DOTS opportunistic-capable router: a router with the capacity to 158 decode the opportunistic DOTS signal and re-embed such an 159 information in other IPv6 packets. 161 o All DOTS opportunistic-capable agents are defined as the DOTS 162 agents supporting the opportunistic DOTS signal processing. 164 2. Asynchronous DOTS signaling 166 2.1. Motivation 168 The traffic generated by a DDoS can be characterized according to 169 various parameters, such as the layer (IP/ICMP or application), 170 maximum and instant throughput, among others. Regardless its nature, 171 we assume that for most cases, a DOTS client will be able to signal 172 back one or few messages, during the attack, to the DOTS phase. 174 We have the same behavior in other DDoS attacks. For instance, on 175 November 30th and December 1st, 2015, the Root DNS system was hit by 176 an application layer (DNS) attack [rootops-ddos]. Each one of the 13 177 root server letters (A-M) was hit by attacks peaking at 5 million 178 queries per second. By utilizing the RIPE Atlas DNSMON 179 infrastructure, we can see that during the DDoS attacks, most of the 180 root server letters remained reachable and able to respond to the DNS 181 request sent by the probes employed by the DNSMON [ripe-dnsmon-ddos]. 182 Few letters, however, had a packet loss rate of more than 99%. The 183 DNSMON probes, however, experience mostly delays in their DNS 184 requests instead. 186 As regular signaling from the DOTS client to the DOTS server or the 187 DOTS gateway might be affected by the attack traffic, it is important 188 to maximize the delivering success of the signals by using 189 alternative packets and/or paths to deliver it. As a result, it 190 forces to have intermediate agents, DSRs, able to catch DOTS signals 191 delivered through those auxiliary mechanisms. However, those agents 192 MUST not always forward DOTS signal to the server in order to limit 193 the induced overhead. Only if the regular signal is not received by 194 the server, retrieving the signal from the DSRs is required, which 195 has thus initiated by the DOTS server itself. 197 2.2. Architecture 199 DSR (DOTS Signal Repository) are additional REQUIRED datastores. 200 They are integrated in the DOTS architecture 201 [I-D.ietf-dots-architecture]as highlighted in Figure 1. (1) refers to 202 the regular signaling. (2) and (3) refers to the proposed auxiliary 203 mechanism. As shown in this figure, DSRs act as synchronizing agent 204 where the DOTS client drops signal information (2) (attack details). 205 On the contrary, the server will retrieve this information (3). 207 +-----------+ +-------------+ 208 | Mitigator | ~~~~~~~~~~ | DOTS Server |~~~~+ 209 +-----------+ +-------------+ |(3) 210 ^ v 211 | +----------------+ 212 (1)| | DOTS Signal | 213 | | Repository | 214 | +----------------+ 215 | ^ 216 +---------------+ +-------------+ |(2) 217 | Attack Target | ~~~~~~ | DOTS Client |~~~~+ 218 +---------------+ +-------------+ 220 Figure 1: Asynchronous signaling 222 2.3. Asynchronous process 224 This section describes the process of asynchronous DOTS signal 225 processing. In Figure Figure 1, there are two main communication 226 channels which are not synchronized: 228 o Between DOTS client and DSR: the client sends DOTS signal 229 information when a condition is satisfied. The condition MUST be 230 configured by the user but SHOULD be linked to information 231 provided by Attack target. For instance, when an attack is 232 detected, the client connects to DOTS server and in parallel sends 233 signal to one or more DSRs. 235 o Between DOTS server and DSR: the server will retrieve signal 236 information when a specific condition occurs. Such a condition is 237 linked with the probable occurrence of an attack. The server can 238 infer this condition when the client is not responsive anymore. 239 In [I-D.ietf-dots-signal-channel], an heartbeat mechanism is 240 defined. Hence, when no heartbeat is received from the client, 241 the server MUST try to get signal information by the asynchronous 242 communication channel. 244 Each communication channel can implement its own protocol. They are 245 NOT REQUIRED to be the same. 247 We have to note that the client condition to provide signals to the 248 DSR can be weaker than regular synchronous signaling between DOTS 249 client and server. Indeed, a client can signal to the DSR some 250 suspect activities for which no mitigation is required yet. However, 251 when the supposed attack is stronger provoking client disruption, the 252 latter is not able to provide any type of signaling anymore and the 253 server can thus retrieve information on prior stored signals. 255 2.4. Protocol requirements 257 DOTS signaling requirements are documented in 258 [I-D.ietf-dots-requirements]. 260 GEN-003 (Bidirectionality) requires that signal channel MUST enable 261 asynchronous communications between DOTS agent by allowing 262 unsolicited messages. Asynchronous signaling described in the 263 current document allows DOTS client to provide signals, which can be 264 retrieved later by DOTS server(s). 266 Because of this mechanism, there are requirements which are not 267 supported: OP-002 (Session Health Monitoring), OP-003 (Session 268 Redirection). Therefore, the fall-back asynchronous DOTS signaling 269 is an additionnal mechanism and MUST NOT replace regular signaling as 270 described in [I-D.ietf-dots-signal-channel]. 272 It is particularly designed to fulfill GEN-002 (Resilience and 273 Robustness) by increasing the signal delivery success even under the 274 severely constrained network conditions imposed by particular attack 275 traffic. 277 In addition, the fall-back asynchronous DOTS signal MUST specify a 278 TTL (Time-to-Live) used by DSRs to store received signal in a limited 279 period of time. It is different from mitigation lifetime but MUST be 280 lower or equals. 282 3. DOTS Signal Repository 284 DSRs have to be deployed and distributed in order to enhance its 285 reachability by the DOTS client. It is NOT REQUIRED that all DOTS 286 agents use the same set of DSRs and a DOTS client and server SHOULD 287 define their own set regarding their particular context, e.g. the 288 network topology. The Data channel [I-D.ietf-dots-data-channel] 289 between client and server MUST be used to configure it. As an 290 example in the case of the inter-domain scenario, the DOTS server can 291 inform the DOTS client to use DSRs scattered in multiple domains. 293 There is no restriction on the environment where DSRs can be 294 deployed. Two types of DSRs are mainly considered: 296 o Routers: they have low capacity to process and store received 297 signals but they are well distributed by nature in the network. 299 o Servers or stations: they provide higher computational power and 300 storage but are less distributed 302 Selection of protocols to use for asynchronous signaling MUST take 303 into account those specificities. 305 4. Protocol 307 4.1. Between DSR and DOTS server 309 To retrieve signals, the DOTS server MUST request the DSRs. Standard 310 protocols can be used. Requests from the DOTS server MUST specify a 311 client identifier and the DSRs returns all stored signal related to 312 this client. The protocol MUST provide integrity and authenticity 313 and SHOULD guarantee confidentiality. To limit entailed overhead 314 lightweight protocol SHOULD be used. COAP [RFC7252] over DTLS 315 [RFC6347] is RECOMMENDED when DSRs are servers. In the case of 316 routers acting as DSR, network management protocol such as SNMP 317 [RFC1157] or NETCONF [RFC6241] SHOULD be leveraged. 319 4.2. Between DSR and DOTS client 321 The signal sent by the DOTS client to the DSR is more prone to be 322 affected by attack traffic due to its proximity to the attack victim. 323 Similar protocol as between DSR and DOTS server can be used but it is 324 RECOMMENDED to convey the signal over multiple paths to increase the 325 reachability sucess 326 This document introduces two mechanisms to deliver the signal from 327 the DOTS client to the DSR: IPv6 opportunistic signaling using Hop- 328 by-Hop Option header; source routing using IPv6 Segment Routing 329 Header (SRH). 331 4.2.1. Opportunistic DOTS signaling 333 This section specifies a signalling mechanism that instead of 334 designing a new application-layer protocol, it utilizes the IPv6 Hop- 335 by-Hop header [RFC2460]. This header SHOULD be processed by 336 intermediate devices and it MUST be the first header in IPv6 337 extension headers [RFC7045]. 339 In such a particular scenario, DSRs are intermediate routers capable 340 of processing the option. DOTS server MAY also receive IPV6 packets 341 with the Hop-by-Hop option and could thus process it directly. It is 342 till considered as asynchronous since the server MAY NOT receive the 343 initial packet emitted by the client but a copy of the signal in 344 another packet (done by an intermediate DSR/router). Otherwise, it 345 MUST connect to the DSR (section Section 4.1) 347 The new option containing the attributes of the signalling message is 348 included in an opportunistic way in available IPv6 packets leaving a 349 network element. The DOTS client will thus embed the signalling 350 attributes into outgoing IPv6 packets not necessarily going to the 351 DOTS server. Intermediate routers receiving such a packet will 352 examine it and embed the same information into other IPv6 packets. 353 domain in this opportunistic way to increase the probability that 354 such a packet will be finally forwarded to a DOTS gateway or Server, 355 but also in controlled way to avoid that the mechanism is exploited 356 for a malicious purposes. 358 Only the Hop-by-Hop options header allows such behavior and using 359 Destination options header is not enough to make the DOTS signal 360 going through the network in an opportunistic way. Each network 361 element recognizing this new option will select the best fitted IPv6 362 packets to deliver the signal to the DOTS DSRs. For this reason the 363 Hop-by-Hop header option is essential to make such behavior compared 364 to other existing IPv6 extension headers [RFC6564]. 366 The goal is to provide an efficient mechanism where nodes in a IPv6 367 network facing a DDoS attack can deliver a DOTS signal message sent 368 by a DOTS client to the DOTS server. The specified mechanism does 369 not generate transport packets to carry the DOST signal message but 370 it only relies on existing IPv6 packets in the network to include 371 inside them a hop-by-hop extension header which contains an encoded 372 DOTS signal message. The solution defines a new IPv6 Hop-by-Hop 373 header option with the semantic that the network node SHOULD include 374 the option content within one or multiple outgoing IPv6 packets 375 available in that network node. 377 4.2.1.1. Hop-by-Hop option encoding 379 According to [RFC2460], options encoded into the IPv6 Hop-by-Hop 380 header are formatted as Type-Length-Values (TLVs). The option for 381 opportunistic DOTS signal is thus defined as described in Figure 2 383 0 7 15 22 31 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Option type |Option Data Len| DOTS Signal Attribute[1] | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | DOTS Signal Attribute[2] | ... | DOTS Signal Attribute[n] | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 2: Hop-by-Hop option encoding 392 The first byte defines the Hop-by-Hop Option type number allocated to 393 the DOTS opportunistic signalling. This number is not yet fixed but 394 the first three bits MUST be set to 0. The first two zero bits 395 indicate that routers which cannot handle the DOTS signal option will 396 continue to process other options. The third 0 bit means that the 397 option processing will not change the packet's final destination 398 [RFC2460]. 400 The second byte contains the length of the option content. The 401 content of the DOTS Signal option is a variable-length field that 402 contains one or more type-length-values (TLV) encoded DOTS signal 403 attributes, and has the format described in Figure 3. 405 0 7 15 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Attr Type | Attr Data Len | Attr Data ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 3: Hop-by-Hop option encoding 412 The Attr Type is 8-bit identifier of a DOTS signal attribute. 414 The Attr Data Len is 8-bit unsigned integer which is the length of 415 Attr Data in bytes. 417 The Attr Data is variable-length field that contains the data of the 418 attribute. 420 Since using TLVs in Hop-by-Hop options is known to be a factor of 421 attacks [I-D.krishnan-ipv6-hopbyhop], DOTS attributes are encoded 422 with fixed length when possible. 424 4.2.1.2. DOTS signal Option attributes 426 The first attribute embedded into the opportunistic DOTS signal is a 427 TTL (Time-to-Live) field which indicates the maximum number of 428 retransmission of the signal into another IPv6 packets until it MUST 429 be discarded. Remaining attributes are similar to the header fields 430 described in [I-D.ietf-dots-signal-channel] used to convey a DOTS 431 signal through a HTTP POST. 433 The sequence of attributes to be inserted within the header MUST 434 start with fixed-length attributes which are defined in the following 435 order: 437 o TTL: Time-to-Live. This is a mandatory attribute encoded in one 438 byte. 440 o Flags: one byte is reserved for flags. 441 The first bit indicates the type of the IP address of the host: 0 442 for IPv4, 1 for IPv6. The second bit indicate if the protocol to 443 use is TCP (1) or UDP (0). The third bit indicates if the message 444 is signed. The remaining bit are not used yet. 446 o host: the IP address of the DOTS server where the signal option 447 SHOULD be delivered. Depending on the flags, this field is 448 encoded in 4 or 16 bytes. 450 o port: the listening port of the DOTS server. It is encoded in 2 451 bytes. 453 The remaining attributes MUST be TLV encoded, and they are defined in 454 the following order: 456 o policy-id: defined in [I-D.ietf-dots-signal-channel]. 458 o target-ip: defined in [I-D.ietf-dots-signal-channel]. 459 However, each address or prefix is encoded in its own TLV element. 460 The distinction between IPv4 and IPv6 is done over the length of 461 the value. 463 o target-port: defined in [I-D.ietf-dots-signal-channel]. 464 However, each target port is encoded in its own TLV element. 466 o target-protocol: defined in [I-D.ietf-dots-signal-channel] 467 However each target protocol is encoded in its own TLV element. 469 o lifetime (lt): lifetime of the mitigation request defined in 470 [I-D.ietf-dots-signal-channel] 472 The encoded attributes MUST be included in the option header in the 473 order defined above. 475 Table 1 provides the value of types that are used by the TLV encoded 476 attributes. 478 +-----------------+-------+ 479 | Attribute type | Value | 480 +-----------------+-------+ 481 | policy-id | 0 | 482 | target-ip | 1 | 483 | target-port | 2 | 484 | target-protocol | 3 | 485 | lifetime | 4 | 486 +-----------------+-------+ 488 Table 1: TLV encoded attributes types 490 4.2.1.3. Example 492 Following is an example of an encoded Hop-by-Hop Option header to 493 signal that a web service is under attack. 495 0 7 15 22 31 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Next header | Hdr Ext Len=6 | TTL=128 | Flags=IPv4,TCP| 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | host=192.0.2.1 | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | port=443 | A. type=policy| Att Data Len=2| 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | 143 | Attr. type=ip| Att Data Len=4| 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | 192.0.2.20 | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Attr. type=ip |Att Data Len=16| | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 509 | | 510 + + 511 | | 512 + + 513 | 2001:db8:6401::1 | 514 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | |Attr. type=port| Att Data Len=2| 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | 8080 |Attr. type=port| Att Data Len=2| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | 443 |Attr.type=proto| Att Data Len=2| 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | TCP | Attr. type=lt | Att Data Len=2| 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | 600 | 1 | Opt Data Len=0| 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 4: Example of Hop-by-Hop DOTS signal encoding 528 In the previous example, the message is not signed and terminates 529 with padding. If it is the case, then the signature MUST BE added at 530 the end such that the integrity and authenticity can be checked by 531 the DOTS server or gateway. The TTL attributes MUST be excluded from 532 the signature calculation. 534 4.2.1.4. Option Processing 536 4.2.1.4.1. Opportunistic DOTS signal initialization by a DOTS client 538 When a DOTS client needs to inform the DOTS server that it is under 539 attack, it firstly makes a connection attempt and applies the 540 mechanisms described in [I-D.ietf-dots-signal-channel]. 542 In addition, it MAY activates an opportunistic mechanism to include 543 the Hop-by-Hop header option specified in this document in one or 544 multiple available IPv6 packets leaving the node. Because the DOTS 545 client location is independent of the signalling, it can be 546 positionned in a part of the network where there is no passing-by 547 traffic which can serve for opportunistic signalling. DOTS client 548 MAY also create and emit IPv6 datagrams without payload but with the 549 signal encoded in the Hop-by-Hop option header. 551 Otherwise, the selection of packets has to be configured a priori. 552 The configuration is composed of a sequence of rules defined in a 553 hierarchical order such that they are triggered in a sequential 554 manner. 556 The selection of packets has to be configured a priori. The 557 configuration is composed of a sequence of rules defined in a 558 hierarchical order such that they are triggered in a sequential 559 manner. 561 Each rule is defined by: 563 o a set of filters over the IPv6 packet headers. Only packets 564 matching those filters are selected for opportunistic signalling. 566 For instance, only packets heading to a given subnetwork or to 567 specific address close to a DOTS server can be selected to 568 increase the chance to reach the latter. 570 o a ratio to select only a proportion of packets matching the 571 filters in order to limit the induced overhead of the 572 opportunistic signalling. 574 o a timeout until the rule is active and selected IPv6 packets embed 575 the DOTS opportunistic signal. 577 The objective is to apply each ordered rule after another according 578 to their timeouts. The first rule is triggered immediately after the 579 opportunistic signalling is activated. 581 In all cases (embedding information into an exsiting packet or 582 creating an new pakket with no payload), the client MUST avoid 583 fragmentation. 585 Although the definition of rules MUST be configured by the user. It 586 is RECOMMENDED to order them inversely related to the number of 587 packets that would be selected. This can be approximated regarding 588 the definition of filters. The core idea is to benefit from the 589 first instants of the attack before losing connectivity by using a 590 maximum number of outgoing packets to include the DOTS signalling 591 option. It is thus RECOMMENDED to define the first as matching all 592 IPv6 packets with a ratio equals one to rapidly disseminate the 593 information but with a short timeout to limit the implied overhead. 595 Here is the an example of rules: 597 1. all outgoing IPv6 packets with a 10 second timeout 599 2. all outgoing IPv6 packets with a ratio of 10% and a 1 minute 600 timeout 602 3. all outgoing multicast IPv6 packets with a ratio of 10% and a 1 603 minute timeout 605 4. all outgoing IPv6 packets heading to the DOTS server with a ratio 606 of 100% and a one hour timeout 608 4.2.1.4.2. Processing by a non DOTS opportunistic-capable router 610 When receiving an opportunistic DOTS signal encoded in a IPv6 packet, 611 a non DOT opportunistic capable router simply skips the Hop-by-Hop 612 option and continue the normal processing of the IPv6 packet because 613 the option type MUST start with three zero bits. 615 4.2.1.4.3. Processing by a DOTS opportunistic-capable router 617 A DOTS opportunistic-capable router MUST store DOTS signalling 618 information whose it is aware of. If a router processes an IPv6 DOTS 619 opportunistic signal and supports this option, it first checks if it 620 has already stored the associated information. In that case, the 621 router simply skips the option and continues the normal processing 622 otherwise it stores the encoded information in order to embed it 623 again in other IPv6 packets similarly to the DOTS client. Hence, a 624 set of rules are also defined in advance and are triggered upon the 625 reception of a new opportunistic DOTS signal. Once all rule have 626 been applied, signalling information MUST be discarded by the router. 627 When embedding the information into other IPv6 packets, the router 628 MUST decrease the TTL by one since opportunistic signalling does not 629 prevent loops in the dissemination of signalling. 631 4.2.1.4.4. Processing by a DOTS opportunistic-capable gateway 633 If a DOTS gateway has DOTS capabilities, it will apply the same 634 strategy as a DOTS client by making attempts of direct connections to 635 the DOST server and in addition it inserts the Hop-by-Hop header DOTS 636 signalling option in leaving IPv6 packets using the strategy 637 specified above. 639 4.2.1.4.5. Processing by a DOTS opportunistic-capable server 641 When the IP layer of the host where the DOTS server is running 642 receives an IPv6 packet carrying a Hop-by-Hop DOTS signal option 643 header it MUST extracts the content of the option and provides the 644 attributes data to the server program. 646 4.2.1.5. Deployment considerations 648 This mechanism will be potentially used by networks with IPv6 capable 649 elements and requires that of IPv6 traffic exist in the network 650 during the attack. The existing IPv6 traffic to be used could be of 651 any type from management or user levels. It is also important to 652 emphasize that while our mechanism utilizes an IPv6 header field, it 653 can also be used to signal IPv4 attacks as well - given that the 654 network devices are dual stacked. 656 IPv6 extension headers are often rate-limited or dropped entirely. 657 To be able to use the mechanism specified in this document, network 658 operators need to avoid discarding packets or ignoring the processing 659 of the hop-by-hop option on their deployed network elements. 660 However, instead of dropping or ignoring packets with hop-by-hop 661 option carrying DOTS signal, they need to assign these packets to 662 slow forwarding path, and be processed by the router's CPU. This 663 behavior will not affect the performance of the network devices since 664 the network is already facing a DDoS attack and fast forwarding paths 665 are saturated by the attacker traffic. 667 If the DOTS server, gateway and the client are located in the same 668 administrative domain, marking the IPv6 packets with the proposed 669 hop-by-hop header option could be done in a straight forward way, 670 while considering that an agreement exists inside the domain to avoid 671 dropping or rate limiting of IPv6 extension headers as described 672 above. The proposed mechanism becomes less practical and difficult 673 to deploy when the DOST server is running on the Internet. In such 674 scenario, the mechanism could be used in the intra-domain part to 675 deliver the hop-by-hop option carrying the DOTS signal until it 676 reaches a DOTS gateway located in the same domain as the client, then 677 the gateway will apply mechanisms provided by the DOTS transport 678 protocol [I-D.ietf-dots-signal-channel] to inform the server running 679 on Internet about the attack. This deployment scenario requires that 680 at least one DOTS gateway is deployed in the same domain than the 681 DOTS client. 683 4.2.1.6. Impact on existing IP layer implementations 685 For this option to be applicable within an IP system, it requires 686 modifications to existing IP layer implementation. At DOTS capable 687 nodes (client, gateway and server), it requires a service interface 688 used by upper-layer protocols and application programs to ask the IP 689 layer to insert and listen to the Hop-by-Hop header option in IPv6 690 packets. A DOTS client invokes the service interface to insert the 691 option, A DOTS gateway invokes the service interface for listening 692 and inserting the option, and finally a DOTS server only invokes the 693 service interface to listen to the DOTS signalling option. 695 Intermediate nodes (routers or middle boxes) IP layer needs to be 696 extended to perform processing of the new Hop-by-Hop header option. 697 They mainly parse the first host attribute of the option and make a 698 selection of a leaving IPv6 packet where the option will be inserted. 700 Every node inserting the new proposed Hop-by-Hop option SHOULD only 701 select IPv6 packets with enough left space to avoid fragmentation. 703 4.2.2. IPv6 SRH 705 DOTS signalling may be carried using IPv6 source routing header. 706 Details will be provided in a later version of this document. 708 5. Security Considerations 709 Any IPv6 header option could be used by an attacker to create an 710 attack on the routers and intermediate boxes that process packets 711 containing the option. The proposed IPv6 option in this document MAY 712 be abused by an attacker to create a covert channel at the IP layer 713 where data is hidden inside the content of the option [RFC6564]. 714 However, this attack is not specific to the proposed option and it is 715 a known issue of IPv6 header extensions and options. The option MAY 716 also be used by an attacker to forge or modify opportunistic DOTS 717 signal leading to trigger additional processing on intermediate nodes 718 and DOTS servers. 720 However the proposed option should be only initiated by a DOTS client 721 and information embedded in new IPv6 messages by opportunistic DOTS 722 capable routers. Defining proper policies to filter all messages 723 with this option set and originated from other nodes would limit 724 security issues since these DOTS opportunistic-capable agents SHOULD 725 be trustworhy. 727 In addition, the message MAY be signed using techniques to enforce 728 authenticity and integrity over the opportunistic DOTS signal 729 channel. The signalling message specification includes a flag to 730 indicate if the message is signed by the choice of the signature 731 algorithm is let to the users. This signature has to be computed by 732 the DOTS opportunistic-capable client and checked by the DOTS 733 opportunistic-capable gateway or router. Hence, intermediate routers 734 MUST NOT modify the message and its signature except the TTL, which 735 so has not be considered during the signature computation. 737 Assuming a compromised router, the attacker could nevertheless replay 738 the message or increase the TTL but thanks to the unique policy-id 739 all intermediate-DOTS capable router will drop such messages and thus 740 limiting their forwarding in the network. 742 Besides, an attacker can also listen opportunistic DOTS signals to 743 monitor the impact of its own attack. These considerations are not 744 specific to the proposed option and supposes that the attacker is 745 able to compromise intermediate routers. 747 6. IANA Considerations 749 This draft defines a new IPv6 hop-by-hop option[RFC2460].This 750 requires an IANA RFC3692-style update of:http://www.iana.org/ 751 assignments/ipv6-parameters/ipv6-parameters.xhtml and ultimately the 752 assignment of a new hop-by-hop option according to the guidelines 753 described in [RFC5237]. 755 7. Acknowledgements 756 This work is partly funded by FLAMINGO, a Network of Excellence 757 Seventh Framework Programme. 759 8. References 761 8.1. Normative References 763 [I-D.ietf-dots-architecture] 764 Mortensen, A., Andreasen, F., Reddy, T., 765 christopher_gray3@cable.comcast.com, c., Compton, R., and 766 N. Teague, "Distributed-Denial-of-Service Open Threat 767 Signaling (DOTS) Architecture", draft-ietf-dots- 768 architecture-01 (work in progress), October 2016. 770 [I-D.ietf-dots-data-channel] 771 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 772 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 773 Service Open Threat Signaling (DOTS) Data Channel", draft- 774 ietf-dots-data-channel-00 (work in progress), April 2017. 776 [I-D.ietf-dots-requirements] 777 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 778 Denial of Service (DDoS) Open Threat Signaling 779 Requirements", draft-ietf-dots-requirements-04 (work in 780 progress), March 2017. 782 [I-D.ietf-dots-signal-channel] 783 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 784 Teague, "Distributed Denial-of-Service Open Threat 785 Signaling (DOTS) Signal Channel", draft-ietf-dots-signal- 786 channel-01 (work in progress), April 2017. 788 [I-D.krishnan-ipv6-hopbyhop] 789 Krishnan, S., "The case against Hop-by-Hop options", 790 draft-krishnan-ipv6-hopbyhop-05 (work in progress), 791 October 2010. 793 8.2. Informative References 795 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 796 "Simple Network Management Protocol (SNMP)", RFC 1157, DOI 797 10.17487/RFC1157, May 1990, 798 . 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 802 RFC2119, March 1997, 803 . 805 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 806 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 807 December 1998, . 809 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 810 the Protocol Field", BCP 37, RFC 5237, DOI 10.17487/ 811 RFC5237, February 2008, 812 . 814 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 815 and A. Bierman, Ed., "Network Configuration Protocol 816 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 817 . 819 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 820 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 821 January 2012, . 823 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 824 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 825 RFC 6564, DOI 10.17487/RFC6564, April 2012, 826 . 828 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 829 of IPv6 Extension Headers", RFC 7045, DOI 10.17487/ 830 RFC7045, December 2013, 831 . 833 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 834 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 835 RFC7252, June 2014, 836 . 838 [kuhrer2014exit] 839 M. Kuhrer, T. Hupperich, C. Rossow, T. Holz, "Exit from 840 Hell? Reducing the Impact of Amplification DDoS Attacks", 841 USENIX Security Symposium 23rd, 2014. 843 [ripe-dnsmon-ddos] 844 RIPE, "NCC DNS Monitoring Service (DNSMON)", . 847 [rootops-ddos] 848 rootops., "Events of 2015-11-30", 2015, 849 . 851 Appendix A. Additional Stuff 852 This becomes an Appendix. 854 Authors' Addresses 856 Jerome Francois 857 Inria 858 615 rue du jardin botanique 859 Villers-les-Nancy 54600 860 FR 862 Phone: +33 3 83 59 30 66 863 Email: jerome.francois@inria.fr 865 Abdelkader Lahmadi 866 University of Lorraine - LORIA 867 615 rue du jardin botanique 868 Villers-les-Nancy 54600 869 FR 871 Phone: +33 3 83 59 30 00 872 Email: Abdelkader.Lahmadi@loria.fr 874 Marco Davids 875 SIDN Labs 876 Meander 501 877 Arnhem 6825 MD 878 NL 880 Email: marco.davids@sidn.nl 882 Giovane Moura 883 SIDN Labs 884 Meander 501 885 Arnhem 6825 MD 886 NL 888 Email: marco.davids@sidn.nl