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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
