| < draft-li-spring-srv6-security-consideration-07.txt | draft-li-spring-srv6-security-consideration-08.txt > | |||
|---|---|---|---|---|
| Spring C. Li | Spring C. Li | |||
| Internet-Draft Z. Li | Internet-Draft Z. Li | |||
| Intended status: Informational Huawei | Intended status: Informational Huawei | |||
| Expires: April 24, 2022 C. Xie | Expires: 24 October 2022 C. Xie | |||
| China Telecom | China Telecom | |||
| H. Tian | H. Tian | |||
| CAICT | CAICT | |||
| J. Mao | J. Mao | |||
| Huawei | Huawei | |||
| October 21, 2021 | 22 April 2022 | |||
| Security Considerations for SRv6 Networks | Security Considerations for SRv6 Networks | |||
| draft-li-spring-srv6-security-consideration-07 | draft-li-spring-srv6-security-consideration-08 | |||
| Abstract | Abstract | |||
| SRv6 inherits potential security vulnerabilities from Source Routing | SRv6 inherits potential security vulnerabilities from Source Routing | |||
| in general, and also from IPv6. This document describes various | in general, and also from IPv6. This document describes various | |||
| threats and security concerns related to SRv6 networks and existing | threats and security concerns related to SRv6 networks and existing | |||
| approaches to solve these threats. | approaches to solve these threats. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
| 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 April 24, 2022. | This Internet-Draft will expire on 24 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 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 | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Security Principles of SRv6 Networking . . . . . . . . . . . 4 | 3. Security Principles of SRv6 Networking . . . . . . . . . . . 4 | |||
| 4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4 | 4. Types of Vulnerabilities in SR Networks . . . . . . . . . . . 4 | |||
| 4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4 | 4.1. Eavesdropping Vulnerabilities in SRv6 Networks . . . . . 4 | |||
| 4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5 | 4.2. Packet Falsification in SRv6 Networks . . . . . . . . . . 5 | |||
| 4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 6 | 4.3. Identity Spoofing in SRv6 Networks . . . . . . . . . . . 7 | |||
| 4.4. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 7 | 4.4. Packet Replay in SRv6 Networks . . . . . . . . . . . . . 7 | |||
| 4.5. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 7 | 4.5. DOS/DDOS in SRv6 Networks . . . . . . . . . . . . . . . . 8 | |||
| 4.6. Malicious Packet Data in SRv6 Networks . . . . . . . . . 8 | 4.6. Malicious Packet Data in SRv6 Networks . . . . . . . . . 8 | |||
| 5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 8 | 5. Effects of the above on SRv6 Use Cases . . . . . . . . . . . 8 | |||
| 6. Security Policy Design . . . . . . . . . . . . . . . . . . . 8 | 6. Security Policy Design . . . . . . . . . . . . . . . . . . . 8 | |||
| 6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 9 | 6.1. Basic Security Design . . . . . . . . . . . . . . . . . . 9 | |||
| 6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 9 | 6.1.1. ACL for External Interfaces . . . . . . . . . . . . . 9 | |||
| 6.1.2. ACL for Internal Interfaces . . . . . . . . . . . . . 9 | 6.1.2. ACL for Internal Interfaces . . . . . . . . . . . . . 9 | |||
| 6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 9 | 6.1.3. SID Instantiation . . . . . . . . . . . . . . . . . . 10 | |||
| 6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 10 | 6.2. Enhanced Security Design . . . . . . . . . . . . . . . . 10 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 11 | 9.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 1. Introduction | 1. Introduction | |||
| skipping to change at page 3, line 12 ¶ | skipping to change at page 3, line 21 ¶ | |||
| [RFC8754]. By using the SRH, an ingress router can steer SRv6 | [RFC8754]. By using the SRH, an ingress router can steer SRv6 | |||
| packets into an explicit forwarding path so that many use cases like | packets into an explicit forwarding path so that many use cases like | |||
| Traffic Engineering, Service Function Chaining can be deployed easily | Traffic Engineering, Service Function Chaining can be deployed easily | |||
| by SRv6. | by SRv6. | |||
| However, SRv6 also brings some new security concerns. This document | However, SRv6 also brings some new security concerns. This document | |||
| describes various threats to networks deploying SRv6. SRv6 inherits | describes various threats to networks deploying SRv6. SRv6 inherits | |||
| potential security vulnerabilities from source routing in general, | potential security vulnerabilities from source routing in general, | |||
| and also from IPv6. | and also from IPv6. | |||
| o SRv6 makes use of the SRH which is a new type of Routing Extension | * SRv6 makes use of the SRH which is a new type of Routing Extension | |||
| Header. Therefore, the security properties of the Routing | Header. Therefore, the security properties of the Routing | |||
| Extension Header are addressed by the SRH. See [RFC5095] and | Extension Header are addressed by the SRH. See [RFC5095] and | |||
| [RFC8754] for details. | [RFC8754] for details. | |||
| o SRv6 consists of using the SRH on the IPv6 dataplane which | * SRv6 consists of using the SRH on the IPv6 dataplane which | |||
| security properties can be understood based on previous work | security properties can be understood based on previous work | |||
| [RFC4301], [RFC4302], [RFC4303] and [RFC4942]. | [RFC4301], [RFC4302], [RFC4303] and [RFC4942]. | |||
| In this document, we will consider the dangers from the following | In this document, we will consider the dangers from the following | |||
| kinds of threats: | kinds of threats: | |||
| o Wiretapping/eavesdropping | * Wiretapping/eavesdropping | |||
| o Packet Falsification | * Packet Falsification | |||
| o Identity Spoofing | * Identity Spoofing | |||
| o Packet Replay | * Packet Replay | |||
| o DOS/DDOS | * DOS/DDOS | |||
| o Malicious Packet Data | * Malicious Packet Data | |||
| The rest of this document describes the above security threats in | The rest of this document describes the above security threats in | |||
| SRv6 networks and existing approaches to mitigate and avoid the | SRv6 networks and existing approaches to mitigate and avoid the | |||
| threats. | threats. | |||
| 2. Terminology | 2. Terminology | |||
| This document uses the terminology defined in [RFC5095] and | This document uses the terminology defined in [RFC5095] and | |||
| [RFC8754]. | [RFC8754]. | |||
| skipping to change at page 4, line 41 ¶ | skipping to change at page 4, line 49 ¶ | |||
| This section outlines in details the different types of | This section outlines in details the different types of | |||
| vulnerabilities listed in Section 1. Then, for each type, an attempt | vulnerabilities listed in Section 1. Then, for each type, an attempt | |||
| to determine whether or not the vulnerability exists in a trusted | to determine whether or not the vulnerability exists in a trusted | |||
| domain is made. | domain is made. | |||
| 4.1. Eavesdropping Vulnerabilities in SRv6 Networks | 4.1. Eavesdropping Vulnerabilities in SRv6 Networks | |||
| As with practically all kinds of networks, traffic in an SRv6 network | As with practically all kinds of networks, traffic in an SRv6 network | |||
| may be vulnerable to eavesdropping. | may be vulnerable to eavesdropping. | |||
| o Threats: Eavesdropping | * Threats: Eavesdropping | |||
| * Solutions: Encapsulating Security Payload (ESP, [RFC4303]) can be | ||||
| o Solutions: Encapsulating Security Payload (ESP, [RFC4303]) can be | ||||
| used in order to prevent Eavesdropping. The ESP header is either | used in order to prevent Eavesdropping. The ESP header is either | |||
| inserted between the IP header and the next layer(transport) | inserted between the IP header and the next layer(transport) | |||
| protocol header, or before an encapsulated IP header (tunnel | protocol header, or before an encapsulated IP header (tunnel | |||
| mode). ESP can be used in order to provide confidentiality, data | mode). ESP can be used in order to provide confidentiality, data | |||
| origin authentication, connectionless integrity, an anti-replay | origin authentication, connectionless integrity, an anti-replay | |||
| service (a form of partial sequence integrity), and (limited) | service (a form of partial sequence integrity), and (limited) | |||
| traffic flow confidentiality. The set of services provided | traffic flow confidentiality. The set of services provided | |||
| depends on the selected options at the time of the Security | depends on the selected options at the time of the Security | |||
| Association (SA) establishment and on the location of the | Association (SA) establishment and on the location of the | |||
| implementation in a network topology.(add reference to the | implementation in a network topology.(add reference to the | |||
| different points explained in this paragraph). | different points explained in this paragraph). | |||
| o Conclusion: In tunnel mode of ESP, packets are encrypted and can | * Conclusion: In tunnel mode of ESP, packets are encrypted and can | |||
| not be eavesdropped in a trusted SRv6 domain. In transport mode | not be eavesdropped in a trusted SRv6 domain. In transport mode | |||
| of ESP, the payload of packets are encrypted and cannot be | of ESP, the payload of packets are encrypted and cannot be | |||
| eavesdropped in a trusted SRv6 domain, even if the IPv6 and SRH | eavesdropped in a trusted SRv6 domain, even if the IPv6 and SRH | |||
| headers are not encrypted. | headers are not encrypted. | |||
| o Gaps: The IPv6 and SRH headers are not encrypted in transport mode | * Gaps: The IPv6 and SRH headers are not encrypted in transport mode | |||
| of ESP which may be eavesdropped by attackers. | of ESP which may be eavesdropped by attackers. | |||
| +------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| |IPv6 Header| SRH | ESP| Payload |ESP Tail| ESP Auth data| | |IPv6 Header| SRH | ESP| Payload |ESP Tail| ESP Auth data| | |||
| +------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| |----- Encryption Scope -----| | |----- Encryption Scope -----| | |||
| |------ Authentication Scope -----| | |------ Authentication Scope -----| | |||
| Figure 1: Transport Mode ESP for SRv6 packets | Figure 1: Transport Mode ESP for SRv6 packets | |||
| +----------------------------------------------------------------------+ | +----------------------------------------------------------------------+ | |||
| |New IPv6 Header|SRH|ESP|IPv6 Header|SRH|Payload|ESP Tail|ESP Auth data| | |New IPv6 Header|SRH|ESP|IPv6 Header|SRH|Payload|ESP Tail|ESP Auth data| | |||
| +----------------------------------------------------------------------+ | +----------------------------------------------------------------------+ | |||
| |------ Encryption Scope --------| | |------ Encryption Scope --------| | |||
| |------- Authentication Scope -------| | |------- Authentication Scope -------| | |||
| Figure 2: Tunnel Mode ESP for SRv6 packets | Figure 2: Tunnel Mode ESP for SRv6 packets | |||
| 4.2. Packet Falsification in SRv6 Networks | 4.2. Packet Falsification in SRv6 Networks | |||
| As SRv6 domain is a trusted domain, there is no Packet Falsification | As SRv6 domain is a trusted domain, there is no Packet Falsification | |||
| within the SRv6 domain. | within the SRv6 domain. | |||
| As the packets from outside of SRv6 domain cannot be trusted, an | As the packets from outside of SRv6 domain cannot be trusted, an | |||
| Integrity Verification policy is typically deployed at the external | Integrity Verification policy is typically deployed at the external | |||
| interfaces of the ingress SRv6 routers in order to verify the | interfaces of the ingress SRv6 routers in order to verify the | |||
| incoming packets (i.e., from outside of SRv6 domain [RFC8986]). | incoming packets (i.e., from outside of SRv6 domain [RFC8986]). | |||
| Also, the packets with SRH sent form hosts within the SRv6 domain | Also, the packets with SRH sent form hosts within the SRv6 domain | |||
| should be verified in order to prevent the falsification between the | should be verified in order to prevent the falsification between the | |||
| host and the ingress router. [RFC8986]. | host and the ingress router. [RFC8986]. | |||
| o Threats: Packet Falsification | * Threats: Packet Falsification | |||
| o Solutions: The packets from outside can not be trusted, so | * Solutions: The packets from outside can not be trusted, so | |||
| Integrity Verification policy should be deployed at the external | Integrity Verification policy should be deployed at the external | |||
| interfaces by using , e.g., IPSec [RFC4301] (AH [RFC4302], ESP | interfaces by using , e.g., IPSec [RFC4301] (AH [RFC4302], ESP | |||
| [RFC4303] ) or HMAC [RFC2104]. AH [RFC4302], ESP [RFC4303] and | [RFC4303] ) or HMAC [RFC2104]. AH [RFC4302], ESP [RFC4303] and | |||
| HMAC [RFC2104] can provide Integrity Verification for packets, | HMAC [RFC2104] can provide Integrity Verification for packets, | |||
| while the ESP can encrypt the payload in order to provide higher | while the ESP can encrypt the payload in order to provide higher | |||
| security. However, it has been noted that the AH and ESP are not | security. However, it has been noted that the AH and ESP are not | |||
| directly applicable in order to reduce the vulnerabilities of SRv6 | directly applicable in order to reduce the vulnerabilities of SRv6 | |||
| due to the presence of mutable fields in the SRH. In order to | due to the presence of mutable fields in the SRH. In order to | |||
| solve this problem, [RFC8754] defines a mechanism in order to | solve this problem, [RFC8754] defines a mechanism in order to | |||
| carry HMAC TLV in the SRH so to verify the integrity of packets | carry HMAC TLV in the SRH so to verify the integrity of packets | |||
| including the SRH fields. The HMAC TLV is usually processed based | including the SRH fields. The HMAC TLV is usually processed based | |||
| on the local policy, only at the ingress router. Within the SRv6 | on the local policy, only at the ingress router. Within the SRv6 | |||
| domain, the packets are trusted, so HMAC TLV is typically ignored. | domain, the packets are trusted, so HMAC TLV is typically ignored. | |||
| In other words, the segment list is mutable within the SRv6 domain | In other words, the segment list is mutable within the SRv6 domain | |||
| but cannot be changed before processing the HMAC TLV. | but cannot be changed before processing the HMAC TLV. | |||
| o Conclusions: There is no Packet Falsification within a trusted | * Conclusions: There is no Packet Falsification within a trusted | |||
| SRv6 domain. Integrity Verification policy like HMAC processing | SRv6 domain. Integrity Verification policy like HMAC processing | |||
| should be deployed at the external interfaces of the ingress SRv6 | should be deployed at the external interfaces of the ingress SRv6 | |||
| routers filtering SRH packets from outside the trusted domain and | routers filtering SRH packets from outside the trusted domain and | |||
| SRH packets from hosts within the SRv6 domain. | SRH packets from hosts within the SRv6 domain. | |||
| o Gaps: IPsec cannot provide verification for SRH. | * Gaps: IPsec cannot provide verification for SRH. | |||
| +-----------------------------------------------------------------+ | +-----------------------------------------------------------------+ | |||
| |IPv6 Header | SRH | AH| Payload | | |IPv6 Header | SRH | AH| Payload | | |||
| +-----------------------------------------------------------------+ | +-----------------------------------------------------------------+ | |||
| |--Auth Scope--|HMAC |---------------Auth Scope-------------------| | |--Auth Scope--|HMAC |---------------Auth Scope-------------------| | |||
| Figure 3: Transport Mode AH and HMAC for SRv6 packets | Figure 3: Transport Mode AH and HMAC for SRv6 packets | |||
| +-----------------------------------------------------------------+ | +-----------------------------------------------------------------+ | |||
| |New IPv6 Header|SRH | AH |IPv6 Header|SRH|Payload | | |New IPv6 Header|SRH | AH |IPv6 Header|SRH|Payload | | |||
| +-----------------------------------------------------------------+ | +-----------------------------------------------------------------+ | |||
| |--Auth Scope---|HMAC|---------------Auth Scope-------------------| | |--Auth Scope---|HMAC|---------------Auth Scope-------------------| | |||
| Figure 4: Tunnel Mode AH and HMAC for SRv6 packets | ||||
| Figure 4: Tunnel Mode AH and HMAC for SRv6 packets | ||||
| 4.3. Identity Spoofing in SRv6 Networks | 4.3. Identity Spoofing in SRv6 Networks | |||
| The same as for Packet Falsification, there is no Identity Spoofing | The same as for Packet Falsification, there is no Identity Spoofing | |||
| possible within the boundaries of a SRv6 trusted domain where all | possible within the boundaries of a SRv6 trusted domain where all | |||
| nodes are under control of the same administrative organization. | nodes are under control of the same administrative organization. | |||
| Authentication policy should be deployed at the external interfaces | Authentication policy should be deployed at the external interfaces | |||
| of the ingress SRv6 routers in order to validate the packets from | of the ingress SRv6 routers in order to validate the packets from | |||
| outside of SRv6 domain [RFC8986]. Also, the packets with SRH sent | outside of SRv6 domain [RFC8986]. Also, the packets with SRH sent | |||
| form hosts inside the SRv6 domain should be validated in order to | form hosts inside the SRv6 domain should be validated in order to | |||
| prevent the Identity Spoofing [RFC8986]. | prevent the Identity Spoofing [RFC8986]. | |||
| o Threats: Identity Spoofing | * Threats: Identity Spoofing | |||
| o Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC | * Solutions: IPSec [RFC4301] (AH [RFC4302], ESP [RFC4303] ) or HMAC | |||
| [RFC2104] can be used for Authentication. AH, ESP and HMAC can | [RFC2104] can be used for Authentication. AH, ESP and HMAC can | |||
| provide Authentication of source node, while the ESP can encrypt | provide Authentication of source node, while the ESP can encrypt | |||
| the payload in order to provide higher security. Same as section | the payload in order to provide higher security. Same as section | |||
| 3.2. | 3.2. | |||
| o Conclusion: There is no Identity Spoofing within a trusted SRv6 | * Conclusion: There is no Identity Spoofing within a trusted SRv6 | |||
| domain. Identity Spoofing policy should be deployed on the | domain. Identity Spoofing policy should be deployed on the | |||
| external interfaces of the ingress SRv6 routers for the packets | external interfaces of the ingress SRv6 routers for the packets | |||
| from outside and the packets with SRH from hosts within the SRv6 | from outside and the packets with SRH from hosts within the SRv6 | |||
| domain. | domain. | |||
| o Gaps: TBA | * Gaps: TBA | |||
| 4.4. Packet Replay in SRv6 Networks | 4.4. Packet Replay in SRv6 Networks | |||
| There are no new Packet Replay threat brought by SRH. ESP can be | There are no new Packet Replay threat brought by SRH. ESP can be | |||
| applied to SRv6 in order to prevent Packet replay attacks. | applied to SRv6 in order to prevent Packet replay attacks. | |||
| o Threats: Packet Replay | * Threats: Packet Replay | |||
| o Solutions: ESP [RFC4303] can be used to prevent Replay Attacks. | * Solutions: ESP [RFC4303] can be used to prevent Replay Attacks. | |||
| o Conclusion: There are no new Packet Replay threat brought by SRH. | * Conclusion: There are no new Packet Replay threat brought by SRH. | |||
| ESP can be applied to SRv6 in order to prevent Packet replay | ESP can be applied to SRv6 in order to prevent Packet replay | |||
| attacks. | attacks. | |||
| o Gaps: TBD | * Gaps: TBD | |||
| 4.5. DOS/DDOS in SRv6 Networks | 4.5. DOS/DDOS in SRv6 Networks | |||
| The generation of ICMPv6 error messages may be used in order to | The generation of ICMPv6 error messages may be used in order to | |||
| attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) | attempt DOS(Denial-Of-Service)/DDOS(Distributed Denial-Of-Service) | |||
| attacks by sending an error-causing destination address or SRH in | attacks by sending an error-causing destination address or SRH in | |||
| back-to-back packets [RFC8754]. An implementation that correctly | back-to-back packets [RFC8754]. An implementation that correctly | |||
| follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 | follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 | |||
| rate-limiting mechanism also in the case of packets with an SRH. | rate-limiting mechanism also in the case of packets with an SRH. | |||
| o Threats: DOS/DDOS | * Threats: DOS/DDOS | |||
| o Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] | * Solutions: ICMPv6 rate-limiting mechanism as defined in [RFC4443] | |||
| o Conclusions: There are no DOS/DDOS threats within SRv6 domain, the | ||||
| * Conclusions: There are no DOS/DDOS threats within SRv6 domain, the | ||||
| threats come from outside of the domain, and can be prevented by | threats come from outside of the domain, and can be prevented by | |||
| ICMPv6 rate-limiting mechanism. | ICMPv6 rate-limiting mechanism. | |||
| o Gaps: TBD | * Gaps: TBD | |||
| 4.6. Malicious Packet Data in SRv6 Networks | 4.6. Malicious Packet Data in SRv6 Networks | |||
| TBA | TBA | |||
| 5. Effects of the above on SRv6 Use Cases | 5. Effects of the above on SRv6 Use Cases | |||
| This section describes the effects of the above-mentioned | This section describes the effects of the above-mentioned | |||
| vulnerabilities in terms of applicability statement and the use cases | vulnerabilities in terms of applicability statement and the use cases | |||
| given in citation. | given in citation. | |||
| skipping to change at page 8, line 39 ¶ | skipping to change at page 9, line 4 ¶ | |||
| easier understanding, a easy example is shown in Figure 5. | easier understanding, a easy example is shown in Figure 5. | |||
| *************************** ***** | *************************** ***** | |||
| * (3) h2 * * * SRv6 domain | * (3) h2 * * * SRv6 domain | |||
| * \ | * ***** | * \ | * ***** | |||
| h1-----A-----B-----C-----D-------E-------F | h1-----A-----B-----C-----D-------E-------F | |||
| / * (2) (2) (2) * \ | / * (2) (2) (2) * \ | |||
| (1,2,3) * * (1,2) | (1,2,3) * * (1,2) | |||
| * * | * * | |||
| *************************** | *************************** | |||
| Figure 5: SRv6 Security Policy Design | Figure 5: SRv6 Security Policy Design | |||
| o A-E: SRv6 Routers inside the SRv6 domain, A and E are the edge | * A-E: SRv6 Routers inside the SRv6 domain, A and E are the edge | |||
| router, can be called Ingress router instead. | router, can be called Ingress router instead. | |||
| o F: Router F outside the SRv6 domain. | * F: Router F outside the SRv6 domain. | |||
| o h1: A host outside the SRv6 domain connects to router Router A. | * h1: A host outside the SRv6 domain connects to router Router A. | |||
| o h2: A host within SRv6 domain, which connects to the Router D. | * h2: A host within SRv6 domain, which connects to the Router D. | |||
| o (1): Security policy 1: ACL for External Interface. | * (1): Security policy 1: ACL for External Interface. | |||
| o (2): Security policy 2: ACL for Internal Interfaces. | * (2): Security policy 2: ACL for Internal Interfaces. | |||
| o (3): Security policy 3: Policy for processing HMAC, should be | * (3): Security policy 3: Policy for processing HMAC, should be | |||
| deployed at the ingress nodes. | deployed at the ingress nodes. | |||
| 6.1. Basic Security Design | 6.1. Basic Security Design | |||
| 6.1.1. ACL for External Interfaces | 6.1.1. ACL for External Interfaces | |||
| Typically, in any trusted domain, ingress routers are configured with | Typically, in any trusted domain, ingress routers are configured with | |||
| Access Control Lists (ACL) filtering out any packet externally | Access Control Lists (ACL) filtering out any packet externally | |||
| received with SA/DA having a domain internal address. An SRv6 router | received with SA/DA having a domain internal address. An SRv6 router | |||
| typically comply with the same rule. | typically comply with the same rule. | |||
| skipping to change at page 11, line 19 ¶ | skipping to change at page 11, line 28 ¶ | |||
| [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., | [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., | |||
| Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | |||
| (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | |||
| <https://www.rfc-editor.org/info/rfc8754>. | <https://www.rfc-editor.org/info/rfc8754>. | |||
| 9.2. Informative References | 9.2. Informative References | |||
| [I-D.ietf-spring-segment-routing-policy] | [I-D.ietf-spring-segment-routing-policy] | |||
| Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and | Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and | |||
| P. Mattes, "Segment Routing Policy Architecture", draft- | P. Mattes, "Segment Routing Policy Architecture", Work in | |||
| ietf-spring-segment-routing-policy-13 (work in progress), | Progress, Internet-Draft, draft-ietf-spring-segment- | |||
| May 2021. | routing-policy-22, 22 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-spring- | ||||
| segment-routing-policy-22.txt>. | ||||
| [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
| Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
| DOI 10.17487/RFC2104, February 1997, | DOI 10.17487/RFC2104, February 1997, | |||
| <https://www.rfc-editor.org/info/rfc2104>. | <https://www.rfc-editor.org/info/rfc2104>. | |||
| [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
| Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | |||
| December 2005, <https://www.rfc-editor.org/info/rfc4301>. | December 2005, <https://www.rfc-editor.org/info/rfc4301>. | |||
| skipping to change at page 12, line 22 ¶ | skipping to change at page 12, line 33 ¶ | |||
| D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | |||
| (SRv6) Network Programming", RFC 8986, | (SRv6) Network Programming", RFC 8986, | |||
| DOI 10.17487/RFC8986, February 2021, | DOI 10.17487/RFC8986, February 2021, | |||
| <https://www.rfc-editor.org/info/rfc8986>. | <https://www.rfc-editor.org/info/rfc8986>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Cheng Li | Cheng Li | |||
| Huawei | Huawei | |||
| China | China | |||
| Email: c.l@huawei.com | Email: c.l@huawei.com | |||
| Zhenbin Li | Zhenbin Li | |||
| Huawei | Huawei | |||
| China | China | |||
| Email: lizhenbin@huawei.com | Email: lizhenbin@huawei.com | |||
| Chongfeng Xie | Chongfeng Xie | |||
| China Telecom | China Telecom | |||
| China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District | China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District | |||
| Beijing | Beijing | |||
| China | China | |||
| Email: xiechf@chinatelecom.cn | ||||
| Email: xiechf@chinatelecom.cn | ||||
| Hui Tian | Hui Tian | |||
| CAICT | CAICT | |||
| Beijing | Beijing | |||
| China | China | |||
| Email: tianhui@caict.ac.cn | Email: tianhui@caict.ac.cn | |||
| Jianwei Mao | Jianwei Mao | |||
| Huawei | Huawei | |||
| China | China | |||
| Email: MaoJianwei@huawei.com | Email: MaoJianwei@huawei.com | |||
| End of changes. 54 change blocks. | ||||
| 73 lines changed or deleted | 66 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/ | ||||