diff --git a/draft-ietf-dots-architecture.xml b/draft-ietf-dots-architecture.xml index e2334ce..501b894 100644 --- a/draft-ietf-dots-architecture.xml +++ b/draft-ietf-dots-architecture.xml @@ -18,6 +18,12 @@ + + + + + + ]> @@ -588,24 +594,15 @@ servers with which it has established signal channels, the client may unintentionally inflict additional network disruption on the resources it intends to protect. In one of the worst cases, a multi-homed DOTS client could cause a permanent routing loop of traffic destined for the client’s protected -protected services, as the uncoordinated DOTS servers’ mitigators all try to +services, as the uncoordinated DOTS servers’ mitigators all try to divert that traffic to their own scrubbing centers. The DOTS protocol itself provides no fool-proof method to prevent such self-inflicted harms as a result deploying multi-homed DOTS clients. If DOTS client implementations nevertheless include support for multi-homing, they are expected to be aware of the risks, and consequently to include measures -aimed at reducing the likelihood of negative outcomes. Simple measures might -include: - - - Requesting mitigation serially, ensuring only one mitigation request for -a given address space is active at any given time; - Dividing the protected resources among the DOTS servers, such that no two -mitigators will be attempting to divert and scrub the same traffic; - Restricting multi-homing to deployments in which all DOTS servers are -coordinating management of a shared pool of mitigation resources. - +aimed at reducing the likelihood of negative outcomes. Sample multi-homing deployment guidelines +and recommendations are elaborated in .
@@ -1214,7 +1211,6 @@ again in accordance with best current practices for network and host security. @@ -1233,12 +1229,326 @@ again in accordance with best current practices for network and host security. +
+ + DOTS may be deployed within networks that are connected to one single + upstream provider. It can also be enabled within networks that are + multi-homed. The reader may refer to for + an overview of multi-homing goals and motivations. - + This appendix discusses DOTS multi-homing considerations, + specifically to: + Complete the base DOTS architecture with multi-homing specifics. + Those specifics need to be taking into account because: + Send a DOTS mitigation request to an arbitrary DOTS server + won't help mitigating a DDoS attack. + + Blindly forking all DOTS mitigation requests among all + available DOTS servers is suboptimal. + Sequentially contacting DOTS servers may increase the delay + before a mitigation plan is enforced. + + Identify DOTS deployment schemes in a multi-homing context, where + DOTS service can be offered by all or a subset of upstream + providers. + Sketch guidelines and recommendations for placing DOTS requests + in multi-homed networks, e.g.,: + Select the appropriate DOTS server(s). + + Identify cases where anycast is not recommended. + + + + To that aim, this appendix adopts the following methodology: + Identify and extract viable deployment candidates from . + + Augment the description with multi-homing technicalities, e.g., + + One vs. multiple upstream network providers + + One vs. multiple interconnect routers + + Provider-Independent (PI) vs. Provider-Aggregatable (PA) + + + Describe the recommended behavior of DOTS clients and gateways + for each case. + + + Multi-homed DOTS agents are assumed to make use of the protocols + defined in and ; no specific extension is + required to the base DOTS protocols for deploying DOTS in a multihomed + context. + + provides some sample (non-exhaustive) + deployment schemes to illustrate how DOTS agents may be deployed for + each of the scenarios introduced in . + + + Scenario + + DOTS client + + DOTS gateway + + Residential CPE + + CPE + + N/A + + Single CPE, Multiple provisioning domains + + internal hosts or CPE + + CPE + + Multiple CPEs, Multiple provisioning domains + + internal hosts or all CPEs (rtr1 and rtr2) + + CPEs (rtr1 and rtr2) + + Multi-homed enterprise, Single provisioning domain + + internal hosts or all CPEs (rtr1 and rtr2) + + CPEs (rtr1 and rtr2) + + + These deployment schemes are further discussed in the following + sub-sections. + +
+ depicts DOTS signaling sessions + that are required to be established between a DOTS client (C) and DOTS + servers (S1, S2) for a multi-homed CPE. + + The DOTS client MUST resolve the DOTS server's name provided by a + provisioning domain using the DNS servers learned from the same + provisioning domain. The DOTS client MUST use the source address + selection algorithm defined in to + select the candidate source addresses to contact each of these DOTS + servers. DOTS signaling sessions must be established and maintained + with each of the DOTS servers because the mitigation scope of these + servers is restricted. The DOTS client SHOULD use the certificate + provisioned by a provisioning domain to authenticate itself to the + DOTS server provided by the same provisioning domain. When conveying a + mitigation request to protect the attack target(s), the DOTS client + among the DOTS servers available MUST select a DOTS server whose + network has assigned the prefixes from which target prefixes and + target IP addresses are derived. For example, mitigation request to + protect target resources bound to a PA IP address/prefix cannot be + honored by an provisioning domain other than the one that owns those + addresses/prefixes. Consequently, Typically, if a CPE detects a DDoS + attack on all its network attachments, it must contact both DOTS + servers for mitigation. Nevertheless, if the DDoS attack is received + from one single network, then only the DOTS server of that network + must be contacted. + + The DOTS client MUST be able to associate a DOTS server with each + provisioning domain. For example, if the DOTS client is provisioned + with S1 using DHCP when attaching to a first network and with S2 using + Protocol Configuration Option (PCO) when attaching to a second + network, the DOTS client must record the interface from which a DOTS + server was provisioned. DOTS signaling session to a given DOTS server + must be established using the interface from which the DOTS server was + provisioned. + +
+ +
+ +
+ illustrates a first set of DOTS + associations that can be established with a DOTS gateway is enabled in + the context of this scenario. This deployment is characterized as + follows: + + + One of more DOTS clients are enabled in hosts located in the + internal network. + + A DOTS getaway is enabled to aggregate/relay the requests to + upstream DOTS servers. + When PA addresses/prefixes are in used, the same + considerations discussed in are to be + followed by the DOTS gateway to contact its DOTS server(s). The DOTS + gateways can be reachable from DOTS client using a unicast or anycast + address. + + Nevertheless, when PI addresses/prefixes are assigned, the DOTS + gateway MUST sent the same request to all its DOTS servers. + +
+ + An alternate deployment model is depicted in . This deployment assumes that: + + + One of more DOTS clients are enabled in hosts located in the + internal network. + + These DOTS clients communicate directly with upstream DOTS + servers. + If PI addresses/prefixes are in use, the DOTS client can send + the mitigation request for all its PI addresses/prefixes to any one of + the DOTS servers. The use of anycast addresses is NOT RECOMMENDED. + + If PA addresses/prefxies are used, the same considerations + discussed in are to be followed by the + DOTS clients. Because DOTS clients are not located on the CPE and + multiple addreses/prefixes may not be assigned to the DOTS client + (IPv4 context, typically), some complications arise to steer the + traffic to the appropriate DOTS server using the appropriate source IP + address. These complications discussed in are not specific to DOTS . + +
+ + Another deployment approach is to enable many DOTS clients; each of + them responsible to handle communication with a specific DOTS server + (see ). Each DOTS client is provided with + policies (e.g., prefix filter) that will trigger DOTS communications + with the DOTS servers. The CPE MUST select the appropriate source IP + address when forwarding DOTS messages received from an internal DOTS + client. If anycast addresses are used to reach DOTS servers, the CPE + may not be able to select the appropriate provisioning domain to which + the mitigation request should be forwarded. As a consequence, the + request may not be forwarded to the appropriate DOTS server. + +
+ +
+ +
+ One specific problem for this scenario is to select the appropriate + exit router when contacting a given DOTS server. + + An alternative deployment scheme is shown in : + DOTS clients are enabled in hosts located in the internal + network. + + A DOTS gateway is enabled in each CPE (rtr1, rtr2). + + Each of these DOTS gateways communicate with the DOTS server of + the provisioning domain. + + + When PI addresses/prefixes are used, DOTS clients can contact any + of the DOTS gateways to send a DOTS message. DOTS gateway will then + relay the request to the DOTS server. Note that the use of anycast + addresses is NOT RECOMMENDED to establish DOTS signaling sessions + between DOTS client and DOTS gateways. + + When PA addresses/prefixes are used, but no filter rules are + provided to DOTS clients, these later MUST contact all DOTS gateways + simultaneously to send a DOTS message. Upon receipt of a request by a + DOTS gateway, it MUST check whether the request is to be forwarded + upstream or be rejected. + + When PA addresses/prefixes are used, but specific filter rules are + provided to DOTS clients using some means that are out of scope, these + later MUST select the appropriate DOTS gateway to be contacted. The + use of anycast is NOT RECOMMENDED to reach DOTS gateways. + +
+ +
+ +
+ The key difference of this scenario compared to the aforementioned + scenarios is that multi-homing is provided by the same ISP. + Concretely, that ISP can decided to provision the enterprise network + with: + + + The same DOTS server for all network attachments. + + Distinct DOTS servers for each network attachment. These DOTS + servers needs to coordinate when a mitigation action is received + from the enterprise network. + + + In both cases, DOTS agents enabled within the enterprise network + may decide to select one or all network attachments to place DOTS + mitigation requests. +
+