Internet DRAFT - draft-lin-savnet-lsr-intra-domain-method
draft-lin-savnet-lsr-intra-domain-method
SAVNET Working Group D. Li
Internet Draft Tsinghua University
Intended status: Standards Track L. Liu
Expires: July 5, 2024 Zhongguancun Laboratory
C. Lin
New H3C Technologies
X. Song
ZTE Corporation
Y. Qiu
New H3C Technologies
January 5, 2024
Intra-domain SAVNET method
draft-lin-savnet-lsr-intra-domain-method-03
Abstract
This document proposes a method of Source Address Validation in
Intra-domain, which can be applied to OSPF and IS-IS protocols. By
extending IGP and adding the protocol calculation procedure, the SAV
rule can be accurately calculated to realize the source address
verification.
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 July 5 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expire July, 2024 [Page 1]
Internet-Draft intra-domain SAVNET January 2024
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. Calculating SAV Rules based on IGP Extension ................. 3
3. Advertising the Protected Prefixes ........................... 4
4. Calculate SAV Rules based on IGP ............................. 4
5. Scenario of Multi-area ....................................... 7
6. Protocol Extension ........................................... 9
6.1. Extension of OSPFv2 ..................................... 9
6.1.1. Extension for Protected Prefixes ................... 9
6.1.2. Extension for Reverse Prefix Cost ................. 10
6.2. Extension of OSPFv3 .................................... 10
6.2.1. Extension for Protected Prefixes .................. 10
6.2.2. Extension for Reverse Prefix Cost ................. 11
6.3. Extension of IS-IS ..................................... 12
6.3.1. Extension for Protected Prefixes .................. 12
6.3.2. Extension for Reverse Prefix Cost ................. 12
7. Consideration of Redirection Routing Policy ................. 13
8. IANA Considerations ......................................... 16
9. Security Considerations ..................................... 16
10. References ................................................. 16
10.1. Normative References .................................. 16
Contributors ................................................... 17
Authors' Addresses ............................................. 18
1. Introduction
There are long-term attacks based on source address spoofing in the
Internet. By spoofing the source address, attackers can disguise
themselves and carry out hacking activities including DOS and DDoS
attacks, which have brought serious security threats to the entire
Internet. [I-D.ietf-savnet-intra-domain-problem-statement] provides
the gap analysis of existing intra-domain SAV mechanisms, describes
Li, et al. Expires July, 2024 [Page 2]
Internet-Draft intra-domain SAVNET January 2024
the fundamental problems, and defines the requirements for
improvements.
This document proposes a method based on the existing IGP routing
protocol for the requirement of SAV in the domain. By extending the
message of the routing protocol, adding the relevant protocol
calculation procedure, each node has the ability to independently
calculate the valid incoming interface of a specific prefix in
domain, so as to verify the source address of the traffic.
In addition, for the redirected forwarding policy independent of
routing protocol, the impact on SAV rule calculation is discussed.
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. Calculating SAV Rules based on IGP Extension
By extending the IGP routing protocol, each routing node calculates
independently SAV rule, that is, the binding entry including
prefixes and valid incoming interfaces.
If the source address of the received packet hits the prefix of a
binding entry, and the interface belongs to the valid incoming
interfaces bound with the prefix, the source address of the packet
is considered legal, otherwise it is illegal.
The existing uRPF uses the source address of the packet to lookup
the local route table when receiving the packet, and determines
whether the packet is valid according to the lookup result. For
strict uRPF, it is required that the outgoing interface of the found
route is consistent with the incoming interface of the packet. For
loose uRPF, only a route to the source address is required.
However, the local route table is used to guide how to go from the
local to the node and subnet where the source address is located,
and it cannot really reflect how to reach this node from the node
and subnet where the source address is located. Therefore, the local
route table only has some reference value and cannot be fully
trusted to validate the source address. In order to obtain more
accurate SAV rules, the routing tables of other routers should be
used for calculation.
Li, et al. Expires July, 2024 [Page 3]
Internet-Draft intra-domain SAVNET January 2024
The IGP needs to be extended to advertise specific prefix
information. At the same time, each node that enables the intra-
domain SAV function needs to calculate the SAV rule according to the
extended routing message. In addition, this document also considers
the protocol extension required by the multi-area scenario.
3. Advertising the Protected Prefixes
When advertising prefix information through IGP, it is necessary to
identify the source prefix participating in SAV rule calculation.
These prefixes can be called protected prefixes.
For intra-domain scenarios, it is mainly the access side prefix of
each boundary node. Prefixes from outside the domain are considered
in the inter-domain solution. If the loopback address and network
side interface prefix of the node in the domain are considered to be
safe, it is not necessary to participate in the calculation of SAV
rule.
The prefix that needs to participate in SAV rule calculation can be
specified through configuration. When IGP advertises such a prefix,
it needs to attach corresponding information to inform other routing
nodes.
When the router that has enabled the intra-domain SAV function
receives the packet, only those packets whose source address comes
from the protected prefixes will be checked for the legitimacy of
the incoming interface of the packet. That is, if the legal
interfaces of SAV rule corresponding to the source prefix do not
contain the incoming interface of the packet, it may be necessary to
discard the packet or do other related processing to the packet.
In order to identify the protected prefixes, the IGP protocol needs
to be extended accordingly.
4. Calculate SAV Rules based on IGP
This section describes how to calculate SAV rule based on the route
information advertised by IGP. Referring to the following topology
as an example, each router from R1 to R7 has an access subnet prefix.
These prefixes are protected prefixes.
Li, et al. Expires July, 2024 [Page 4]
Internet-Draft intra-domain SAVNET January 2024
subnet(P2)
,-----.
( _)
`--+--' _ subnet(P3)
\ (->)cost 20 ,--------.
+----+ cost 100(<-) ( )
+---------+ R2 +-------------------+ `----+---'
| +-+--+ | /
| |cost 100(<->) | /
| | Intf1| /
| | (->)cost 100 +-+--+ /
| | +-----------------+ R3 +/
subnet(P1) | | |cost 20(<-) Intf2+-+--+
----. | | | | Intf3
( ) | | | |
---`: | | | subnet(P7) |
`.+-+--+ +-+--+ ,---. +-+--+
| R1 +------+ R7 +---( ) + R6 |`.subnet(P6)
+-+--+ +-+--+ `---' +-+--+ `-,---.
| | | | ( )
| | | | `---'
| | | +-+--+
| | +-----------------+ R5 |-
| | cost 100(<->) +-+--+ ,`-..
| +-+--+ | ( )
+---------+ R4 +-------------------+ `---'
-+----+ subnet(P5)
subnet(P4) /
,----+--.
( )
`-------'
Figure 1: example topology of intra-domain SAVNET
Taking R3 as an example, after collecting the prefix and topology
information in the domain through IGP, R3 first takes itself as the
root, calculates a shortest path tree to other routers in the
domain, and calculates the intra-domain route based on this shortest
path tree. This process is consistent with the existing IGP route
calculation process.
R3 continues to take other routers in the domain as the root to
calculate the shortest path tree. Finally, seven shortest path trees
from Tree-R1 to Tree-R7 are generated on R3. R3 calculates SAV rule
corresponding to the protected prefix based on these trees.
Take Prefix P1 as an example. Prefix P1 is advertised by R1.
Therefore, R3 needs to calculate which interface the packet from R1
will reach the R3 from. The specific process is as follows.
Li, et al. Expires July, 2024 [Page 5]
Internet-Draft intra-domain SAVNET January 2024
R1 will learn the route through IGP protocol, including the subnet
prefix accessed by each router in the domain and the route to the
outside of the domain. The logical next hop of these routes is
actually other routing nodes.
For R3, the received packet should be the following three cases:
o The destination address of the packet is R3 or the subnet prefix
accessed by R3.
o The packet goes out of the AS or Area and hits inter-AS or inter-
area route advertised by R3 as ASBR or ABR. At this time, R3
receives the packet as the logic next hop to these routes.
o The route hit by the destination address of the packet is
advertised by the downstream node of R3 on the Tree-R1. When
forwarding, the packet will pass through R3 node and go to the
downstream node of R3.
Packets from R1 in these three cases can take R3 as the logical next
hop, so the actual forwarding path of these packets is consistent
with the actual forwarding path of the packet with the destination
address of R3.
Therefore, R3 can calculate the forwarding path of the packet from
R1 to R3 based on the Tree-R1, and then get the physical interfaces
of the packet from R1 to R3.
Based on Tree-R1, the interface between R3 and the upstream node
will be the actual interface of R3 receiving the packet which is
from R1.
As shown in the figure below, Intf1 of R3 is the legal incoming
interface of packets from prefix P1.
Li, et al. Expires July, 2024 [Page 6]
Internet-Draft intra-domain SAVNET January 2024
+----+ Intf1
+------------+ R2 +---------------+
| +----+ +-+--+
| | R3 |
| +-+--+
| |Intf3
| |
| |
+-+--+ +----+ +-+--+
| R1 +---------+ R7 + | R6 |
+-+--+ +--+-+ +-+--+
| |
| |
| | +----+
| +---------------+ R5 |
| +----+
| +----+
+------------+ R4 |
+----+
Figure 2: Tree-R1 on R3
Repeat this process. Based on the shortest path tree with each
router as the root, R3 can get the legal incoming interfaces of all
protected prefixes in the domain, establish the SAV table, and guide
the verification of the source address of the packet in forwarding
plane.
As shown in Figure 1, the costs of links between R3 and R2 and links
between R3 and R7 are different in both directions. The forward and
reverse routes between R1 and R3 are asymmetric. According to the
result of R3 query of FIB, the message from R3 to R1 will be sent
from the interface connecting R3 and R7. Using the calculation
method of this proposal, the problem of asymmetric routing here can
be well solved. R1 and R3 can accurately calculate the actual
incoming interface according to the shortest path tree with R3 as
the root.
5. Scenario of Multi-area
In large-scale networks, an AS may be divided into different areas
to avoid the problems caused by too many nodes. As shown in the
following figure, an AS divided into two areas, each router is
connected to the corresponding subnet, R1 is connected to P1, and so
on, and R7 is connected to P7.
Taking OSPFv2 as an example, R4 and R5, as ABRs, will convert the
router LSA (type-1) of R6 and R7 in Area1 into network Summary LSA
Li, et al. Expires July, 2024 [Page 7]
Internet-Draft intra-domain SAVNET January 2024
(type-3) and advertise it to the routers in Area0. Area0 to Area1
are also processed in the same way.
The type-3 route received by R3 from R4 will include the subnet of
R6, with an originator of R4 and a cost of 10. According to the
method described in section 4, R3 will calculate the valid incoming
interface of P6 as intf1.
If the cost of the two directions of the link between R4 and R6 is
different for some reason, for example, the cost from R4 to R6 is
10, but the cost in the reverse direction is 100, which will cause
the packet sent by R6 to arrive at R3 from intf2 actually. But the
type-3 route advertised by R4 to R3 has only one-way cost from R4 to
R6, which cannot reflect the real situation.
In order to accurately calculate SAV rule in the scenarios of multi-
area, it is necessary to expand the type-3 route and advertise the
cost in reverse directions between ABR and a prefix at the same time.
That is, when R4 advertises the prefix information of R6, it carries
cost of 10 and reverse cost of 100 at the same time. Similarly, the
cost of R6 network prefix information advertised by R5 in two
directions is 40 and 50 respectively.
Area1
Area0 +-------------------------+
+-------------------------------+ | |
| | * cost 100(<-) *
* intf1 +-+-+-+(->)cost 10 +-----+ |
| +----+ +-------+ R4 +-------------+ R6 | *
* | R1 +---------+ | +-+-+-+ +--+--+ |
| +----+ ++--++ | | cost20 | *
* | R3 | * * (<->) | |
| ++--++ | | | *
* +----+ | | +-+-+-+(->)cost 20 +--+--+ |
| | R2 +---------+ +-------+ R5 +-------------+ R7 | *
* +----+ intf2 +-+-+-+ cost 30(<-) +-----+ |
| | | *
+-------------------------------+ +-------------------------+
Figure 3: example topology of multi-area
When ABR that enables SAV function advertises network Summary LSA
(type-3), ABR needs to calculate the total cost from the node where
the prefix in LSA is located to this ABR, and advertises it together
through protocol extension.
By extending the protocol, R3 can be aware that packets from P6 and
P7 will arrive at R3 from R5, so the valid incoming interface of the
two protected prefixes can be calculated as intf2.
Li, et al. Expires July, 2024 [Page 8]
Internet-Draft intra-domain SAVNET January 2024
After the AS is divided into different areas, in order to reduce
routing messages, the ABR may aggregate the routing information with
the same prefix and only publish one route to other areas. If the
forward or reverse path costs of the aggregated prefixes are
different, after advertising the aggregated route, the ABR that
enables the SAV function also needs to separately advertise a route
for the prefixes with different costs, and advertise the forward and
reverse costs corresponding to this prefix in this route.
6. Protocol Extension
6.1. Extension of OSPFv2
6.1.1. Extension for Protected Prefixes
A sub-TLV called Prefix-SAV sub-TLV is defined to identify a
protected prefix. The Prefix-SAV Sub-TLV is a sub-TLV of the OSPF
Extended Prefix TLV described in [RFC7684].
When the Route Type of OSPFv2 Extended Prefix TLV is Intra-Area (1)
or Inter-Area (3), prefix-SAV sub-TLV can be used to identify the
prefix.
It SHOULD appear only once in the parent TLV and has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: TBD1.
* Length: 4.
* Flags: Reserved flag field.
* Reserved: SHOULD be set to 0 on transmission and MUST be
ignored on reception
Li, et al. Expires July, 2024 [Page 9]
Internet-Draft intra-domain SAVNET January 2024
According to the current definition, if this sub-TLV appears in
ospfv2 extended prefix TLV, it means that the prefix in the message
is protected prefixes.
6.1.2. Extension for Reverse Prefix Cost
A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the
total costs from the router where the prefix is located to reach
ABR.
The Prefix-Reverse-cost Sub-TLV is a sub-TLV of the OSPF Extended
Prefix TLV described in [RFC7684].
When the Route Type of OSPFv2 Extended Prefix TLV is Inter-Area (3),
Prefix-Reverse-cost sub-TLV can be used.
It SHOULD appear only once in the parent TLV and has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reverse metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: TBD2.
* Length: 4.
* Rreverse metric: Total cost value from the router where the
prefix is located to ABR.
6.2. Extension of OSPFv3
6.2.1. Extension for Protected Prefixes
A sub-TLV called prefix-SAV sub-TLV is defined to identify a
protected prefix. The Prefix-SAV sub-TLV is a sub-TLV of the
following OSPFv3 TLVs as defined in [RFC8362] and in Section 5:
Intra-Area Prefix TLV
Inter-Area Prefix TLV
Li, et al. Expires July, 2024 [Page 10]
Internet-Draft intra-domain SAVNET January 2024
It SHOULD appear only once in the parent TLV and has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: TBD3.
* Length: 4.
* Flags: Reserved flag field..
* Reserved: SHOULD be set to 0 on transmission and MUST be
ignored on reception
6.2.2. Extension for Reverse Prefix Cost
A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the
total cost from the router where the prefix is located to reach ABR.
The Prefix-Reverse-cost sub-TLV is a sub-TLV of the following OSPFv3
TLVs as defined in [RFC8362] and in Section 5:
Inter-Area Prefix TLV
It SHOULD appear only once in the parent TLV and has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: TBD4.
Li, et al. Expires July, 2024 [Page 11]
Internet-Draft intra-domain SAVNET January 2024
* Length: 4.
* Reverse metric: Total cost value from the router where the
prefix is located to ABR.
6.3. Extension of IS-IS
6.3.1. Extension for Protected Prefixes
A sub-TLV called Prefix-SAV sub-TLV is defined to identify protected
prefixes. The Prefix-SAV sub-TLV is a sub-TLV of the following IS-IS
TLVs:
* TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
* TLV-235 (Multi-topology IPv4 Reachability) defined in
[RFC5120].
* TLV-236 (IPv6 IP Reachability) defined in [RFC5308].
* TLV-237 (Multi-topology IPv6 IP Reachability) defined in
[RFC5120].
It SHOULD appear only once in the parent TLV and has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: TBD5.
* Length: 2.
* Flags: Reserved flag field.
* Reserved: SHOULD be set to 0 on transmission and MUST be
ignored on reception
6.3.2. Extension for Reverse Prefix Cost
A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the
total cost from the router where the prefix is located to reach ABR.
Li, et al. Expires July, 2024 [Page 12]
Internet-Draft intra-domain SAVNET January 2024
The Prefix-Reverse-cost sub-TLV is a sub-TLV of the following of the
following IS-IS TLVs:
* TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
* TLV-235 (Multi-topology IPv4 Reachability) defined in
[RFC5120].
* TLV-236 (IPv6 IP Reachability) defined in [RFC5308].
* TLV-237 (Multi-topology IPv6 IP Reachability) defined in
[RFC5120].
When the level 2 router leaks routes through the above TLVs, Prefix-
Reverse-cost sub-TLV can be used to carry reverse total cost.
It SHOULD appear only once in the parent TLV and has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: TBD6.
* Length: 6.
* Reserved: SHOULD be set to 0 on transmission and MUST be
ignored on reception
* Reverse metric: Total cost value from the router where the
prefix is located to ABR.
7. Consideration of Redirection Routing Policy
In the actual deployment, some redirected forwarding policies may be
used, such as PBR and QoS. The forwarding path of the packets
processed by these policies may be inconsistent with the routing
table, resulting in a router receiving the packets forwarded based
on the routing table and the packets forwarded based on the
redirected forwarding policies from different interfaces. Therefore,
Li, et al. Expires July, 2024 [Page 13]
Internet-Draft intra-domain SAVNET January 2024
when calculating SAV rule, the influence of redirected forwarding
policy should also be taken into account.
Because the redirected forwarding policy is very complicated, this
section only describes a relatively simple scenario. More in-depth
and detailed analysis and discussion are expected to be added in
future versions.
The redirected forwarding policy can be deployed on any node in the
domain. These policies specify the characteristics of the packet, as
well as the outgoing interface and next hop to redirect the packet.
After a router applies this forwarding policy, the packets matching
the characteristics specified by the policy will be forwarded
according to the path specified by the policy, and its forwarding
path may be different from the route learned through IGP.
The packet characteristics of redirection routing policy often
contain a lot of information, including source and destination
addresses, Port number, protocol number and other information. Only
the source and destination addresses participate in the calculation
of SAV rule. If a redirected forwarding policy specifies only L4
information, the source and destination addresses are considered to
match all; similarly, if a redirection policy is only configured
with destination address characteristics, the source address is
considered to match all
Redirected forwarding policies can be divided into the following
categories:
o (Src, dest, M, nexthop): Both source and destination prefixes are
specified, as well as the next hop. M identifies whether other
non-address fields are specified. If so, it indicates that the
redirection policy only works on part of the traffic, and it
needs to be calculated based on the routing and redirection
policies at the same time; If not, it means that this policy will
affect all packets matching the source and destination prefixes,
and these packets can no longer calculate SAV rule according to
the routing.
o (*, dest, M, nexthop): Only the destination prefix and next hop
are specified. M has the same meaning as above. * means to match
all source addresses, that is, there is no restriction on source
addresses.
o (Src, *, M, nexthop): Only the source prefix and next hop are
specified. M has the same meaning as above.
Li, et al. Expires July, 2024 [Page 14]
Internet-Draft intra-domain SAVNET January 2024
o (*, *, M, nexthop): The source and destination prefixes are not
specified, and M must be yes at this time.
If some nodes in the domain have enabled the redirected forwarding
policy, when calculating the SAV rule, R3 cannot rely on a single
shortest path tree, but also needs to collect the redirected
forwarding policy of relevant nodes to calculate the valid incoming
interface for the packet from R1 to R3.
The redirected forwarding policy is complex and needs to be
considered comprehensively based on the information of multiple
nodes. This document takes a simple case as an example to illustrate
the calculation process
1. Assume that R1 and R7 are configured with redirection policies as
follows:
R1 (*, dst1, Yes, R7)
R7 (*, dst1, Yes, R3)
Dst1 is the route prefix advertised by R3. According to these
policies, the forwarding path of some packets from R1 to dst1 is
R1->R7->R3. But the forwarding path according to the route should
be R1->R2->R3.
2. After receiving the redirection policy advertised by R1, R3 finds
that dst1 is the routing prefix advertised by itself, and can know
that the next hop specified by the redirection rule is R7.
3. If there is no matching redirection policy on R7, then according
to tree-R7, the next hop to dst1 is R2, which is the upstream node
of R3 on tree-R1, and R2 also has no redirection policy. Then there
is no need to continue the calculation. That is, the current
redirection policy will not increase the incoming interface for R3
to receive packets from R1.
4. If there is also a matching redirection policy on R7, and the
next hop is R3, then intf2 of R3 also needs to be the valid incoming
interface of the packet from R1.
Li, et al. Expires July, 2024 [Page 15]
Internet-Draft intra-domain SAVNET January 2024
+----+ 10
| R2 +-----------------+
+-+--+ +-+--+
| | R3 |
| +-+--+
10 | |
| | 10
| |
+----+ 10 +-+--+ +-+--+
| R1 +---------+ R7 | | R6 |
+-+--+ +-_--+ +----+
| |
| |
10| | 10 +----+
| +---------------+ R5 |
| +----+
| +----+
+------------+ R4 |
+----+
Figure 4: Tree-R7
The actual situation is more complicated. The redirected forwarding
policies configured on different nodes may specify different packet
characteristics, so the affected prefix range is also different.
Therefore, the calculation of SAV rule based on redirected
forwarding policy needs further analysis and discussion.
8. IANA Considerations
TBD.
9. Security Considerations
This document does not introduce any new security consideration.
10. References
10.1. Normative References
[I-D.ietf-savnet-intra-domain-problem-statement] Li, D., Wu, J.,
Qin, L., Huang, M., Geng, N., "Source Address Validation
in Intra-domain Networks (Intra-domain SAVNET Gap
Analysis, Problem Statement and Requirements", draft-ietf-
savnet-intra-domain-problem-statement-02 (work in
progress), August 2023.
Li, et al. Expires July, 2024 [Page 16]
Internet-Draft intra-domain SAVNET January 2024
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI
10.17487/RFC2328, April 1998, <https://www.rfc-
editor.org/info/rfc2328>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI
10.17487/RFC5308, October 2008, <https://www.rfc-
editor.org/info/rfc5308>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, DOI
10.17487/RFC5120, February 2008, <https://www.rfc-
editor.org/info/rfc5120>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
Contributors
Li, et al. Expires July, 2024 [Page 17]
Internet-Draft intra-domain SAVNET January 2024
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Xueyan Song
ZTE Corporation
China
Email: song.xueyan2@zte.com.cn
Yuanxiang Qiu
New H3C Technologies
China
Email: qiuyuanxiang@h3c.com
Li, et al. Expires July, 2024 [Page 18]
