Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Danny McPherson <[e-mail]>]

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