| < draft-ietf-dots-multihoming-12.txt | draft-ietf-dots-multihoming-13.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Boucadair | Network Working Group M. Boucadair | |||
| Internet-Draft Orange | Internet-Draft Orange | |||
| Intended status: Informational T. Reddy.K | Intended status: Informational T. Reddy.K | |||
| Expires: 23 October 2022 Akamai | Expires: 28 October 2022 Akamai | |||
| W. Pan | W. Pan | |||
| Huawei Technologies | Huawei Technologies | |||
| 21 April 2022 | 26 April 2022 | |||
| Multi-homing Deployment Considerations for Distributed-Denial-of-Service | Multi-homing Deployment Considerations for Distributed-Denial-of-Service | |||
| Open Threat Signaling (DOTS) | Open Threat Signaling (DOTS) | |||
| draft-ietf-dots-multihoming-12 | draft-ietf-dots-multihoming-13 | |||
| Abstract | Abstract | |||
| This document discusses multi-homing considerations for Distributed- | This document discusses multi-homing considerations for Distributed- | |||
| Denial-of-Service Open Threat Signaling (DOTS). The goal is to | Denial-of-Service Open Threat Signaling (DOTS). The goal is to | |||
| provide some guidance for DOTS clients and client-domain DOTS | provide some guidance for DOTS clients and client-domain DOTS | |||
| gateways when multihomed. | gateways when multihomed. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 23 October 2022. | This Internet-Draft will expire on 28 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 36 ¶ | skipping to change at page 2, line 36 ¶ | |||
| 5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8 | 5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8 | |||
| 5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8 | 5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream | 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream | |||
| ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream | 5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream | |||
| ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13 | 5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 15 | 9.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 1. Introduction | 1. Introduction | |||
| In many deployments, it may not be possible for a network to | In many deployments, it may not be possible for a network to | |||
| determine the cause of a distributed Denial-of-Service (DoS) attack | determine the cause of a distributed Denial-of-Service (DoS) attack | |||
| [RFC4732]. Rather, the network may just realize that some resources | [RFC4732]. Rather, the network may just realize that some resources | |||
| appear to be under attack. To help with such situations, the IETF | appear to be under attack. To help with such situations, the IETF | |||
| skipping to change at page 4, line 46 ¶ | skipping to change at page 4, line 46 ¶ | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. Terminology | 3. Terminology | |||
| This document makes use of the terms defined in [RFC8811], [RFC8612], | This document makes use of the terms defined in [RFC8811], [RFC8612], | |||
| and [RFC4116]. In particular: | and [RFC4116]. In particular: | |||
| Provider-Aggregatable (PA) addresses: are globally-unique addresses | Provider-Aggregatable (PA) addresses: globally-unique addresses | |||
| assigned by a transit provider to a customer. The addresses are | assigned by a transit provider to a customer. The addresses are | |||
| considered "aggregatable" because the set of routes corresponding | considered "aggregatable" because the set of routes corresponding | |||
| to the PA addresses are usually covered by an aggregate route set | to the PA addresses are usually covered by an aggregate route set | |||
| corresponding to the address space operated by the transit | corresponding to the address space operated by the transit | |||
| provider, from which the assignment was made (Section 2 of | provider, from which the assignment was made (Section 2 of | |||
| [RFC4116]). | [RFC4116]). | |||
| Provider-Independent (PI) addresses: are globally-unique addresses | Provider-Independent (PI) addresses: globally-unique addresses that | |||
| which are not assigned by a transit provider, but are provided by | are not assigned by a transit provider, but are provided by some | |||
| some other organisation, usually a Regional Internet Registry | other organisation, usually a Regional Internet Registry (RIR) | |||
| (RIR) (Section 2 of [RFC4116]). | (Section 2 of [RFC4116]). | |||
| IP indifferently refers to IPv4 or IPv6. | IP indifferently refers to IPv4 or IPv6. | |||
| 4. Multi-Homing Scenarios | 4. Multi-Homing Scenarios | |||
| This section describes some multi-homing scenarios that are relevant | This section describes some multi-homing scenarios that are relevant | |||
| to DOTS. In the following subsections, only the connections of | to DOTS. In the following subsections, only the connections of | |||
| border routers are shown; internal network topologies are not | border routers are shown; internal network topologies are not | |||
| elaborated. | elaborated. | |||
| skipping to change at page 6, line 44 ¶ | skipping to change at page 6, line 44 ¶ | |||
| Figure 2: Typical Multi-homed Residential CPE | Figure 2: Typical Multi-homed Residential CPE | |||
| 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs | 4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs | |||
| The scenario shown in Figure 3 is characterized as follows: | The scenario shown in Figure 3 is characterized as follows: | |||
| * The enterprise network is connected to the Internet using a single | * The enterprise network is connected to the Internet using a single | |||
| router. | router. | |||
| * That router is connected to multiple provisioning domains (i.e., | * That router is connected to multiple provisioning domains managed | |||
| managed by distinct administrative entities). | by distinct administrative entities. | |||
| Unlike the previous scenario, two sub-cases can be considered for an | Unlike the previous scenario, two sub-cases can be considered for an | |||
| enterprise network with regards to assigned addresses: | enterprise network with regards to assigned addresses: | |||
| 1. PI addresses/prefixes: The enterprise is the owner of the IP | 1. PI addresses/prefixes: The enterprise is the owner of the IP | |||
| addresses/prefixes; the same address/prefix is then used when | addresses/prefixes; the same address/prefix is then used when | |||
| establishing communications over any of the provisioning domains. | establishing communications over any of the provisioning domains. | |||
| 2. PA addresses/prefixes: Each of the provisioning domains assigns | 2. PA addresses/prefixes: Each of the provisioning domains assigns | |||
| IP addresses/prefixes to the enterprise network. These | IP addresses/prefixes to the enterprise network. These | |||
| skipping to change at page 10, line 10 ¶ | skipping to change at page 10, line 10 ¶ | |||
| domain other than the one that owns those addresses/prefixes. | domain other than the one that owns those addresses/prefixes. | |||
| Consequently, if a CPE detects a DDoS attack that spreads over all | Consequently, if a CPE detects a DDoS attack that spreads over all | |||
| its network attachments, it MUST contact all DOTS servers for | its network attachments, it MUST contact all DOTS servers for | |||
| mitigation purposes. | mitigation purposes. | |||
| The DOTS client MUST be able to associate a DOTS server with each | The DOTS client MUST be able to associate a DOTS server with each | |||
| provisioning domain it serves. For example, if the DOTS client is | provisioning domain it serves. For example, if the DOTS client is | |||
| provisioned with S1 using DHCP when attaching to a first network and | provisioned with S1 using DHCP when attaching to a first network and | |||
| with S2 using Protocol Configuration Option (PCO) [TS.24008] when | with S2 using Protocol Configuration Option (PCO) [TS.24008] when | |||
| attaching to a second network, the DOTS client must record the | attaching to a second network, the DOTS client must record the | |||
| interface from which a DOTS server was provisioned. DOTS signaling | interface from which a DOTS server was provisioned. A DOTS signaling | |||
| session to a given DOTS server must be established using the | session to a given DOTS server must be established using the | |||
| interface from which the DOTS server was provisioned. If a DOTS | interface from which the DOTS server was provisioned. If a DOTS | |||
| server is explicitly configured, DOTS signaling with that server must | server is explicitly configured, DOTS signaling with that server must | |||
| be established via the interfaces that are indicated in the explicit | be established via the interfaces that are indicated in the explicit | |||
| configuration or via any active interface if no interface is | configuration or via any active interface if no interface is | |||
| configured. | configured. | |||
| 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs | 5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs | |||
| Figure 6 illustrates the DOTS sessions that can be established with a | Figure 6 illustrates the DOTS sessions that can be established with a | |||
| client-domain DOTS gateway (hosted within the CPE as per Table 1), | client-domain DOTS gateway (hosted within the CPE as per Table 1), | |||
| which is enabled within the context of the scenario described in | which is enabled within the context of the scenario described in | |||
| Section 4.2. This deployment is characterized as follows: | Section 4.2. This deployment is characterized as follows: | |||
| * One of more DOTS clients are enabled in hosts located in the | * One or more DOTS clients are enabled in hosts located in the | |||
| internal network. | internal network. | |||
| * A client-domain DOTS gateway is enabled to aggregate and then | * A client-domain DOTS gateway is enabled to aggregate and then | |||
| relay the requests towards upstream DOTS servers. | relay the requests towards upstream DOTS servers. | |||
| +--+ | +--+ | |||
| .................... ----------|S1| | .................... ----------|S1| | |||
| . +---+ . / +--+ | . +---+ . / +--+ | |||
| . | C1|----+ ./ DOTS Server Domain #1 | . | C1|----+ ./ DOTS Server Domain #1 | |||
| . +---+ | . | . +---+ | . | |||
| skipping to change at page 11, line 8 ¶ | skipping to change at page 11, line 8 ¶ | |||
| '..................' ----------|S2| | '..................' ----------|S2| | |||
| +--+ | +--+ | |||
| DOTS Client Domain DOTS Server Domain #2 | DOTS Client Domain DOTS Server Domain #2 | |||
| Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple | Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple | |||
| DOTS Servers | DOTS Servers | |||
| When PA addresses/prefixes are in use, the same considerations | When PA addresses/prefixes are in use, the same considerations | |||
| discussed in Section 5.1 need to be followed by the client-domain | discussed in Section 5.1 need to be followed by the client-domain | |||
| DOTS gateway to contact its DOTS server(s). The client-domain DOTS | DOTS gateway to contact its DOTS server(s). The client-domain DOTS | |||
| gateways can be reachable from DOTS clients by using an unicast | gateways can be reachable from DOTS clients by using a unicast | |||
| address or an anycast address (Section 3.2.4 of [RFC8811]). | address or an anycast address (Section 3.2.4 of [RFC8811]). | |||
| Nevertheless, when PI addresses/prefixes are assigned and absent any | Nevertheless, when PI addresses/prefixes are assigned and absent any | |||
| policy, the client-domain DOTS gateway MUST send mitigation requests | policy, the client-domain DOTS gateway SHOULD send mitigation | |||
| to all its DOTS servers. Otherwise, the attack traffic may still be | requests to all its DOTS servers. Otherwise, the attack traffic may | |||
| delivered via the ISP which hasn't received the mitigation request. | still be delivered via the ISP that hasn't received the mitigation | |||
| request. | ||||
| An alternate deployment model is depicted in Figure 7. This | An alternate deployment model is depicted in Figure 7. This | |||
| deployment assumes that: | deployment assumes that: | |||
| * One or more DOTS clients are enabled in hosts located in the | * One or more DOTS clients are enabled in hosts located in the | |||
| internal network. These DOTS clients may use [RFC8973] to | internal network. These DOTS clients may use [RFC8973] to | |||
| discover their DOTS server(s). | discover their DOTS server(s). | |||
| * These DOTS clients communicate directly with upstream DOTS | * These DOTS clients communicate directly with upstream DOTS | |||
| servers. | servers. | |||
| skipping to change at page 11, line 45 ¶ | skipping to change at page 11, line 46 ¶ | |||
| | . +--+ . | | | . +--+ . | | |||
| +--------|C2|--------+ | +--------|C2|--------+ | |||
| . +--+ . | . +--+ . | |||
| '........' | '........' | |||
| DOTS Client | DOTS Client | |||
| Domain | Domain | |||
| Figure 7: Multiple DOTS Clients, Multiple DOTS Servers | Figure 7: Multiple DOTS Clients, Multiple DOTS Servers | |||
| If PI addresses/prefixes are in use, the DOTS client MUST send a | If PI addresses/prefixes are in use, the DOTS client MUST send a | |||
| mitigation request to all the DOTS servers. The use of anycast | mitigation request to all the DOTS servers. The use of the same | |||
| addresses to reach these DOTS servers is NOT RECOMMENDED. If a well- | anycast addresses to reach these DOTS servers is NOT RECOMMENDED. If | |||
| known anycast address is used to reach multiple DOTS servers, the CPE | a well-known anycast address is used to reach multiple DOTS servers, | |||
| may not be able to select the appropriate provisioning domain to | the CPE may not be able to select the appropriate provisioning domain | |||
| which the mitigation request should be forwarded. As a consequence, | to which the mitigation request should be forwarded. As a | |||
| the request may not be forwarded to the appropriate DOTS server. | consequence, the request may not be forwarded to the appropriate DOTS | |||
| server. | ||||
| If PA addresses/prefixes are used, the same considerations discussed | If PA addresses/prefixes are used, the same considerations discussed | |||
| in Section 5.1 need to be followed by the DOTS clients. Because DOTS | in Section 5.1 need to be followed by the DOTS clients. Because DOTS | |||
| clients are not embedded in the CPE and multiple addresses/prefixes | clients are not embedded in the CPE and multiple addresses/prefixes | |||
| may not be assigned to the DOTS client (typically in an IPv4 | may not be assigned to the DOTS client (typically in an IPv4 | |||
| context), some issues may arise in how to steer traffic towards the | context), some issues may arise in how to steer traffic towards the | |||
| appropriate DOTS server by using the appropriate source IP address. | appropriate DOTS server by using the appropriate source IP address. | |||
| These complications discussed in [RFC4116] are not specific to DOTS. | These complications discussed in [RFC4116] are not specific to DOTS. | |||
| Another deployment approach is to enable many DOTS clients; each of | Another deployment approach is to enable many DOTS clients; each of | |||
| skipping to change at page 13, line 29 ¶ | skipping to change at page 13, line 29 ¶ | |||
| . +---+ . | . +---+ . | |||
| '...............................' | '...............................' | |||
| DOTS Client Domain | DOTS Client Domain | |||
| Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple | Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple | |||
| DOTS Servers | DOTS Servers | |||
| When PI addresses/prefixes are used, DOTS clients MUST contact all | When PI addresses/prefixes are used, DOTS clients MUST contact all | |||
| the client-domain DOTS gateways to send a DOTS message. Client- | the client-domain DOTS gateways to send a DOTS message. Client- | |||
| domain DOTS gateways will then relay the request to the DOTS servers | domain DOTS gateways will then relay the request to the DOTS servers | |||
| as a function of local policy. Note that anycast addresses cannot be | as a function of local policy. Note that (same) anycast addresses | |||
| used to establish DOTS sessions between DOTS clients and client- | cannot be used to establish DOTS sessions between DOTS clients and | |||
| domain DOTS gateways because only one DOTS gateway will receive the | client-domain DOTS gateways because only one DOTS gateway will | |||
| mitigation request. | receive the mitigation request. | |||
| When PA addresses/prefixes are used, but no filter rules are provided | When PA addresses/prefixes are used, but no filter rules are provided | |||
| to DOTS clients, the latter MUST contact all client-domain DOTS | to DOTS clients, the latter MUST contact all client-domain DOTS | |||
| gateways simultaneously to send a DOTS message. Upon receipt of a | gateways simultaneously to send a DOTS message. Upon receipt of a | |||
| request by a client-domain DOTS gateway, it MUST check whether the | request by a client-domain DOTS gateway, it MUST check whether the | |||
| request is to be forwarded upstream (if the target IP prefix is | request is to be forwarded upstream (if the target IP prefix is | |||
| managed by the upstream server) or rejected. | managed by the upstream server) or rejected. | |||
| When PA addresses/prefixes are used, but specific filter rules are | When PA addresses/prefixes are used, but specific filter rules are | |||
| provided to DOTS clients using some means that are out of scope of | provided to DOTS clients using some means that are out of scope of | |||
| this document, the clients MUST select the appropriate client-domain | this document, the clients MUST select the appropriate client-domain | |||
| DOTS gateway to reach. The use of anycast addresses is NOT | DOTS gateway to reach. The use of the same anycast addresses is NOT | |||
| RECOMMENDED to reach client-domain DOTS gateways. | RECOMMENDED to reach client-domain DOTS gateways. | |||
| 5.4. Multi-Homed Enterprise: Single ISP | 5.4. Multi-Homed Enterprise: Single ISP | |||
| The key difference of the scenario described in Section 4.4 compared | The key difference of the scenario described in Section 4.4 compared | |||
| to the other scenarios is that multi-homing is provided by the same | to the other scenarios is that multi-homing is provided by the same | |||
| ISP. Concretely, that ISP can decide to provision the enterprise | ISP. Concretely, that ISP can decide to provision the enterprise | |||
| network with: | network with: | |||
| * The same DOTS server for all network attachments. | * The same DOTS server for all network attachments. | |||
| skipping to change at page 14, line 45 ¶ | skipping to change at page 14, line 45 ¶ | |||
| This document does not require any action from IANA. | This document does not require any action from IANA. | |||
| 8. Acknowledgements | 8. Acknowledgements | |||
| Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and | Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and | |||
| Christian Jacquenet for sharing their comments on the mailing list. | Christian Jacquenet for sharing their comments on the mailing list. | |||
| Thanks to Kirill Kasavchenko for the comments. | Thanks to Kirill Kasavchenko for the comments. | |||
| Thanks to Kathleen Moriarty for the secdir review, Joel Jaeggli for | Thanks to Kathleen Moriarty for the secdir review, Joel Jaeggli for | |||
| the opsdir review, and Mirja Kuhlewind for the tsvart review. | the opsdir review, Mirja Kuhlewind for the tsvart review, and Dave | |||
| Thaler for the Intdir review. | ||||
| Many thanks to Roman Danyliw for the careful AD review. | Many thanks to Roman Danyliw for the careful AD review. | |||
| Thanks to Lars Eggert, Robert Wilton, Paul Wouters, Erik Kline, and | Thanks to Lars Eggert, Robert Wilton, Paul Wouters, Erik Kline, and | |||
| Eric Vyncke for the IESG review. | Eric Vyncke for the IESG review. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, | [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, | |||
| "Default Address Selection for Internet Protocol Version 6 | "Default Address Selection for Internet Protocol Version 6 | |||
| (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, | (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, | |||
| End of changes. 17 change blocks. | ||||
| 30 lines changed or deleted | 34 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||