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

[Stephen Kent <[e-mail]>]

At 9:32 PM -0400 11/2/11, Danny McPherson wrote:
>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 think we can, because of the SIDR charter. The focus is on 
authenticity for inter-AS paths, not intra-AS paths. Any attacks 
against iBGP would appear, externally, to be equivalent to internal 
config errors or other forms of internal attacks. But, if you wish, I 
can add a sentence or two to state that explicitly.

>  > 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?

The WG charter established this scope.

>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.

see comment above.

>  > 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.

I agree that adding security after the fact is never the preferred 
approach. But we often are forced to do that in the IETF because we 
have very widely deployed protocols. The IESG chartered this WG with 
a specific scope. We are adding onto BGP, not starting from scratch. 
You're certainly welcome to propose how to do this better, consistent 
with the SIDR charter.

>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..).

I presume that your statement "fundamental shift from the stateful 
BGP model..." refers to beaconing. Beaconing does create a new basis 
for propagating a route, but an AS could cause the same impact on the 
routing system by changing other route parameters at the same 
frequency, consistent with the BGP spec. I'd prefer a better 
solution, but I don't have one to offer at this time.

Steve