Re: [savnet] Some thoughts on SAVNET

[[e-mail]]

Continue the discussion with Jari here.

 

In the previous email I said that OSPF is not enough to discover the real forwarding path in the data plane, because the data-plane forwarding path may not only be determined by OSPF. Static routing, ACL-like routing redirection may also change the real data-plane forwarding path.

 

We can argue that there are two possible solutions: learning the actual forwarding path used vs. the set of possible forwarding paths. There are two issues.

 

1) We need a way to determine which are “possible” forwarding paths. For intra-domain SAV, since network topology is a connected graph, if we do not consider the routing/configuration choices, every incoming interface may be the “possible” incoming interface. If we consider the routing/configuration choices, there will be a “delay” between routing update and SAV learning. But maybe we can add the “possible” path from FRR (fast rerouting). For inter-domain SAV, if we want to consider “possible” forwarding path, we can ask each AS to send the prefix notification message to all the neighboring ASes from which a BGP routing message is announced, instead of only sending the prefix notification to the neighboring AS which is selected as the next hop. 

 

2) Accuracy. If we can select the real forwarding path, the improper permit ratio will be minimized, but there may be improper block. If we can select all the “possible” paths, the improper block ratio will be reduced. If setting every interface as the possible incoming interface, the improper block ration will be zero, but it does not help solve the source address spoofing problem at all.

 

Dan

 

发件人: [e-mail] <[e-mail]> 代表 Jari Arkko
发送时间: 2022年3月21日 20:13
收件人: [e-mail]
主题: [savnet] Some thoughts on SAVNET

 

I’ve been reading through the meeting materials. Some questions and comments below. These are of course my opinions only but provided in case they are useful for your consideration.

 

Intro/chairs slides:

 

*	Looked good, right framing for the discussion.

 

Gap analysis – overall good, some comments though:

 

*	Nice focus on incentives (e.g., page 4) – good!

 

*	“Traditional Internet architecture lacks SAV (source address validation)”. To me this seemed a bit too hard statement to make. Source address checking is as old as the dial-up times in the 1990s. But it is of limited capability or coverage though.

 

*	”SAV for access network - SAVI [RFC 6620, 6959, 7039, 7219, 7513, 8074]”. Is this list of RFCs complete? Ingress filtering in the access networks predates the work on SAVI, see e.g. RFC 2267.

 

*	I was trying to think about the root cause situation (slide 9), and wondered about fundamentals of routing. Not that I know much about it, but … Could it be that there are actually three root causes?:

 

*	One, if you do not use all the information that would be available. For instance, if you *did* have a network topology map like the one on slide 8, you *could* in theory calculate that P2 can only come from AS2, whereas P3 could come from AS1, AS3, or AS5 given their connectivity. RFC 8704 doesn’t seem to use this info.. and I’m not sure if that’s because of BGP’s nature as a distance vector/path vector protocol.
*	Secondly, not all necessary information is passed from the networks to each other.
*	Thirdly, something happens in network part X, and this needs to be taken into account in network part Y in real-time. There doesn’t seem to be a way around this actually, it is always the case that X knows the situation before Y, so either you (a) ensure that no data plane packets get sent before you’ve confirmed that Y has learned about the change (introducing an undesirable delay) or (b) accept that before Y learns of the true situation, some packets may be improperly discarded or passed through a SAV check.

 

Given this, it would seem to be that to improve SAV, one has to primarily ensure that enough data is shared and that all the shared data is actually used. This does not necessarily need a new network protocol, if existing routing protocols pass the necessary information. It would seem to be the case that OSPF for instance does, if I have understood things correctly. Of course, you may wish to ensure that there’s less temporary glitches when something changes. However, that doesn’t fundamentally seem to be possible with introducing a delay of some kind. But one can of course reduce the delay by ensuring that either a routing protocol or new protocol communicates a change as soon as it has happened.

 

Would appreciate comments on this. Am I missing something?

 

*	Overall question about incentives is whether an incremental improvement in SAV with a cost is more desirable than putting the same cost in some other activity. 

 

DSAV:

 

*	Overall looked good
*	I really liked having a set of open questions, thanks for this!
*	Is there an open question of whether a DSAV protocol could be an extension of a routing protocol?
*	Authenticating the DSAV protocol messages seems to be a clearly required requirement. Perhaps based on the same methods used for authenticating routing protocol statements. Still, it is unclear if there’s an actual difference. If I am a network X, I can show that I own prefix P (e.g., via RPKI) and statements about that will be believed by receivers. And since X has a peering agreement with Y, Y believes that the messages come from a legitimate peer. However, it is less clear to me how routing protocol information (you can reach Z via X) or other source address data (X will be sending from prefixes P and Q) can be believed…

 

ESAV:

 

*	Nicely explained, overall good again
*	Presentation doesn’t include details of how tags are generated and verified, but there’s a lot of material on hierarchies. Is that the right choice? Draft section 8.3 was clearer to me. Still, details may also matter, how many bits, etc.
*	Incentive question: If the problem is that network X hasn’t done its access-side source address validation correctly, what are the chances that it will add tag-generating feature on its outgoing interface? Would the ESAV only be done between networks that didn’t have a SAV problem to begin with?

 

Jari