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
