Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Feb 2008 06:35:20 -0500

At 8:31 PM -0800 2/27/08, Vishwas Manral wrote:
>Hi Stephen,
>
>The point I raise is that there is a cost associated with this, using
>certificates has a CPU cost associated with it.
>
>I may be missing the point but even if you leave aside the cost of an
>off line server to do this check but if the checks are done on each
>new prefix we can still overload the off line server. If we do things
>like rate limiting we can still have an attacks, or cause delays in
>the convergence times.
>
>Thanks,
>Vishwas

I think you are missing the point. So long as the processing is done 
as an offline operation, not as a gating item in routing, it does not 
strike me as a DoS concern. The initial use of the infrastructure is 
analogous to downloading IRR databases and processing the RPSL 
assertions, an operation many ISPs perform today on a daily basis.

More to the point, folks have implemented the necessary software and 
tested it with about 20K certs and CRLs and 10K ROAs, a reasonable 
starting point. I don't have the precise figures in front of me now, 
but I believe their results show that the time to do all the 
processing (on a laptop) is about 20-30 minutes, and the time is 
dominated by the retrieval of the data from online repositories, not 
by the crypto operations per se. For a once daily, offline 
operations, this seems quite reasonable.

Steve

_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 28 Feb 2008 06:49:04 -0800

Hi Stephen,

Ok, I understand the model you talk about now. Yes the CPU may not be
the biggest concern as the server is verifying the Cert's offline. I
guess this would also lead to models like CRL's for revocation.

Like I said earlier as SIDR does not stop malicious attacks, but only
ones caused unintentionally, is it not possible to actually use a
simpler mechanism to get over such errors?

Thanks,
Vishwas

On Thu, Feb 28, 2008 at 3:35 AM, Stephen Kent <[email-masked]> wrote:
> I think you are missing the point. So long as the processing is done as an
> offline operation, not as a gating item in routing, it does not strike me as
> a DoS concern. The initial use of the infrastructure is analogous to
> downloading IRR databases and processing the RPSL assertions, an operation
> many ISPs perform today on a daily basis.
>
>
> More to the point, folks have implemented the necessary software and tested
> it with about 20K certs and CRLs and 10K ROAs, a reasonable starting point.
> I don't have the precise figures in front of me now, but I believe their
> results show that the time to do all the processing (on a laptop) is about
> 20-30 minutes, and the time is dominated by the retrieval of the data from
> online repositories, not by the crypto operations per se. For a once daily,
> offline operations, this seems quite reasonable.
>
>
> Steve

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Feb 2008 11:34:48 -0500 (Eastern Standard Time)

> simpler mechanism to get over such errors?

Vishwas, the current SIDR work is focused on preventing attacks 
(faulty/misconfigured/subverted/malicious/whatever) against the 
origination of routing advertisements, by providing strong assurance of 
who holds what prefixes, and therefore who can authorize origination of 
a prefix.

(And in the leak that is the subject of this email chain, the fully 
deployed system would indeed have detected the mis-origination, in any AS 
that had received the mis-origination, not just the direct link up from 
the customer.)

The concerns you raise are recognized subjects for further work.

But all of the very many proposals for securing BGP (see: S-BGP, soBGP, 
psBGP, SPV, etc., etc.) rely on protecting this initial bit of routing 
information: originating a route to a prefix.  So defining this work is a 
basis for defining future fuller protection techniques as well.

All simpler mechanisms I have ever heard of for protecting origination of 
routing advertisements are either much lower assurance, or based on data 
with similar strong protections but not more assurance, or not extensible 
to protecting more features of BGP exchanges.

--Sandy

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 28 Feb 2008 09:56:23 -0800

Hi Sandra,

Thanks for the reply. You put forward the all the points correctly and
precisely.

My concern is that, unlike the normal PKI model where the final output
is to authenticate the user using the just the certificate, the
Routing based model we are now talking about verifying just a small
bit of information which is used for the BGP Best Path selection - the
sanity of which we are trying to protect, and protecting just the
Origin does not make sense in a malicious case at all. Though you may
say that it protects in case the malicious person plays with the
Origin attribute, it however does not protect much as with the same
amount of effort a malicious person can still cause the same attacks.
What increases is the over head in each of the domains to maintain the
new PKI information.

After reading a bit through what Pekka/ Danny/ Joe Abely said away in
which we could update the filters between peers automatically(only
relating to routes originated by the peer), from the RIR, we may
achieve the very same functionality.

Thanks,
Vishwas

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Feb 2008 13:13:27 -0500 (Eastern Standard Time)

> achieve the very same functionality.

Generating filters from IRR (not RIR, a point it took me a while to learn) 
data is indeed similar, with the following differences:

(a) Security (authenticity, integrity and authorization) of IRR data 
varies widely among IRR's.  And there are quite a few IRRs.

(b) Even those IRRs associated with RIRs can protect authn/int/authr of 
only that data that comes from their own members.

(c) RIPE uses the strongest security model among the many IRRs, but their 
system relies on protection of the communication with the user (and the 
protection varies from user to user) and the protection of communication 
to the person accessing the data.  The protection is not stored with the 
data, so the reader must rely on the IRR to get it right.  I don't think 
the reader can tell what protection was used to put the data in there, so 
there's no way for the reader to judge the assurance in the data.

(d) This is not a mechanism that could extent to protection of the other 
BGP features that you have mentioned.  So if/when we decide to work on 
those features, we'd have to start over with the system we are building 
now anyway.

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Feb 2008 13:34:49 -0500 (Eastern Standard Time)

> What increases is the over head in each of the domains to maintain the

(Yes, I know I already replied to this message, but to a different point 
and I wanted to keep them separate.)

When I say origination of route advertisements, I am not talking about the 
ORIGIN attribute in the BGP Update.

I am talking about an ISP that creates a BGP Update that has an AS_PATH 
containing only its AS number.  That is the point at which a route is 
first advertised into the BGP system.  I'm talking about an action, not a 
protocol field.

It is indeed possible for a route to modify attributes other than the 
AS_PATH.  But many of those (local preference, community strings, etc) 
have only local significance.  And as we have seen, bogus AS_PATHs have a 
whole lot of impact.

--Sandy

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 28 Feb 2008 10:56:58 -0800

Hi Sandra,

Thanks again for the information in both the mails. I got to read the
differences between the RIR and the IRR. I also agree to the fact that
in case we have some mechanism which can verify all the attributes of
a route, then such a certificate which does this would be helpful, and
then the infrastructure you talk about would be helpful too.

I understand the fact that we are talking about a NLRI and the AS
element in the AS_PATH. I still look very interestingly at differences
we have between AS_SEQUENCE and AS_SET (if we are to verify an update
more than one hop away which element in the AS-SET to verify it
against - not much difference though if we have only one AS number in
the AS_PATH).

The only point I want to add to the discussion is because we have to
verify the Origin only in the first hop peer, we do not need a global
database (as I mentioned we are not saving against malicious attacks
in any case).

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 28 Feb 2008 11:02:31 -0800

Hi Sandra,

To further clarify,
>  database (as I mentioned we are not saving against malicious attacks
This would mean for someone who gets the information from RIPE does
not need to necessarily use the mechanism the way it currently stands.

Thanks,
Vishwas

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Feb 2008 15:03:12 -0500 (Eastern Standard Time)

> against - not much difference though if we have only one AS number in

You are right that we have not considered how you validate an AS_PATH 
where the origination is an AS_SET.  That has been looked at before, and 
it is complicated and the possibilities of providing some protection 
aren't good, even on the theoretical level.  Keep in mind that the number 
of BGP Updates that contain AS_SET anywhere in the AS_PATH are a tiny, 
tiny, percentage (one figure I saw recently was 10K out of a base of 91M 
updates - .01%).  As a wg, we decided not to work on this right now.

> database (as I mentioned we are not saving against malicious attacks

As long as *every* first hop peer does the appropriate strong 
verification, you would be good.

But this system allows ASs beyond the first hop to verify the origination 
of the route.  So, for example, UUNET could have verified the 
announcements it saw from PCCW even if PCCW did no check and propogated 
the bogus announcement.

(As "Origin" is a BGP attribute with a different semantics, perhaps we 
should avoid using that term in this context to avoid confusion.)

And, finally, yes we *are* protecting against malicious attacks (as well 
as accidental attacks) on those features we *are* intending to protect. 
No, we are not protecting against malicious attacks (or accidental 
attacks) on features we are *not* intending to protect.  The difference is 
not malicious vs accidental, the difference is scope of protection.

You think we haven't gone far enough, I'm saying what we're building is 
the basis for any further protection.

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Feb 2008 16:12:13 -0500 (Eastern Standard Time)

> not need to necessarily use the mechanism the way it currently stands.

As long as:

(a) you were interested in protecting only those prefixes that are managed 
by RIPE - data in RIPE about other prefixes doesn't fall under the 
protection of their security model, and the RIPE database does not 
contain all prefixes,

and

(b) you were comfortable with the trust model of RIPE (they authenticate 
the upload of the data with varying strength of authentication and you 
must get the data, whose aussurance you can not yourself verify, from them 
and only them with a protected transport they support).

As an additional wrinkle, I believe that RIPE does allocate prefixes to 
LIRs.  I do not know if the LIRs are required to maintain the RIPE 
security model in their allocations.

--Sandy

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 28 Feb 2008 11:02:31 -0800

Hi Sandra,

To further clarify,

Thanks,
Vishwas

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr