Hi Robert, First, We have analyzed the adversary models of SAV messages as follows.
1) Message alteration: A malicious AS alters any part of a DSAV message, such as source prefix field or propagation scope field. 2) Message injection: A malicious AS injects a “valid” DSAV message and sends it to the corresponding next-hop AS, such as replay attacks. 3) Path deviation: A malicious AS sends a DSAV message to a wrong next-hop AS which conflicts with the propagation scope field. 4) Combination attack: A malicious AS alters a DSAV message to prevent path deviation from causing obvious conflicts, which is the most challenging attack. Generally, we are facing the same problem as in BGP routing. So BGPsec and RPKI-like approaches can be taken to prevent nodes from advertising false prefixes. Existing symmetric cryptography mechanisms for origin and path validation can also be used address these adversary models. Other security problems and mechanisms are to be explored. Can you explain more about "A lot of harm can be done if you just try to copy BGP state of the art in security"? Second, at this stage I am not saying that we cannot leverage BGP FlowSpec to help distribute the SAV messages. We are also thinking about the feasibility. But even so, what I want to mean is that it is not all of the story in our solution. We need a way to scalably notify the source prefixes of each AS to other ASes along the real forwarding path, which is the core of our architecture. Again, can you explain more about "But I guess/hope analysis has been done on this already "? Backup path is also one of our design choices to handle the convergence problem during failure, which can be found from the slides we presented in the last SAVNET BOF. In this case, we just regard the backup path as a valid path as well when building the SAV tables. Given our solution supports multi-path routing, there is no big difference in the design architecture. Best, Dan 发件人: Robert Raszuk <[email protected]> 发送时间: 2022年5月11日 23:30 收件人: Dan Li <[email protected]> 抄送: [email protected]; RTGWG <[email protected]>; Lizhenbin <[email protected]> 主题: Re: [savnet] IPv6 and/or IPv4//RE: SAVNET WG charter Hi Dan, > So the security approaches adopted to BGP routing can also be applied to > secure > SAV messages, such as BGPsec, RPKI, etc. If you want to apply SAV messages for any filtering the security aspect must be solved first. A lot of harm can be done if you just try to copy BGP state of the art in security. > The idea of SAV protocol is to let each AS advertise it’s prefixes along the > “real” data-plane forwarding path. + > path should make a decision on which neighboring AS to propagate this > message, based on its AS routing path > it chooses in the data plane. I am not seeing what is missing in FlowSpec encoding to do just that. Of course advertising SAV to selected peers unlike advertising reachability to all peers will have a drastic connectivity restoration effect. But I guess/hope analysis has been done on this already. Waiting for any control plane convergence during link or node failure is not the correct model to build robust networks. Backup state (including filters if applicable) should be in place ahead of any failures. Best, Robert On Wed, May 11, 2022 at 4:23 PM Dan Li <mailto:[email protected]> wrote: Hi Robert, First, in the charter we do not specifically mention how to secure the new protocol. We want to leave it to the architecture design document. But we have widely discussed the security issue of protocol messages in the mailing list before. Generally, the SAV message propagation direction is the inverse of BGP routing advertisement messages, and SAV faces similar security problems as BGP routing messages. So the security approaches adopted to BGP routing can also be applied to secure SAV messages, such as BGPsec, RPKI, etc. Second, RFC 8955 does not solve the problem of SAV. If we talk about BGP flow spec, let’s focus on the inter-domain scenario of SAV. The idea of SAV protocol is to let each AS advertise it’s prefixes along the “real” data-plane forwarding path. Each AS in the path should make a decision on which neighboring AS to propagate this message, based on its AS routing path it chooses in the data plane. It’s not “broadcasting” to all neighboring ASes. BGP flow spec protocol does not handle these issues. Best, Dan 发件人: Robert Raszuk <mailto:[email protected]> 发送时间: 2022年5月11日 21:39 收件人: Dan Li <mailto:[email protected]>; mailto:[email protected]; RTGWG <mailto:[email protected]> 抄送: Lizhenbin <lizhenbin=mailto:[email protected]> 主题: Re: [savnet] IPv6 and/or IPv4//RE: SAVNET WG charter Hi, Could someone point me to the text (or charter section) describing how this new protocol is going to be secured ? In RFC5575/8955 we used BGP to automatically validate if the peer advertising the DDoS vector is the same as the peer advertising IP reachability to those src addresses subject to additional filtering. How is SAVNET going to solve this ? Also let me repeat one question which I asked before and have not seen reply to .. What is missing in vanilla RFC8955 for SAVNET ? It is supported today by all major vendors, deployed and in fact in use. Do we need a mirror of existing solution ? There is also ongoing work for Flowspec v2 if there is something missing in v1 - but for SAV I am not sure v2 would be needed. Thx a lot, Robert. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
