At 10:29 PM -0400 11/2/11, Danny McPherson wrote:
On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote:
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.
Duly noted, and my disagreement stands:
To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or
benign, that is not an authorized transit for a given prefix is out of scope
because it is not a "semantics violation" does not mitigate what I perceive
as a very significant risk to my operations.
Absent a companion set of mechanisms and controls under cover of "BGPSEC"
to mitigate that risk, I'm opposed to the publication of this
document under the
auspices of "Threat Model for BGP Path Security". I.e., it is not
an acceptable
residual risk.
Having been motived to reread the SIDR charter by Brian's message,
there is a simple answer to the in/out of scope question, but it's
one you will not like :-). The charter for SIDR states that the
secruity goals for the WG are to address two vulnerabilities:
authorization for prefix origination and path validation. Relative
to the charter, route leaks are out of scope. I will add text to the
intro for the threat model to state that the scope of the model is
defined by the charter, and include the relevant charter text. I hope
you'll forgive me for taking the easy path here.
yes, one can use RPSL to express more info, but these are just assertions
by the maintainers of RPSL objects.
But if these maintainers are the resource holders that are authorized via the
RPKI, then they are no more assertions than an RIR's RPKI testimony about
their resource holdings is an assertion.
I'm not sure I understand the sentence above. RPKI CAs issue certs
based on authoritative databases about Internet resources. The
authorized holder of a resource can make lots of assertions, and the
RPKI allows us to attribute these assertions to that entity. RPSL
allows lots of assertions to be made, and many of them cannot be
validated relative to the RPKI. Relying on such assertions, just
because their sigs can be validated under the RPKI is a new sort of
vulnerability that we ought not enable.
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.
Ahh, and the crux - then perhaps this needs to be corrected, rather than
accepting this residual risk?
see comment above.
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.
"Some types" is relative, and I understand and agree with that. Tell me
how to get there?
Get where?
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.
If it were cryptographically protected by the origin AS then it couldn't be
manipulated by intermediate ASes for the purpose of traffic attraction
attacks - as it commonly is today. As discussed above, ORIGIN code was
simply an example of why the laser focus only on the AS_PATH Path
Attributes may be problematic in practice.
I agree that the integrity that would result from including this
attribute under the sig applied by the first AS would provide the
secruity you cited. That may make it worthwhile to protect via the
sig. However, the accuracy of the assertion being made by this
attribute is unverifiable by any of the ASes along the path, and that
was what worried me. But, again, the charter makes this out of
scope, i.e., it is not relevant to the origin authorization or path
accuracy vulnerabilities cited there.
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.
If an origin AS for which a ROA is associated in the current system signs
those transitive attributes then what more do you need?
That sig provides integrity, which is valuable, but it does not
provide a way to verify the accuracy of the assertion by the origin
AS. Your concern is that an AS along the route can change the value
of the attribute. One might also be concerned that the origin set the
value incorrectly. Ultimately, I think this is a bad example for us
to argue about, as it is a vestigial part of BGP, from EGP days, that
is the penultimate basis for route decisions.
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.
I agree NO_EXPORT is not the right answer, I never even considered it.
I'm saying policy is a big part of the problem, at least as considerable as
"integrity" of the AS_PATH, IMO, and if we don't take a systemic approach
and consider the gaps that exist, then it's hard for me to justify the
investment.
I'm not sure what you're trying to say about policy here. Can you elaborate.
But it "may" be externally detectable, which was my point that
you've reinforced :-)
"May" is not a suitable basis for a secruity protocol :-).
The possibly exists that it many cases it can be detected, therefore, "cannot"
is false.
OK, "cannot" was too strong. But, I still feel that "may" is a bad
basis for a security protocol.
I can add text to note that use of cached data enables some types
of attacks resulting from use of stale data.
I think the text we need here, if you truly believe this is the right course,
is to clearly state that expired digital certificate data is acceptable. As a
basis for a security architecture, this assumption seems a residual risk I
would prefer to mitigate.
It is up to each RP to decide whether to rely on assertions made by
an expired cert, or to act as though the cert does not exist. In the
routing context, there appears to be some agreement that relying on
expired certs is more desirable
than treating the resources as not certified. But, this is a per-RP decision.
For example, do you consider it acceptable to use expired certs when
you connect to a web site via SSL or VPN to some remote location? I
don't.
Many folks do. This is probably because an expired cert often indicates that
the cert holder was sloppy, and failed to renew the cert, i.e., pay
the CA. Expiration is not as negative an indication as revocation.
Furthermore, besides the obvious attacks you're accepting by recommending
use of expired certificates, aren't revoked certificates
only supposed to remain
in the CRL until their validity period has expired? How in the
heck can we justify
use of expired certificates in the absence of current data, when some of those
expired certificates may have even been revoked?
There is a subtly here, and thanks for pointing it out. The idea is
that if an RP has a cert, and it was not revoked, then the RP can
continue to rely on it, after the cert expires, if the RP is unable
to acquire fresh data from the pub point for that cert. If the cert
had been revoked, it should not be un-revoked because it expired.
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.
And that is exactly my point, I don't know the difference between them
and therefore using them opens me up to attack and undermines the entire
system.
I think the phrase "undermines the entire system" is melodramatic.
How about "you actual assurance may vary?" :-)
Also, if RPKI weren't so distributed, or if we could develop a
model, perhaps some
OSCP-esque near realtime function would be of benefit here, in the
general case,
and perhaps even some notify function from publication points/CAs
for RPs to identify
revoked certificates, such that a RP, or even BGPSEC speakers, could
be notified of
an incident with a particular resource, rather than periodically
telling everyone
everything via a periodic update/refresh mechanism?
What are your thoughts on this?
I would prefer more centralization of RPKI data. My original model
called for each RIR to aggregate the data for every member, and act
as a mirror for the data for every other RIR. But other folks wanted
greater distribution. One can argue that wider distribution may offer
potentially greater resilience, so ...
OCSP is an optimization of the CRL mechanism, designed to efficiently
answer a revocation status query for a single cert. Since every RP
needs to know the revocation status of every cert, OCSP (or an
analogous mechanism) does not seem to be a good match. For many
years folks have thought that very fast dissemination of revocation
status data was important for PKIs. In reality, revocation is an
administrative procedure for which the major delays will be
created by people deciding whether to revoke a cert, vs. the time it
takes to disseminate the CRL.
There are two types of certs: CA certs and EE certs.
Because revoking a CA cert has major implications, so such a decision
will not be taken lightly. Thus I expect relatively few revocations
of CA certs and the principle delay will be procedural.
All of the EE certs defined so far (not counting router certs for
BGPSEC, which have yet to be agreed upon) are embedded in RPKI
objects: manifests, ROAs, and GB records.
A new manifest MUST be published whenever any file at a pub point
changes. The CPS template recommends daily CRL issuance, and that
seems to be what the RIRs are doing for the pub points that they
maintain . Thus it is likely that a new manifest will be issued every
day. So, I doubt that many manifest cert will be revoked.
The GB record is likely to be very stable, as it provides contact
info for the pub point maintainer. I don't see freshness attacks on
these records as a big deal.
A ROA expresses a binding between a prefix and an ASN. I would expect
most of these to be fairly stable, and that operators would follow a
make-before-break policy. That suggests that ROA cert revocation will
be relatively infrequent, and will not require immediate
dissemination.
So, I am not convinced that there is a need for a different approach
to disseminating revocation status.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
