Internet DRAFT - draft-yang-spring-srv6-vpn-across-state-firewall
draft-yang-spring-srv6-vpn-across-state-firewall
Network Working Group F. Yang
Internet Draft China Mobile
Intended status: Informational C. Lin
Expires: September 7, 2023 M. Chen
New H3C Technologies
March 7, 2023
Considerations for SRv6-based VPN across SR-aware Stateful Firewall
draft-yang-spring-srv6-vpn-across-state-firewall-00
Abstract
This document describes a problem caused by asymmetrical
source/destination address tuple when the VPN traffics pass through
an SR-aware stateful firewall in the SRv6 network. A solution for
that problem is also proposed.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 7, 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yang, et al. Expire September 7, 2023 [Page 1]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................2
1.1. Requirements Language.....................................3
2. Problem........................................................3
3. Solution.......................................................5
4. Security Considerations........................................6
5. IANA Considerations............................................6
6. References.....................................................6
6.1. Normative References......................................6
6.2. Informative References....................................7
Authors' Addresses................................................8
1. Introduction
Segment Routing (SR) [RFC8402] leverages the source routing
paradigm. A node steers a packet through an SR Policy instantiated
as an ordered list of instructions called "segments". Segment
Routing (SR) can be applied to the IPv6 data plane using Segment
Routing Header (SRH) [RFC8754], which is called SRv6.
To provide VPN service in an SRv6 network [RFC9252], the ingress PE
encapsulates the payload in an outer IPv6 header with the Segment
Routing Header (SRH) [RFC8754] carrying the SR Policy segment list
along with the VPN Service SID. If the VPN service is with best-
effort connectivity, the destination address of the outer IPv6
header carries the VPN service SID and the SRH is omitted.
Along the forwarding path in the SRv6 network, firewalls may be
deployed to filter the traffics. If a firewall is SR-aware, it will
retrieve the final destination of an SRv6 packet from the last entry
in the SRH rather than the destination address field of the IPv6
header [I-D.ietf-spring-sr-service-programming].
A stateful firewall keeps a track of the state of the network
connections traveling across it. Whenever a packet arrives to seek
permission to pass through it, the firewall checks from its state
Yang, et al. Expires September 7, 2023 [Page 2]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
table if there is an active connection identified by 3 tuple or 5
tuple. Thus only legitimate packets are allowed to be transmitted
across it.
This document describes a problem caused by asymmetrical
source/destination address tuple when the VPN traffics pass through
an SR-aware stateful firewall in the SRv6 network. A solution for
that problem is also proposed.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Problem
Figure 1 and Figure 2 show the bidirectional VPN traffic packets
passing through a firewall in an SRv6 network.
The source address of the outer IPv6 header is the IPv6 address of
ingress PE. The final destination address of the outer IPv6 header
is the VPN Service SID of egress PE. In the SR-Policy-based way, the
final destination address is encapsulated in the last entry in the
SRH, Segment[0]. In the best-effort way, the SRH is omitted.
Yang, et al. Expires September 7, 2023 [Page 3]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
+---+ +---+ +--------+ +---+ +---+
|CE1|---|PE1|--...--|Firewall|--...--|PE2|---|CE2|
+---+ +---+ +--------+ +---+ +---+
Packet (PE1 ---> PE2): Packet (PE1 <--- PE2):
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-IP-ADDR * * SA=PE2-IP-ADDR *
* DA=NextSegment * * DA=NextSegment *
********************** **********************
* SRH * * SRH *
* Seg[0]=PE2-VPN-SID * * Seg[0]=PE1-VPN-SID *
* Seg[...] * * Seg[...] *
********************** **********************
* Eth/IPv4/IPv6 * * Eth/IPv4/IPv6 *
* Source=CE1 * * Source=CE2 *
* Destination=CE2 * * Destination=CE1 *
********************** **********************
* Payload * * Payload *
********************** **********************
Figure 1: SR-Policy-based VPN Traffic across Firewall
+---+ +---+ +--------+ +---+ +---+
|CE1|---|PE1|--...--|Firewall|--...--|PE2|---|CE2|
+---+ +---+ +--------+ +---+ +---+
Packet (PE1 ---> PE2): Packet (PE1 <--- PE2):
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-IP-ADDR * * SA=PE2-IP-ADDR *
* DA=PE2-VPN-SID * * DA=PE1-VPN-SID *
********************** **********************
* Eth/IPv4/IPv6 * * Eth/IPv4/IPv6 *
* Source=CE1 * * Source=CE2 *
* Destination=CE2 * * Destination=CE1 *
********************** **********************
* Payload * * Payload *
********************** **********************
Figure 2: Best-Effort VPN Traffic across Firewall
The stateful firewall will check the association relationships of
the bidirectional VPN traffic packets. A common implementation may
record the key information of the packets on forward way (internal
to external), such as source address and destination address. When
receiving a packet on backward way (external to internal), it checks
the state table if there is an existing forward packet flow. For
Yang, et al. Expires September 7, 2023 [Page 4]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
example, the firewall may require that the source address of packet
on backward way matches the destination address of packet on forward
way, and destination address will be checked in the similar way. If
not matched, the packet on the backward path will be regarded as
illegal and thus dropped.
An SR-aware firewall is able to retrieve the final destination of an
SRv6 packet from the last entry in the SRH. The <source,
destination> tuple of the packet from PE1 to PE2 is <PE1-IP-ADDR,
PE2-VPN-SID>, and the other direction is <PE2-IP-ADDR, PE1-VPN-SID>.
However, the source address of the outer IPv6 packet is usually a
loopback interface of the ingress PE. Eventually, the source address
and destination address of the forward and backward VPN traffic are
regarded as different flows, and they may be blocked by the
firewall.
3. Solution
In the SRv6-based VPN service, the final destination of the outer
IPv6 header is the VPN Service SID of the egress PE, which is
associated with that VPN service. But the source address of the
outer IPv6 header is usually unrelated to the VPN service. So, it
can be difficult for a stateful firewall to establish the
association relationship between the bidirectional traffic flows.
The proposed solution is to use the ingress PE's own VPN Service SID
as the source address of outer IPv6 header, and thus ensure the
symmetry of the bidirectional flows.
When an ingress PE receives the client packet from CE, it checks
which VRF/VSI/XC it belongs to, and uses the VPN Service SID
associated with that VRF/VSI/XC as the source address when
encapsulating the outer IPv6 header with the optional SRH.
Yang, et al. Expires September 7, 2023 [Page 5]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
Outer IPv6 Header of SR-Policy-based VPN Traffic:
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-VPN-SID * * SA=PE2-VPN-SID *
* DA=NextSegment * * DA=NextSegment *
********************** **********************
* SRH * * SRH *
* Seg[0]=PE2-VPN-SID * * Seg[0]=PE1-VPN-SID *
* Seg[...] * * Seg[...] *
********************** **********************
Outer IPv6 Header of Best-effort VPN Traffic:
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-VPN-SID * * SA=PE2-VPN-SID *
* DA=PE2-VPN-SID * * DA=PE1-VPN-SID *
********************** **********************
Figure 3: Outer IPv6 Header in the Proposed Solution
According to [RFC8402] and [RFC8986], an SRv6 VPN Service SID is an
IPv6 address, and it is routable by its Locator prefix in the SRv6
network. In the proposed solution, when an SRv6 VPN Service SID is
used as the source address of the outer IPv6 header in the SRv6
network, it is treated as a normal IPv6 address and does not perform
any special behavior.
4. Security Considerations
TBD.
5. IANA Considerations
This document has no IANA actions.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017
Yang, et al. Expires September 7, 2023 [Page 6]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI
10.17487/RFC9252, July 2022, <https://www.rfc-
editor.org/info/rfc9252>.
6.2. Informative References
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, DOI
10.17487/RFC8986, February 2021, <https://www.rfc-
editor.org/info/rfc8986>.
[I-D.ietf-spring-sr-service-programming] Clad, F., Xu, X., Filsfils,
C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli,
C., Henderickx, W., and S. Salsano, "Service Programming
with Segment Routing", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-service-programming-07, 15 February
2023, <https://www.ietf.org/archive/id/draft-ietf-spring-
sr-service-programming-07.txt>.
Yang, et al. Expires September 7, 2023 [Page 7]
Internet-Draft SRv6 VPN across Stateful Firewall March 2023
Authors' Addresses
Feng Yang
China Mobile
China
Email: yangfeng@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Mengxiao Chen
New H3C Technologies
China
Email: chen.mengxiao@h3c.com
Yang, et al. Expires September 7, 2023 [Page 8]
