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 <[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 <[email protected]> > *发送时间:* 2022年5月11日 21:39 > *收件人:* Dan Li <[email protected]>; [email protected]; RTGWG < > [email protected]> > *抄送:* Lizhenbin <[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
