Intra-domain SAVNET method
draft-lin-savnet-lsr-intra-domain-method-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Changwang Lin , Yuanxiang Qiu | ||
| Last updated | 2022-07-09 | ||
| Replaced by | draft-li-lsr-igp-reverse-prefix-metric | ||
| RFC stream | (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-lin-savnet-lsr-intra-domain-method-00
SAVNET Working Group C. Lin
Internet Draft Y. Qiu
Intended status: Standards Track New H3C Technologies
Expires: January 11, 2023
July 10, 2022
Intra-domain SAVNET method
draft-lin-savnet-lsr-intra-domain-method-00
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
information 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 January 11 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lin, et al. Expire January, 2023 [Page 1]
Internet-Draft intra-domain savnet July 2022
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 information based on IGP extension .......... 3
3. Advertising the protected prefixes .......................... 4
4. Calculate SAV information based on IGP ...................... 4
5. Scenario of Multi-area ...................................... 7
6. Protocol extension .......................................... 8
6.1. Extension of OSPFv2 .................................... 8
6.1.1. Extension for protected prefixes .................. 8
6.1.2. Extension for reverse prefix cost ................. 9
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.
Lin, et al. Expires January, 2023 [Page 2]
Internet-Draft intra-domain savnet July 2022
[draft-li-sav-gap-analysis] describes the gap analysis of various
current SAV methods.
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 information 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 information based on IGP extension
By extending the IGP routing protocol, each routing node calculates
independently SAV information, 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.
Lin, et al. Expires January, 2023 [Page 3]
Internet-Draft intra-domain savnet July 2022
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 information 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 information
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
information.
The prefix that needs to participate in SAV information 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 information 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. The corresponding message extensions are
described in Section 7.
4. Calculate SAV information based on IGP
This section describes how to calculate SAV information 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.
Lin, et al. Expires January, 2023 [Page 4]
Internet-Draft intra-domain savnet July 2022
subnet(p2)
,-----. subnet(p3)
( _) ,---------.
`-----'-_ ( )
+----+ Intf1`-----+---'
+------------+ R2 +-----------------+ /
| +-+--+ +-+--+
| | | R3 |
subnet(p1) | | +---------------+-+--+
----. | | | Intf2 | Intf3
( ) | | | |
---`: | | | subnet(p7) |
`.+-+--+ +-+--+ ,---. +-+--+
| R1 +---------+ R7 +---( ) + R6 |`.subnet(p6)
+-+--+ +-+--+ `---' +-+--+ `-,---.
| | | | ( )
| | | | `---'
| | | +-+--+
| | +---------------+ R5 |-
| | +-+--+ ,`-..
| +-+--+ | ( )
+------------+ 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
information 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.
R1 will learn the route through IGP protocol, including the subnet
prefix accessed by each router in the domain and the route to the
Lin, et al. Expires January, 2023 [Page 5]
Internet-Draft intra-domain savnet July 2022
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, the intf1 interface of R3 is the legal
incoming interface of packets from prefix P1.
Lin, et al. Expires January, 2023 [Page 6]
Internet-Draft intra-domain savnet July 2022
+----+ Intf1
+------------+ R2 +-----------------+
| +----+ +-+--+
| | R3 |
| +-+--+
| |Intf3
| |
| |
+-+--+ +----+ +-+--+
| R1 +---------+ R7 + | R6 |
+-+--+ +----+ +-+--+
| |
| |
| | +----+
| +---------------+ R5 |
| +----+
| +----+
+------------+ R4 |
+----+
Figure 2: Tree-R1
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 binding entry, and
guide the verification of the source address of the packet in
forwarding plane.
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
(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
Lin, et al. Expires January, 2023 [Page 7]
Internet-Draft intra-domain savnet July 2022
the packet sent by R6 to arrive at R3 from intf2 actually. 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 information 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.
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].
Lin, et al. Expires January, 2023 [Page 8]
Internet-Draft intra-domain savnet July 2022
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 octets.
Flags: Reserved flag field.
Reserved: SHOULD be set to 0 on transmission and MUST be
ignored on reception
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.
Lin, et al. Expires January, 2023 [Page 9]
Internet-Draft intra-domain savnet July 2022
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 octets.
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lin, et al. Expires January, 2023 [Page 10]
Internet-Draft intra-domain savnet July 2022
where:
Type: TBD3.
Length: 4 octets.
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.
Length: 4 octets.
Reverse metric: Total cost value from the router where the
prefix is located to ABR.
Lin, et al. Expires January, 2023 [Page 11]
Internet-Draft intra-domain savnet July 2022
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 | Reversed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBD5.
Length: 2 octets.
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.
Lin, et al. Expires January, 2023 [Page 12]
Internet-Draft intra-domain savnet July 2022
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBD6.
Length: 4 octets.
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
Lin, et al. Expires January, 2023 [Page 13]
Internet-Draft intra-domain savnet July 2022
redirected forwarding policies from different interfaces. Therefore,
when calculating SAV information, 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 information. 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 information
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.
Lin, et al. Expires January, 2023 [Page 14]
Internet-Draft intra-domain savnet July 2022
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 information, 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.
Lin, et al. Expires January, 2023 [Page 15]
Internet-Draft intra-domain savnet July 2022
+----+ 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 information 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.li-sav-gap-analysis] Li, D., Wu, J., Huang, M., Qin, L., Geng,
N., " Source Address Validation: Use Cases and Gap
Analysis ", draft-li-sav-gap-analysis-01 (work in
progress), January 2022
Lin, et al. Expires January, 2023 [Page 16]
Internet-Draft intra-domain savnet July 2022
[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
Lin, et al. Expires January, 2023 [Page 17]
Internet-Draft intra-domain savnet July 2022
Authors' Addresses
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Yuanxiang Qiu
New H3C Technologies
Email: qiuyuanxiang@h3c.com
Lin, et al. Expires January, 2023 [Page 18]