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

[Stephen Kent <[e-mail]>]

At 10:03 PM -0400 10/28/11, Danny McPherson wrote:
>On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote:
>
>>  Seems that the authors, at least, expect this doc to be prepared for
>>  WGLC, could we do that concluding 11/11/11 please?
>
>
>I've got a couple of comments.
>
>Some high-level bits captured with specific comments below
>include:

This isn't my doc, but I will reply to a few of your points, since 
I've been replying to your comments on the threat model :-).


>2) from a mechanics and processing perspective, this appears to
>largely focus only on external BGP.  It would be useful if the
>requirements considered what behaviors and recommendations are
>applicable to internal BGP speakers as well.

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.

>2) This document seems to allude to a solution that only protects
>NLRI and AS_PATH, and ignores ORIGIN and other attributes.  This
>concerns me a great deal given that most (all?) path selection
>today is largely based on policy derived from and applied based
>upon all those other attributes.

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.

>3) as a WG we need to agree on what constitutes a reasonable
>solution for minimizing an exposure window.  If we're going
>to build such a heavy solution I find it hard to justify new
>hardware and tons of complexity if we can't get the window to
>seconds or minutes, rather than 8+ hours or more best case with
>what we've seen proposed to date, and that's with periodic
>updates (ala beacons) that have the scaling properties of RIP.

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.

Steve