[savnet] Some thoughts on SAVNET

[Jari Arkko <[e-mail]>]

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