Hi, Dan and co-authors (DSAV):
I am still catching up with the discussions on the mailing list. So please let
me know if I am repeating any questions already discussed and point me to the
relevant messages on the list to catch up. I am up to speed in the sense I
attended the BoF at the March IETF and I have read the drafts on gap analysis
and DSAV.
Comment #1: Regarding the accuracy of the permit list, in the following example
(see the figure below copied from RFC 8704), assume that AS1 is not upgraded
and does not do DSAV (partial deployment scenario). It does not announce P3 by
its policy to AS2 or AS3 and announces P3 only to AS5. But it sends data
traffic with source addresses in P3 towards AS2 and AS3. Am I right in
understanding that, with the DSAV protocol, AS4 will block data with SA in P3
on the interfaces with customers AS2 and AS3?
By comparison, with Algorithm A of EFP-uRPF (RFC 8704), AS4 will not block
(data with SA in P3 on the interfaces with customers AS2 and AS3) in this
partial deployment scenario. As you have acknowledged, Algorithm A is
reasonably good with directionality.
Partial deployment usually lasts for years, and hence any proposed method
should provide benefits to early adopters during partial deployment. RFC 8704
(EFP-uRPF) has the benefit that it works for an AS higher in the
provider-customer hierarchy even when all ASes in the lower levels in the
hierarchy have not adopted the method. (Granted that some education is needed
about the operational recommendations in Sec 3.2.)
+----------+ P3[AS5 AS1] +------------+
| AS4(ISP4)|<---------------| AS5(ISP5) |
+----------+ (P2P) +------------+
/\ /\ /\
/ \ /
P1[AS2 AS1]/ \P2[AS3 AS1] /
(C2P)/ \(C2P) /
/ \ /
+----------+ +----------+ /
| AS2(ISP2)| | AS3(ISP3)| /
+----------+ +----------+ /
/\ /\ /
\ / /
P1[AS1]\ /P2[AS1] /P3[AS1]
(C2P)\ /(C2P) /(C2P)
\ / /
+----------------+ /
| AS1(customer) |/
+----------------+
P1, P2, P3 (prefixes originated)
(Figure 4 in RFC 8704.)
Comment #2: You did not give weight to Algorithm A in RFC 8704 in your gap
analysis. IMO, Algorithm A works well and works even better if the operational
recommendations in Sec 3.2 are heeded. And also, it does not have the messaging
overhead that DSAV has.
Comment #3: In the gap analysis document you stated:
“When AS1 spoofs IP address prefix P2 of
AS2, the malicious Northward traffic cannot be filtered by AS4. The
same is true when AS2 forges P1 of AS1. That is to say, EPF-uRPF
cannot prevent source address spoofing among customers even though it
only focus on Northward traffic.”
I know precisely what you mean. However, I think the DSAV also has the same
shortcoming. It is unavoidable when ASes in the middle (along the path) are not
upgraded. Consider this example:
AS4
|
AS3 (not upgraded to do SAV filtering)
/ \
AS1 AS2
(P1) (P2)
AS4 is compliant but still, it cannot block if a hacker at AS2 spoofs a source
address in P1 because the data packets have no path information. Some
compromise about directionality seems inevitable. Do you agree?
Comment #4: In the example (figure below) in your DSAV draft, nodes 2, 3, and 4
already know P2, P3, and P4 via BGP Updates. Based on that they can set their
permit lists for SAV on the appropriate interfaces. It seems redundant to send
dest_v = [P2, P3, P4]. What does it convey to Nodes 2, 3, and 4 that is new?
What am I missing?
+----------+
| Node 1 +---+P1
+----+-----+
| pkt:src_v=[P1],
| dst_v=[P2,P3,P4]
pkt:src_v=[P1], |
+----------+ dst_v=[P4] +-----#-----+
| Node 4 #-------------+ Node 2 |---+P2
+-----+----+ +-----+-----+
| | pkt:src_v=[P1],
+ | dst_v=[P3]
P4 |
+-----#-----+
| Node 3 +---+P3
+-----------+
(Figure 1 in the DSAV draft.)
Comment #5: Is there a statement being made by the name ‘Distributed SAV
(DSAV)’ that other proposals such as EFP-uRPF are not distributed? I think all
uRPF schemes are distributed. Each AS or node can implement any kind of uRPF
independently of the other ASes. The more the ASes that adopt uRPF, the better
it is to stop the spoofing closer to the source. But with DSAV there are
dependencies – an AS needs other ASes to deploy DSAV messaging to create its
permit list.
I am happy to discuss, correct any misunderstandings on my part, and learn
further 😊
Thank you.
Sriram
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
