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