SAVNET Use Cases
draft-ys-savnet-use-cases-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shengnan Yue , Xueyan Song , Changwang Lin , Nan Geng | ||
| Last updated | 2024-03-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ys-savnet-use-cases-00
SAVNET Group S. Yue
Internet-Draft China Mobile
Intended status: Informational X. Song
Expires: 3 September 2024 ZTE Corporation
C. Lin
New H3C Technologies
N. Geng
Huawei Technologies
4 March 2024
SAVNET Use Cases
draft-ys-savnet-use-cases-00
Abstract
This document introduces the use case for Source Address Validation
(SAV) applied in intra-domain and inter-domain telecommunication
networks. It describes the typical routing implements and possible
improvements for SAV in the use cases.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 3 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Yue, et al. Expires 3 September 2024 [Page 1]
Internet-Draft SAVNET Use Cases March 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
3. Mobile Transport Network . . . . . . . . . . . . . . . . . . 3
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 3
3.3. Possible improvements for SAV . . . . . . . . . . . . . . 4
4. Fixed Transport Network . . . . . . . . . . . . . . . . . . . 4
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 4
4.3. Possible improvements for SAV . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Source Address Validation in Intra-domain and Inter-domain
Networks (SAVNET) use cases provides the typical applications at
telecommunication field. Considering the network topology and
technology used in these applications have big difference, the
possible improvement schema for Source Address Validation (SAV) may
have different considerations.
This document specifically identifies the SAV use case for
telecommunication networks and provides possible SAV validation
location but does not suggests any specific design for SAV
architecture and protocol. The SAVNET architecture introduced at
[I-D.wu-savnet-inter-domain-architecture] and
[I-D.li-savnet-intra-domain-architecture].
This document serves the purpose of helping those learning SAVNET
applications and understand the possible influence brought by SAVNET
to telecommunication scenarios and provides necessary considerations
for SAV solution design.
2. Conventions and Definitions
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.
Yue, et al. Expires 3 September 2024 [Page 2]
Internet-Draft SAVNET Use Cases March 2024
3. Mobile Transport Network
3.1. Description
A telecom network refers to the network composed of user terminal
equipment, transmission equipment, switches and telecom operators
room. The communication devices and equipment interconnect to
provide high flexible and dedicated services to users. The telecom
network in this document is mainly related to 5G transport network,
6G transport network, etc.
3.2. Implementation
The following figure shows a typical 5G Transport network
architecture.
____ ____ ____
/ \ / \ / \
+-------+ _/ \ _/ \ _/ \ +---------+
| User | / Access \ / Aggrega \ / Core \ |5G Mobile|
|System +---+ Network +----+ Network +---+ Network +---+ System |
+-------+ \_ _/ \_ _/ \_ _/ +---------+
\_____/ \_____/ \_____/
| |
Option1 | IPoETH | MPLS/VPN/SR |
|--------------------------------------------|
Option2 | IPoETH | MPLS/VPN/SR |
|--------------------------------------------|
Option3 | IPoL2VPN | MPLS/VPN/SR |
|--------------------------------------------|
Option4 | IPoL2VPN | MPLS/VPN/SR |
|--------------------------------------------|
| |
Figure 1: An example for mobile transport network Scenario
From the implementation in NG (R)AN network there are optional
connection links between CSG and Edge Node (between Access Network
and Aggregation Network) which use IP or Ethernet technology. The
more common deployment is to use MPLS/VPN as overlay technology to
carry data packets. The LTE or 5G traffic will be transported
through either a L3VPN or an L2VPN or EVPN over MPLS or IP with or
without segment routing.
Yue, et al. Expires 3 September 2024 [Page 3]
Internet-Draft SAVNET Use Cases March 2024
Please noted the scope of SAVNET is the validation of IPv4 and IPV6
addresses. The validation of label packets with MPLS/VPN deployments
in Mobile Transport Network is out of the scope of the SAVNET.
3.3. Possible improvements for SAV
As described and analyzed at the previous section, there is no need
for SAVNET in MPLS/VPN network. The only location for SAVNET is in
Access Network but SAVI function MAY be required and enough for
source address validation.
However, in the case of an AS cross-domain network for the
communication between different Service Providers, the raw IPv4/IPv6
traffic is transported through EBGP technology so in order to reduce
source address spoofing attack EBGP protocol SHOULD support SAVNET
feature to validate the traffic accessed from other external AS
domains.
4. Fixed Transport Network
4.1. Description
A Fixed Transport Network refers to the network consists of optical
transport, which physically connects all the fixed network nodes, may
involve residential gateway, optical equipment, switch/router and
broadband network gateway. The typical fixed transport network may
across the wireline and wireless access, metro and backbone IP
networks.
4.2. Implementation
The following figure shows a typical Fixed Transport Network
architecture.
Yue, et al. Expires 3 September 2024 [Page 4]
Internet-Draft SAVNET Use Cases March 2024
________ ___/ \
_____ / \ / Data \_
/ \__/ \ +_Center/
+------| /+----+ +----+ \_____ / |____/
| User | / | | | | \_______ /
|System+--+--+BNG +----+ P +----+ \ / _
| | | | | | | | +-----+ ___/ \
+------+ | +--+-+ +----+ | +--+-+ | / \_
\ | | | | | / Backbone \
\ | +----+ +-+--+ +--+Edge|-------+ Network _/
\ | | | | | | | | | \_ _/
\ +---+ P +----+ P +--+ +----+ | \____/
\___ | | | | /
\ +----+__ +----+ _____/
\_____/ \___________/
| |Backbone|
| Metro Area Network |Network |
|-------------------------------------|--------|
| IGP | BGP |
| | |
Figure 2: An example for fixed transport network Scenario
From the network levels perspective, it divides into residential
Access Network (AN), Metro Area Network (MAN) and Backbone Network
(BN).
From the implementation in AN network there are optical connection
links between fixed user and broadband network gateway (BNG) nodes
which use IP or Ethernet technology. The BNG attached AAA server
allocates ipv4/ipv6 address to fixed users the access traffic from
user to fixed network will be validated at BNG.
The MAN network usually implements IGP (i.e., ISIS, OSPF) routes to
achieve the path connection between network nodes. Meanwhile the
service traffic uses MPLS/VPN with/without segment routing technology
as traffic overlay.
The BN network usually implements BGP (i.e., eBGP) to achieve inter-
domain network path connection.
Yue, et al. Expires 3 September 2024 [Page 5]
Internet-Draft SAVNET Use Cases March 2024
4.3. Possible improvements for SAV
It's assumed that the most feasible way for packets validation is at
the location closest to the traffic for filtering invalid address or
mitigating source address spoofing. As described at the previous
section, the traffic directed from user to network server the BNG is
considered as a suitable validation entity. And for the reverse
traffic directed from DC/contents server to user the most feasible
way to validate external spoofing traffic is at the location of edge
routers of BN network. If there is no SAV function implemented at
edge routers of BN network, it's expected to implement SAV function
at MAN network nodes.
With the selection of the SAV validation entity and the use of SAV
function to the network nodes at Fixed Transport Network, the
incoming traffic from user and the external traffic from DC/content
server can be validated effectively. It may use IGP or BGP protocol
extension to support necessary SAV information transport.
For the SAV function used at BNG, there is an optional way to achieve
source validation function:
For the upstream traffic (from user to server)
1. After receiving a packet from a broadband user, the BNG applies
the SAV function to determine whether the source address of the
packet belongs to the legitimate user and the inbound port.
2. If yes, packets are forwarded according to the specified rules.
3. If no, packets are discarded or redirected according to the
specified rules.
For the downstream traffic (from server to user)
1. BNG advertises the source route prefix of broadband users to the
upstream routers and receives the reachable route from the
upstream router. The network topology is reachable.
2. After receiving the traffic from the server, the BNG applies the
SAV function to check whether the source address of the packet is
valid and whether it matches the expected inbound port.
3. If yes, packets are forwarded according to the specified rules.
4. If no, packets are discarded or redirected according to the
specified rules.
The SAV policy may be different to upstream and downstream traffic.
For example, the upstream traffic is mainly from valid users the SAV
function is suggested to use allowlistt filtering policy like ACL;
while the downstream traffic from internet or DC servers the SAV
policy may apply allowlistt and blocklist filtering policy.
Yue, et al. Expires 3 September 2024 [Page 6]
Internet-Draft SAVNET Use Cases March 2024
The detailed SAV policy and function is out of the scope of this
document. There is an optical way described at
[I-D.cheng-savnet-intra-domain-sav-igp].
5. Security Considerations
TBD.
6. IANA Considerations
This document has no requests for IANA.
7. Acknowledgements
TBD.
8. Informative References
[I-D.cheng-savnet-intra-domain-sav-igp]
Cheng, W., Li, D., Lin, C., and Yue, "Intra-domain SAV
Support via IGP", Work in Progress, Internet-Draft, draft-
cheng-savnet-intra-domain-sav-igp-01, 25 February 2024,
<https://datatracker.ietf.org/doc/html/draft-cheng-savnet-
intra-domain-sav-igp-01>.
[I-D.li-savnet-intra-domain-architecture]
Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M.,
and F. Gao, "Intra-domain Source Address Validation
(SAVNET) Architecture", Work in Progress, Internet-Draft,
draft-li-savnet-intra-domain-architecture-06, 21 January
2024, <https://datatracker.ietf.org/doc/html/draft-li-
savnet-intra-domain-architecture-06>.
[I-D.wu-savnet-inter-domain-architecture]
Wu, J., Li, D., Huang, M., Chen, L., Geng, N., Liu, L.,
and L. Qin, "Inter-domain Source Address Validation
(SAVNET) Architecture", Work in Progress, Internet-Draft,
draft-wu-savnet-inter-domain-architecture-06, 5 February
2024, <https://datatracker.ietf.org/doc/html/draft-wu-
savnet-inter-domain-architecture-06>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Yue, et al. Expires 3 September 2024 [Page 7]
Internet-Draft SAVNET Use Cases March 2024
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Shengnan Yue
China Mobile
China
Email: yueshengnan@chinamobile.com
Xueyan Song
ZTE Corporation
China
Email: song.xueyan2@zte.com.cn
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Nan Geng
Huawei Technologies
China
Email: gengnan@huawei.com
Yue, et al. Expires 3 September 2024 [Page 8]