Subject: [OPSEC] pccw as17557 leak...

From: Joel Jaeggli <[email-masked]>
Date: Tue, 26 Feb 2008 20:14:06 -0800

Would be an otherwise unremarkable leak of some isp's internal policy 
except for the players.

We have fairly well understood but not widely deployed tools that were 
the used could have precluded some networks from accepting the longer 
prefix...

Are there simple lessons to be taken away from this event?

On the originator side certainly there are safer ways to insert 
blackhole routes into your fib that what was likely done.

joel
_______________________________________________
OPSEC mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/opsec

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 21:34:44 -0800

Hi Joel,

This was certainly a very interesting case of how and why some basic
security is required between consenting peers.

I was eager to know what tools/ filters you thought could be used to
prevent such an exploit.

Thanks,
Vishwas

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

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 27 Feb 2008 12:47:04 +0700

> I was eager to know what tools/ filters you thought could be used to

This problem and the solutions for it are about 15 years old, FYI.

It's ISP BGP 101 - filter the routing advertisements you accept for  
your customers/peers/transits, filter the routing announcements you  
pass to customers/peers/transits, make use of RIRs to build filters,  
et. al.

<http://www.nanog.org/mtg-0706/Presentations/PhilipSmith-BGP.pdf>

<http://www.amazon.com/Practical-BGP-Russ-White/dp/0321127005/ref=sr_1_1?ie=UTF8&s=books&qid=1204090875&sr=8-1 

<http://www.cymru.com/Documents/secure-bgp-template.html>

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // +66.83.266.6344 mobile

      If you don't know what to do, it's harder to do it.

                    -- Malcom Forbes

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 22:29:49 -0800

Hi Roland,

Thanks for the links.

I looked at the document from Philip Smith as well as the last one. I
did not find any way for a route to figure out a peer is actually
advertising a bogus prefix, which it does not own, which is what the
case was with the PCCW leak. Note the real problem is not that the
peer advertised a wrong/ malicious prefix, but that we have no
mechanism to decide the prefix originated is not right. Best practices
for blackholing may help only in the non-malicious case.

I think the ideal solution for that would require a certificate
containing the AS Number and the prefix. Do let me know what is the
exact method you are talking about?

Thanks,
Vishwas

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 27 Feb 2008 13:44:11 +0700

On Feb 27, 2008, at 1:29 PM, Vishwas Manral wrote:

>  Note the real problem is not that the
> mechanism to decide the prefix originated is not right.

You don't accept advertisements from your customers for networks they  
don't own, it's quite simple, in most cases.  You don't advertise  
netblocks you don't own or that your customers don't own; if you set  
up a blackhole for any reason, you don't leak it.  You build your  
filters based on RIR information (keeping in mind that it's incomplete).

> Best practices for blackholing may help only in the non-malicious  
> case.

Many years of experience indicate otherwise.  This isn't theoretical,  
mind; operators who do these things don't end up causing problems of  
this type.  Perusing the NANOG-l archives would probably prove  
educational in this regard.

> containing the AS Number and the prefix.

sBGP, soBGP, the 'PKI problem', see the years of discussions  
surrounding them (lots of conceptual overlap with DNSSEC).

Again, there's about 15 years of history, operational art, BCPs,  
proposals, counterproposals, et. al. surrounding this set of issues.   
It's probably a good idea for anyone evaluating approaches to this  
problem to read up on the history and considerable literature/ 
discussions on this subject prior to engaging in advocacy of a  
particular class of solution.

> Do let me know what is the exact method you are talking about?

There is no one 'exact' method, but, rather, a set of BCPs which, if  
implemented, drastically reduce the risks and impact of a miscue such  
as this one.

                    -- Malcom Forbes

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Feb 2008 08:53:26 +0200 (EET)

> implemented, drastically reduce the risks and impact of a miscue such

I think Vishwas is asking a valid question.  The answer is.. a lot of 
manual work, or in some parts of Europe, IRR-built filters.

This start of the thread and reference to Joe Abley's explanation on 
SIDR list is probably relevant here:

http://www.gossamer-threads.com/lists/nanog/users/103419

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Feb 2008 23:56:52 -0700

> for blackholing may help only in the non-malicious case.

The question isn't about verifying if the peer is advertising a prefix
which it doesn't own, it's about only accepting routes from a peer
if that peer originates or provides transit services for those routes,
implicitly denying all others.

15 years ago this worked like so (very abbreviated):

- I peer with AS X.  AS X announces prefixes a, b & c,
which I discover by interrogating IRR data associated
with AS X as an origin AS.

- AS X's IRR data also includes an as-macro which provides a list of
ASNs for which AS X provides transit services, e.g., AS Y & Z.

- I look up all prefixes registered as originating from AS Y & Z
and find d, e & f.

- I define a prefix list for AS X that permits them to only announce
a, b,c, d, e & f, and explicitly deny everything else.  I also do this
based explicitly on prefix length so that I don't have to accept a
bunch of extraneous prefixes such as more specifics.

> exact method you are talking about?

This didn't need to be in the routing system itself, nor does the  
initial
[re]deployment today.  It can all occur out of band.

Subsequently, SIDR and somewhere WAY down the road, something
akin to soBGP or SBGP could dynamically do this in the routing system
itself, but that's quite a ways away.

See: RIPE-181, RPSL, SIDR

-danny

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 27 Feb 2008 13:59:43 +0700

On Feb 27, 2008, at 1:53 PM, Pekka Savola wrote:

> I think Vishwas is asking a valid question.

I agree, it's certainly a valid question.  The answer is, right now,  
less than ideal and subject to operational inertia/entropy, as you  
indicate, but there *is* an answer.   We need better answers, and  
that's the intention of proposals  like soBGP, etc.

                    -- Malcom Forbes

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 27 Feb 2008 14:00:39 +0700

> See: RIPE-181, RPSL, SIDR

Yes, I forgot SIDR - good point, Danny & Pekka.

                    -- Malcom Forbes

---

From: Ron Bonica <[email-masked]>
Date: Wed, 27 Feb 2008 10:40:41 -0500

Folks,

I think that it would helpful if this working group were to produce a
document (or two) recommending BGP policy for ISP.

                                         Ron

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 Feb 2008 08:49:00 -0700

> document (or two) recommending BGP policy for ISP.

I mentioned to Joel off list, and the GROW chairs, I'm
hacking up a boiler for this now.

-danny

---

From: "Barry Greene (bgreene)" <[email-masked]>
Date: Wed, 27 Feb 2008 07:55:28 -0800

Recommending policy is not the core problem. If you look at the way we
train people at our operations meetings (mainly Phillip Smith's
materials) you will see that we - the community - has been pounding on
prefix filter BCPs over and over again.

So IMHO - being one of the people who has been doing the pounding and
producing the materials - I do see how yet another document will make a
difference. "IETF BCPs" don't mean anything - cause the IETF BCP process
is broken.

What we need is to rethink how we are doing the training at the
operations meetings and how we - as a community - are investing ($$$) in
our open source tools.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Danny McPherson
> Sent: Wednesday, February 27, 2008 7:49 AM
> To: Ron Bonica
> Cc: opsec wg mailing list
> Subject: Re: [OPSEC] pccw as17557 leak...
> 
>

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 Feb 2008 09:03:43 -0700

> difference. "IETF BCPs" don't mean anything - cause the IETF BCP  

I've done a bit of pounding and ISP policy specification at several
ISPs over the years myself, and I believe that the IETF BCP process
sucks less than pretty much any other available option.

-danny

---

From: Gadi Evron <[email-masked]>
Date: Wed, 27 Feb 2008 10:18:18 -0600 (CST)

> sucks less than pretty much any other available option.

As long as Danny is willing to spend the time, I don't see why the effort 
should be discourages. Whatever the result of this being written, I see no 
bad coming of this.

I await the initial fruits of his work.

 	Gadi.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 27 Feb 2008 13:45:43 -0800

> operations meetings and how we - as a community - are investing ($$$) in

So, I do some training, in workshops, sometimes with Phil and sometimes 
with other crews and I think in that context that bcp's are a useful 
framework to hang instructional material on. They aren't a panacea by 
any means. We might consider re-exporting the sort of training we do in 
nogs in emerging markets back to north america and europe, but frankly 
there's a lot more people to train here and I think the market needs to 
drive that otherwise we won't come close to reaching enough operators...

I think collectively we're in a rather unique position to:

A. produce documents which are cogent and useful

B. drive that into instructional materials that get used in network 
operator trainings.

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 17:12:49 -0800

Hi folks,

I looked at the SIDR documents in brief. It can probably be used to
help prevent any attacks caused due to non-malicious intent.

I found easy ways to get over the SIDR security when done with a
malicious intent. SIDR just tells the mapping between AFI, AF and AS
number which can originate the same. However the choosing of a route
by BGP does not depend on these fields alone. So if a malicious router
changed the attributes attached to an NLRI update so that it becomes
the chosen AS to the prefix (of course without changing the
originating AS field). It can still redirect all the traffic to itself
for the prefix and then do whatever malicious it wants to do,
including just drop the packet.

In this way still achieving the attack, but this time for sure with
malicious intent.

Thanks,
Vishwas

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 10:12:05 +0700

On Feb 28, 2008, at 10:07 AM, Stephen Kent wrote:

> I think the SIDR WG participants understand that.

Yes, they do.

                    -- Malcom Forbes

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 19:13:52 -0800

Hi Steve,

Thanks a lot for the comments. I agree it can be a good first step but
not sure what the future holds.

I am not sure if a heavy solution like this is required which only
gives reasonable security. What about the CPU DoS attacks that can be
result when new random routes are injected into a domain.

Thanks again,
Vishwas

On Wed, Feb 27, 2008 at 7:07 PM, Stephen Kent <[email-masked]> wrote:
> At 5:12 PM -0800 2/27/08, Vishwas Manral wrote:
>  >Hi folks,
>  >
>  Your example of how an AS can tamper with a route, without changing
>  the origin AS assertion is correct. I think the SIDR WG participants
>  understand that.
>  The work so far i SIDR focuses on establishing an infrastructure that
>  will enable more comprehensive routing security capabilities in the
>  future.  Both the soBGP and SBGP proposal need this sort of
>  infrastructure, so it is viewed as a reasonable initial effort.
>
>  I also agree with your observation that the infrastructure makes it
>  potentially easier to distinguish between some forms of attacks vs.
>  accidental routing errors, and that, in itself, seems valuable too.
>
>  Steve
>

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 10:18:25 +0700

On Feb 28, 2008, at 10:13 AM, Vishwas Manral wrote:

> What about the CPU DoS attacks that can be result when new random  
> routes are injected into a domain.

This is a different set of issues handled via different mechanisms,  
some of which exist today in routers from various vendors, and which  
are implemented by operators.  We have to limit the scope, or we'll  
never get anything done, heh.

                    -- Malcom Forbes

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 20:05:38 -0800

Hi Roland,

I looked at soBGP and it is also just checking the origin. The origin
is not of much use in a malicious router case at all.

I have another similar solution, but may help in more than just non
malicious case.

Thanks,
Vishwas

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 11:14:15 +0700

> is not of much use in a malicious router case at all.

I'm aware of that, Vishwas.  And as I indicated, that's a different  
problem.

There is a lot of history and operational art in this arena - we  
aren't all just sitting around waiting for security clue to fall from  
the sky, heh.  I strongly recommend acquainting oneself with the full  
scope of the issues as well as the history of discussions and  
initiatives, so as to avoid re-discussing the invention of the wheel.

;>

A good place to start is the latest ref of the opsec draft.

                    -- Malcom Forbes

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 20:31:16 -0800

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

On Wed, Feb 27, 2008 at 8:13 PM, Stephen Kent <[email-masked]> wrote:
> At 7:13 PM -0800 2/27/08, Vishwas Manral wrote:
>  >Hi Steve,
>  >
>  Vishwas,
>  The current SIDR plans for use of this infrastructure calls for ISPs
>  to download the certs, CRLs, ROAs, etc. on a daily basis, to process
>  them offline, and to use the results in constructing route filters.
>  Even the more comprehensive models offered by SBGP and soBGP did not
>  require routers to process certs, CRLs, etc., i.e., they assume
>  offline processing to verify signed objects and pass the results to
>  routers to use in route verification.
>
>  Give this background, I don't know what sort of CPU DoS attacks you
>  are worried about.  Could you provide some additional context?
>
>  Steve
>

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 11:33:46 +0700

On Feb 28, 2008, at 11:31 AM, Vishwas Manral wrote:

>  If we do things

You are correct - certs and sigs and PSKs and PKI and encryption and  
so forth aren't free, and the numerous people who have been looking at  
this problem-set for a long time are very aware of these issues, FYI.

;>

                    -- Malcom Forbes

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 20:37:48 -0800

Hi Roland,

I looked at the 3 drafts in the OPSEC group (for one of which I am the
coauthor). I could not find any draft referring to BGP.

Could you let me know which draft you refer to?

Thanks,
Vishwas

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 11:50:52 +0700

> Could you let me know which draft you refer to?

I'm not just referring to BGP specifically, but rather to the classes  
of problems you seem to think that nobody else is aware of or  
understands, but which in fact are well-understood by the operational  
community and have been for some time, heh.

Here are some examples:

<http://tools.ietf.org/html/rfc4778>

<http://tools.ietf.org/html/draft-ietf-opsec-infrastructure-security-01>

<http://tools.ietf.org/html/draft-ietf-opsec-routing-capabilities-03>

draft-ietf-opsec-filter-caps, of which you're a co-author, is yet  
another example.

As Paul Ferguson indicated, these issues have been discussed on nanog- 
l and on various vendor-focused operational lists, as well.

                    -- Malcom Forbes

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 20:57:33 -0800

Hi Roland,

I may be wrong but I think you may have missed the context.

The point I raise is that with the SIDR infrastructure we get a way to
catch some attacks, but a malicious attack still cannot be prevent,
while having an overhead. The point I raise is is the trade-off
between what we achieve versus the CPU overload a good one. You seem
to refer to some generic documents.

Thanks,
Vishwas

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 12:09:17 +0700

On Feb 28, 2008, at 11:57 AM, Vishwas Manral wrote:

> while having an overhead.

The point I raise is that everyone here understands that already.

> The point I raise is is the trade-off between what we achieve versus  
> the CPU overload a good one.

Again, I raise the point that everyone here understands that already,  
and, furthermore, that the point you raise regarding CPU spikes due to  
a flood of routing advertisements, etc., are well-understood by the  
operational community and are in fact addressed at least in part by  
existing features implemented in existing devices manufactured by  
various vendors and installed on operational networks.

Whether or not operators make use of these features and techniques is  
another question, of course.

> You seem to refer to some generic documents.

Yes, in order to demonstrate that there is a long history of discourse  
in this arena, and that it isn't necessarily very productive to make  
the assumption that the participants in this WG are ignorant of the  
various classes of problems which must be addressed,.  Also,  
advocating particular solutions or classes of solutions in absence of  
familiarity with the long history and current BCPs surrounding a given  
problem-set isn't necessarily very productive, either.

                    -- Malcom Forbes

---

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:
>
>
> At 8:31 PM -0800 2/27/08, Vishwas Manral wrote:
> Hi Stephen,
>
> 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: Roland Dobbins <[email-masked]>
Date: Thu, 28 Feb 2008 21:51:35 +0700

[removing cross-post to [email-masked]; cross-posting is considered  
poor form, FYI]

On Feb 28, 2008, at 9:49 PM, Vishwas Manral wrote:

> is it not possible to actually use a

So far, the empirical evidence seems to suggest, "No", unfortunately.

                    -- Malcom Forbes

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Feb 2008 10:11:43 -0500

[I've dropped the cross-post to sidr, since people there know what  
their work is about. I seem to think there's some lack of familiarity  
in some corners of opsec, though.]

> simpler mechanism to get over such errors?

Right now, if I am a new customer of an ISP and I want to announce a  
route, I send a bunch of supporting documentation such as:

  - pasted text from whois servers
  - faxed declarations on letterheads
  - PGP signatures for which no trusted key can easily be found
  - personal requests for favours from people I have drunk beer with  
at NANOG

Sooner or later, I hope that the ISP will update their prefix filters  
and accept the filter.

You can think of the SIDR work as an attempt to make the process  
outlined above more accurate and automatable (and hence quicker and  
better).

It would be a mistake to think that the SIDR work aims to solve  
routing security; the actual problem space it seeks to address is much  
smaller. If we could be certain that every route origination was made  
through an up-to-date filter built through the kind of accurate  
framework that SIDR proposes we might consider it to be some kind of  
panacea, but I think we're all aware that this is not the kind of  
Internet we live in.

Geoff described the use cases together with details of the  
certification chain in a NANOG presentation some time ago. See <http://www.potaroo.net/presentations/2006-10-07-certs.pdf 
 >.

Joe

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 28 Feb 2008 08:01:13 -0800

Hi Joe,

Note: I think Stephen cross posted because he thought it was of
interest to the SIDR list too.

May be it is well known in the SIDR community, but I do not see the
same in the charter. Then again I do not visit NANOG or drink beer.
:))

The charter seems to talk of it in the security architecture and not
just an automation mechanism of adding filters, which is what you seem
to say it is. Have a look at below:

Also if it is only between the first EBGP peer, the model can be
considerably simplified by doing the verification of the origination
at the EBGP peer and not the entire Internet. So a mechanism of
actually verifying a prefix/ AS mapping with a central authority will
be a better mechanism.

Thanks,
Vishwas

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Feb 2008 11:03:28 -0500

> to say it is. Have a look at below:

It's quite possible I'm speaking about just one element of the SIDR  
work (that of resource certification) and that I should not generalise  
about the efforts of the wg as a whole.

> actually verifying a prefix/ AS mapping with a central authority will

Verifying a prefix/AS mapping with a central authority (via chained  
certificates) is what the work I was talking about is intended to  
facilitate.

Joe

---

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

On Thu, Feb 28, 2008 at 8:34 AM, Sandra Murphy <[email-masked]> wrote:
>
>
>  On Thu, 28 Feb 2008, Vishwas Manral wrote:
>
>  > Hi Stephen,
>  >
>
>  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 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

On Thu, Feb 28, 2008 at 10:13 AM, Sandra Murphy <[email-masked]> wrote:
>  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: "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 11:34:48 -0500 (Eastern Standard Time)

--Sandy

---

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 13:13:27 -0500 (Eastern Standard Time)

--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: 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: Stephen Kent <[email-masked]>
Date: Wed, 27 Feb 2008 22:07:15 -0500

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Feb 2008 23:13:24 -0500

Vishwas,

Steve

---

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

>like rate limiting we can still have an attacks, or cause delays in

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