That's correct, Aijun. Your summary is very good. Best, Dan
-----邮件原件----- 发件人: Aijun Wang <[email protected]> 发送时间: 2022年5月12日 18:00 收件人: Dan Li <[email protected]> 抄送: Sriram, Kotikalapudi (Fed) <[email protected]>; [email protected]; RTGWG <[email protected]> 主题: Re: [savnet] some questions about basic principles -- DSAV vs. RFC 8704 Hi, Dan: Thanks for your explanation. Back to the questions of Sriram on #Comments 1, the conclusion are the following: If AS4 has deployed the DSAV, but AS1 doesn’t, then AS4 will not block the spoofed packet of AS1 from the sources other than AS1 and also the legitimate packet AS1. No more harm, and no additional benefit. If AS4 has deployed the DSAV, and also AS1, then the spoofed packet for AS1 will be blocked. Only the legitimate packet from AS1 will pass. No more harm, but get additional benefits. This may trigger the motivation of DSAV deployment from AS1, and the mutual benefits can be gotten by AS1 and AS4. Wish my above understandings are correct. Aijun Wang China Telecom > On May 12, 2022, at 15:44, Dan Li <[email protected]> wrote: > > Hi Aijun, > > Thanks for your question. In the previous interaction with Ben, I explained > the additional benefit of DSAV compared with uRPF-based technology. I just > copy the descriptions and put them below. > > The best practice for inter-domain SAV is RFC 8704 (EFP-uRPF). We agree that > “if a network does not deploy internal ingress filtering, then we cannot > suppose that it will deploy the control-plane protocol”. But there are still > many cases we can do better than RFC 8704. In the BOF meeting, we also use an > example to show the benefit. Simply speaking, neighboring ASes who would like > to deploy SAV mechanisms can form a “deployed area”, and the advantage of our > solution over the current practice is that “ASes within the deployed area > cannot spoof each other, and ASes in the undeployed area cannot spoof the > source addresses of the deployed area”. If disconnected “deployed areas” can > be logically connected (by crossing the “undeployed areas”), we can do even > more. Specifically, multiple disconnected islands can form an “alliance” to > protect their addresses from being forged by “outside-alliance” networks. But > of course there is more challenge than a single island, because the real > forwarding paths in the intermediate “undeployed areas” are block boxes. > > For better understanding, Ben once summarized the benefit as “an island of > cooperating and mutually-trusting networks to enforce a common border policy > that prevents spoofing of on-island addresses from outside of the island.” > > If the descriptions above still do not help you understand our solution and > its benefit, we can continue the discussion. > > Best, > Dan > > -----邮件原件----- > 发件人: Aijun Wang <[email protected]> > 发送时间: 2022年5月12日 14:49 > 收件人: Dan Li <[email protected]> > 抄送: Sriram, Kotikalapudi (Fed) <[email protected]>; > [email protected]; RTGWG <[email protected]> > 主题: Re: [savnet] some questions about basic principles -- DSAV vs. RFC > 8704 > > Hi, Dan: > > Aijun Wang > China Telecom > >> On May 12, 2022, at 13:35, Dan Li <[email protected]> wrote: >> >> Hi Sriram, >> >> Thanks a lot for your detailed comments. I answer your questions one-by-one >> as follows. >> >> [To Comment #1]: When DSAV is partially deployed, the source prefixes which >> do not appear in the SAV table will not be blocked. So there will not be >> improper block problem due to partial deployment. This operation also helps >> understand the incentive of DSAV: if you deploy DSAV, other ASes can >> identify and reject packets with spoofed source addresses of you (which can >> avoid reflective DDoS); if you do not deploy DSAV, you do not get the >> benefits. > > [WAJ] To achieve the above effect, does “other ASes” that you mentioned > should have SAV table in their routers? If so, should we call these “other > ASes” have also deployed the DSAV? Although they don’t generate the DSAV > notification messages. > >> >> In the example, if AS1 does not deploy DSAV, it will not generate original >> notification messages and AS4 will not learn the valid incoming port for >> source prefixes of AS1 (i.e., P1, P2, P3). So, AS4 will pass those packets >> with source addresses of P1, P2, and P3. > [WAJ] In this example, if AS1 deploy DSAV, and generate original > notification messages, but AS4 doesn’t understand such messages, then AS4 > will still not form SAV table to filter the spoofed source addresses for P1, > P2 and P3? Then the effect of DSAV should still be depended on the > cooperation of neighboring AS? >> >> We have talked about our incremental deployment considerations with Ben in >> the mailing list. In incremental/partial deployment scenario, each “deployed >> area” gains benefits: “ASes within the deployed area cannot spoof each >> other, and ASes in the undeployed area cannot spoof the source addresses of >> the deployed area”. Moreover, if disconnected “deployed areas” can be >> logically connected (by crossing the “undeployed areas”), multiple >> disconnected “deployed areas” can form an “alliance” to protect their >> addresses from being forged by “outside-alliance” networks. >> >> [To Comment #2]: RFC 8704 proposes two EFP-uRPF algorithms, namely, >> algorithm A and algorithm B. However, since algorithm A has improper block >> problems (as described in RFC 8704 Section 3.3), RFC 8704 (Section 3.7) >> recommends to deploy algorithm B at customer ports. Algorithm A can only be >> used when operators are confident that their inter-domain routing scenarios >> will not trigger improper block, which we think is difficult for operator in >> practice. But we think the recommendation is reasonable. So, we mainly focus >> on the problem of EFP-uRPF algorithm B. We also give the gap analysis of >> EFP-uRPF algorithm A in the slides presented in the BoF meeting. If there is >> any more confusion for this issue, we can discuss further. >> >> [To Comment #3]: Yes I agree with you for the conclusion when AS3 is not >> upgraded in the example. Both uRPF-based solutions and DSAV use the incoming >> interface as the signal to determine spoofed packets. So if two source >> prefixes use the same valid incoming port, spoofing between the two source >> prefixes cannot be identified at the incoming port. But DSAV can still do >> more than existing uRPF-based solutions. Let's use the same example but >> assume AS3 deploys SAV filtering now. If AS3 uses EFP-uRPF algorithm B >> (following the recommendations of RFC 8704), AS1 and AS2 can spoof each >> other. If AS3 uses DSAV and receives notification messages from AS1 and AS2, >> it can generate a finer-grained SAV table: packets with source addresses of >> P1 must come from AS1, and packets with source addresses of P2 must come >> from AS2. In this case, DSAV can achieve more accurate SAV. >> >> [To Comment #4]: In DSAV notification message, the source prefix field is >> used to generate SAV rules, while the propagation scope (or the list of >> destination prefixes) is used to discover the real data-plane forwarding >> path. More specifically, during the prefix notification process, each router >> looks up the local FIB table against the destination prefixes in the >> propagation scope, to determine toward which interface to relay the >> notification message. Before an AS relays the notification message to >> neighboring ASes, it will delete its own prefixes from the propagation >> scope. Therefore, the destination prefixes in the propagation scope field >> will become less and less as the notification process goes on. The >> notification process will be terminated when the scope becomes empty. >> >> In the draft, maybe we used a too simple example, which did not clearly >> describe the process. Without the prefix notification process, the other >> ASes do not know how map source prefixes to the correct incoming >> interface(s). In the updated draft, we will use a better example. >> >> [To Comment #5]: DSAV is short for “Validating Source Addresses via SAV >> Tables Generated by a Distributed Control-plane Protocol”, while not short >> for “Distributed SAV”. We use the full name in the BOF meeting. Yes uRPF is >> fully distributed. To avoid confusion, we will change it to a better short >> name in the updated draft. >> >> Best, >> Dan >> >> 发件人: Sriram, Kotikalapudi (Fed) <[email protected]> >> 发送时间: 2022年5月12日 4:53 >> 收件人: Dan Li <[email protected]> >> 抄送: [email protected]; 'RTGWG' <[email protected]> >> 主题: some questions about basic principles -- DSAV vs. RFC 8704 >> >> 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 >> >> >> -- >> savnet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/savnet > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
