> 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?
> 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. 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. 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.
>>---
>>"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.
>>---
>>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 ?).
> 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.
> 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?
And it's most certainly a threat and one that some consider
out of scope at that?
> I think the motivation and capabilities discussion justifies the
> distinctions between these classes of adversaries. The term
> "attacker" is generic and not useful as an adversary
> characterization.
Contextual use "attacker" is more generic than "hacker"? Umm,
ok, I'm not attached to either..
>
>>---
>>S 4.3:
>>
>>"This type of behavior cannot be externally detected as an attack."
>>
>>/cannot/may not/
>
> 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 :-)
>>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 disagree. First, note that certs expire, but CRLs are defined as
> stale when the next issue date passes. Manifests are defined as
> stale when the bundled EE cert is expired. Other signed objects that
> have bundled EE certs expire with their certs. In the absence of
> current, valid objects,
OK, see above.. Going through all this effort, and then using
"expired data" just seems dirty and opens up a bunch of ugliness
to me...
>>---
>>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.
>
> 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.
As usual, thanks for the thoughtful responses Steve. I really am trying
to come to grips with what's being proposed, but I'm just not there on the
cost/benefit analysis at the moment.
-danny
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
