On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote: > The focus of BGPSEC is eBGP, because the concern is verifying the > authenticity of routes arriving from other ASes. The hard problems arise > for eBGP because these routes are delivered via BGP speakers in different > "trust domains." iBGP integrity and authenticity can be achieved via > internal security procedures and thus is not a focus of BGPSEC.
But given that these attributes and the threat model include internal BGP speakers and the largest scale issues (e.g., route reflectors with 5 millions paths _today), we can't simply expect that it's out of scope. > I replied to the ORIGIN attribute question in my other message. > > NLRI and AS_PATH are the attributes being protected both because they > represent the fundamental routing data elements, and because they are > attested to in the RPKI. Using the RPKI we can determine whether the origin > AS is authorized to originate a route for the NLRI. We can verify whether a > BGP speaker representing each AS in the AS_PATH is the entity that signed the > data carried as part of an Update. We don't have analogous, authoritative > data about MPLS, for example, so we can't provide the same sort of security > guarantees. If the community identifies data carried in Updates that it > believes should be protected, and > we can agree on security semantics that are enforceable relative to the > BGPSEC architecture, then we could expand protection, perhaps in a v2 of the > protocol. But if we add considerable overhead (orders of magnitude from where we are today) to deploy BGPSEC and only focus on a subset of the Path Attribute (i.e., AS_PATH only) integrity functions then the ORIGIN code Path Attribute (and also many others) can still be manipulated to change BGP decision algorithms and induce traffic attraction attacks, then perhaps we need to challenge the assumptions that led to scoping a solution to AS_PATH and NLRI in the first place, as I really haven't seen a consensus call on this in the WG either? I think I constitute a participant in "the community" here -- or are we all expected to accept this large set of documents and assumptions as gospel and use the SIDR WG as a publication house for work done outside of the IETF? I'd be less uncomfortable if the aim was to publish this set of documents as Experimental until they generate some critical deployment mass, and the broader community refines based upon operational experience until then, which is something that I'm becoming more amenable to, but to dictate as "the solution" for secure routing with some many outstanding issues concerns me. > Beacon frequency affects how responsive BGPSEC is relative to one set of > attacks. A more accurate statement is that the beacon parameters that the > BGPSEC design is likely to use will induce significant latency detecting > those attacks. Reducing the latency would require more frequent beaconing, > and that is viewed as an unacceptable tradeoff, at lest for now. The residual > vulnerability due to beacon latency relates to the ability of an AS that was > authorized to advertise a route, to replay the advertisement, even when it is > not currently authorized to do so. This vulnerability should be viewed in the > context of the inability of a BGP speaker to know whether a neighbor has > failed to withdraw a route, when it has no paths for the prefix in question. > An AS cannot, in general, know whether the only route for a given prefix has > been withdrawn at some point upstream. This the BGP design and operational > model embodies this vulnerability. And to challenges assumptions, why is beaconing or the current mechanisms proposed in BGPSEC the right approach -- surely it's something more than "because we bolted a PKI on to a distributed protocol and this is how it's got to work? If that's the case, this becomes a prime example of precisely why we don't want to bolt security on after the fact, particularly in the case of distributed systems and protocols, and if we're working on 8-10 year out solutions, I'd like to think we can do better than this. More specifically, if I have perform a cost/benefit analysis it's not at all clear to me that tightening exposure windows to the frequency (hours/days) you're suggesting is worth the investment and fundamental shift from the stateful BGP model we know today, particularly given the drive-by and targeted nature we see in all other aspects of security today (e.g., APT, phishing, etc..). -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
