< 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/