At 3:27 PM -0400 11/1/11, Danny McPherson wrote:
> Route leaks represent a violation of an ISPs local policy, i.e., the ISP
is propagating routes that it, locally, did not intend to propagate.
Perhaps the network operator DID fully intend to propagate ("leak") those
routes in order to hijack and MITM traffic? Any multi-homed customer can
launch such an attack today of this sort, and as a matter of fact, it
happens all the time, for benign or malicious purposes.
To say that this is not a "semantics violation" and therefore in scope
does not mitigate the risk. How that risk can be considered as a
"Residual Risk" in a "Threat Model for BGP Path Security" document totally
escapes me?
I interpret the task at hand as trying to secure BGP, not a new EGP.
Since BGP semantics (and syntax) do not provide a basis for deciding
when an advertisement constitutes a route leak, I think it reasonable
that the BGPSEC threat model view this as out of scope. If BGP were
modified to express semantics we're discussing, then it would be in
scope, and I would expect BGPSEC to address it.
BGPSEC (or any analogous technology) can provide protection for BGP
relative to two constraints:
- the semantics of BGP have to align with the protection
- the underlying PKI has to align with the protection
Thus, for example, other attributes carried by BGP and for which the
resource allocation system has no reference, cannot be protected.
Similarly, route leaks, because they are a violation of a local policy,
which is not expressed in BGP Update messages, cannot be addressed.
But they are certainly still risks, whether the proposals at
hand can mitigate them or not is orthogonal.
The threat model is based on using the RPKI as the starting point.
I will add text that clearly articulates that.
And even policy
expressed in IRRs and via RPSL can result in controls that can
be put in place to mitigate various aspects of those risk.
yes, one can use RPSL to express more info, but these are just
assertions by the
maintainers of RPSL objects. For some of this data, there is no basis
for validating it via external, authoritative sources. That makes
such data a poor
basis for security controls.
I
don't understand how we can ignore this as an objective here,
and we certainly cannot discard it so casually as a trivial
residual threat. If some non-obvious or undisclosed roadmap
exists to solve this piece then I'm truly anxious to see it -
else it would seem to me secure IRRs bootstrapped by resource
certification data and perhaps even deployed to routers via some
rpki-rtr-esque protocol would provide a lot better protection
with a lot less overhead.
We disagree about the advisability of relying on some types of IRR
data, e.g., an assertion that AS X will advertise (not originate)
routes for prefix Z.
>>"False Origination" should probably be "network operator", not
>>ISP, in particular given the subsequent definition of ISP.
please explain.
You use ISP in this draft as if they're the only ones who
may be multi-homed or trigger leaks or other functions, "network
operator" is much more broadly applicable and well beyond "ISP"
in the traditional sense.
OK; I have changed all instances of ISP to network operator.
>>---
The definition of "Route" seems to be missing the full set of
path attributes associated with the NLRI, it currently only
focuses on the AS_PATH attribute, and even omits the ORIGIN
code of the path.
I think the definition does not omit the origin AS, but I will
clarify the text.
I'm not talking about Origin AS, I'm talking about "ORIGIN Type
Code" Path Attribute (i.e., i, e, or ?).
Sorry, I misunderstood your question. Now I know the data item to
which you were referring. I checked with a network operator here at
the RIPE meetings, to understand how/why it is used. I now believe
that the ORIGIN attribute is a poster boy for an attribute that is
unsuitable for inter-AS protection. This attribute can be set to one
of 3 values by an AS sending an Update. (One of these values cites
EGP as the source of the data, so unless the Update has been terribly
delayed, this is not a credible value :-).) The other two values are
IGP and INCOMPLETE (i.e., mystery). How would an AS that sees this
value externally verify that the value is accurate? I am unable to
imagine how this would work.
> Our context assumes use of the RPKI, and the RPKI attests to only
prefix and ASN holdings of entities, hence the focus on these
attributes. For example, MPLS attributes are not supported in the
RPKI, so they are out of scope here.
I think the "Threat Model" document should give consideration
to Path Attributes beyond just AS_PATH, particularly because most
are used in path selection. If we think we don't need to protect
these because they are not in RPKI, then we should consider what
that means rather than assume RPKI contains the information for
all that we need to protect.
Let me try again. If we can't identify a suitable, authoritative
source of data that could be used to verify an assertion about an
attribute in an Update, that attribute is not a candidate for
inter-AS security mechanisms.
> The definition I used here has been widely used for many years
in contexts where folks understand the importance of
distinguishing among attacks, adversaries, and motivations.
Unlike the RPKI focus on config errors, BGPSEC focuses on attacks.
As noted in above, route leaks are out of scope, because they
> do not represent violations of BGP semantics, as expressed
externally.
If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a
transit customer of both, and then decides (or is compromised
and used to decide) that he wants to hijack traffic from ISP_1
towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2
Prefix_P to ISP_1 through Enterprise_E's local interconnect,
and "policy" makes it a more preferred path, how is this not
an attack?
How does BGP indicate (i.e., where are the bits that say) that the
Update sent to E is not to be propagated to another ISP? I've been
told that the NO_EXPORT community does not have the right semantics,
and that network operators do not pay attention to this anyway.
And it's most certainly a threat and one that some consider
out of scope at that?
I presume that you mean in scope, right?
...
>
I said "cannot" here because of the modifier "externally." To external
observers, such behavior by an ISP may be viewed as odd behavior, but
enough ISPs behave oddly enough to make this indistinguishable from
an attack.
But it "may" be externally detectable, which was my point that
you've reinforced :-)
"May" is not a suitable basis for a secruity protocol :-).
>>Such guidance and implementation may be precisely what an attacker
was hoping to instigate, no? Further:
The RPKI and BGPSEC designs place a high priority on maintaining
the ability of ISPs to continue routing in the face of outages. Using
cached, previously validated RPKI data is a good way to support this
goal, in the face of outages, benign or malicious. So, I think we are
making an appropriate decision here. An attacker can always try to
effect DoS on targeted RPs, and has has fewer attack options when RPs
can revert to cached data.
While I agree, this can enable downgrade or other attacks, no?
Just like clicking on that self-signed or expired intermediate
CA certificate warning in a web browser, right? If so, the threat
model should indicate as such.
I can add text to note that use of cached data enables some types of
attacks resulting from use of stale data.
>>---
I'm surprised I don't see anything here about timing dependencies
between RPKI and BGPSEC routers, and variances across a BGPSEC system
having considerable potential impacts. I think some discussion of
this is in order in a threats draft.
There is no requirement that a BGPSEC router interact directly with
the RPKI repository system. However, your question is still relevant
if we substitute
"local RPKI server" for "BGPSEC router." S 4.4 already deals with
attacks against publication points, many of which are relevant to the
timing concerns you cite above. The RPKI, is a distributed repository
system with many maintainers. RPs ought not assume that they always
have the very latest data from the system, and maintainers ought not
assume that all RPs have the latest data. This issue is addressed in
> detail in the RPKI key rollover doc.
But it's a threat and this is the threat document, right? If
we're not going to include it here we should at least reference
those sections.
I can add text that notes the implications for RPs of using any distributed
repository system with data supplied by object owners.
> Section 5 already addresses this, at a high level, see bold text:
>
- the RPKI repository system may be attacked in ways that make
its contents unavailable, or not current. It is anticipated that
RPs will cope with this vulnerability through local caching of
repository data, and through local settings that tolerate
expired or stale repository data.
I have changed this to say
contents unavailable, not current current, or inconsistent.
Not current == expired. I'll defer to crypto types here, but as
a first order function, I would like to see explicit text and reach
agreement that expired data should be used in the absence of current
data, and what the attack surface implications of using expired data
are.
In PKIs it is always the case that, in the absence of the current
CRL, use the old one. This is because, with one ugly exception, once
you are revoked, you are revoked, you stay revoked. So, expired and
stale are meaningful differences to us PKI experts. But, I agree that
more text can be added to note the vulnerabilities associated with
using stale or expired PKI data.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
