Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00

From: [email-masked]
Date: Mon, 4 Nov 2002 16:44:13 -0500 (EST)

>However, I think it is unnecessary to protect against "evil" ISPs since
>they only get to do this once before they're disconnected and an ISP in
>their right mind wouldn't do this.

(A) There have been numerous occasions where ISP's have done this and
    they have not been disconnected.
(B) To speak for the paranoid:  a routing system that knew that it was
    vulnerable to one faulty/misconfigured/subverted/evil ISP should
    not rely on self-interest of such ISP's to protect the world-wide net.

--Sandy
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Nov 2002 23:02:59 +0100 (CET)

>     they have not been disconnected.

Then obviously not disconnecting yielded a better result than
disconnecting.

>     not rely on self-interest of such ISP's to protect the world-wide net.

Routers need better management in order to be able to filter very large
numbers of routes, I'm all for that.

However, some basic assumption of good will between ISPs is reasonable.

We can do better things with our time than thinking up protocols to
protect us against attacks that 1. we can't really protect ourselves
against and 2. aren't going to happen anyway. BGP misconfiguration and
DoS attacks against the root nameservers ARE happening, so let's focus
on that kind of stuff.

---

From: Tony Tauber <[email-masked]>
Date: Mon, 4 Nov 2002 17:32:55 -0500 (EST)

> against and 2. aren't going to happen anyway. BGP misconfiguration
> and DoS attacks against the root nameservers ARE happening, so let's
> focus on that kind of stuff.

The goal of the WG is to give better security guidance to routing
protocol designers (and implementers), not to solve all problems of
the operational Internet much less world hunger.

The sincere hope is that this effort will not result in a huge
drain on the collective brainpower of the IETF nor will it take eons
to complete.

Let's focus on the actual threat-modeling drafts at hand
(beard, murphy, and convery).  In the convery draft ("Attack Tree"),
what if we think more about the generic approach than the specific
threats against BGP?  That would get this WG closer to its first goal
which the charter tells us is:

- Document threat models for routing systems

In other words, our time can be more productively spent than
conversing about how many post-it notes it takes someone's NOC
to run MD5 with a given vendor's BGP code.  That will come later. 8-)

Thanks.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 18:17:50 -0500

>numbers of routes, I'm all for that.

one could do a good job of filtering using static data about who is 
the legitimate originating AS for a given block of address space, but 
that data should be obtained from whoever is authoritative for 
managing address space assignments. The authoritative folks are are 
Internet Regional Registries.  They allocate blocks to ISPs and to 
subscribers, and the ISPs may allocate blocks to subscribers or to 
downstream ISPs, forming an obvious hierarchy. because this data is 
relatively static, downloading it from repositories and constructing 
filters would be a viable means of checking origin AS assertions in 
UPDATEs. Note that just relying on an ISP to advertise this data 
correctly via a repository is not a good idea, as the same config 
errors that cause route errors today could cause errors in posted 
data, and attacks on workstations used for configuration management 
by an ISP would have the same effect.

In contrast the route authorization data is dynamic and thus is a 
poor choice for posting to a repository for later download to 
construct filters. moreover, because some (many?) ISPs consider some 
of the policy data about relationships to be sensitive, it is hard to 
convince all ISPs to publish all of this data, which further limits 
the ability to make use of this sort of relatively static data as 
input to filters.

>However, some basic assumption of good will between ISPs is reasonable.

only to the extent that you wish to be vulnerable to errors by the 
ISP, or to attacks on the ISP management system that are externally 
equivalent to these sorts of benign errors.  I would suggest that a 
goal for BGP security is to find a way to detect and reject erroneous 
UPDATEs, irrespective of the way they come about. No ISP should trust 
another ISP to always do the right thing.

>DoS attacks against the root nameservers ARE happening, so let's focus

Not sure what attacks you think fall into category 1. Do you have 
some examples in mind?

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 00:20:24 +0100 (CET)

> the operational Internet much less world hunger.

Ok.

> drain on the collective brainpower of the IETF nor will it take eons

Ok again. However, I think we should be careful not to go overboard. But
when that happens or is about to happen we can discuss it then so I'm
going to shut up about it now.

> (beard, murphy, and convery).  In the convery draft ("Attack Tree"),

I'm reading those as we speak.

I found the first murphy draft misleading as it describes lots of
attacks that are easily mitigated by proper IP filters or the MD5
option. However, this is corrected mostly in the second one.

> - Document threat models for routing systems

Here's one: someone implements security that is so airtight it proves
impossible to get the "systems" "routing".  :-)

> to run MD5 with a given vendor's BGP code.  That will come later. 8-)

I think a discussion on operational issues is important. For instance,
in theory you can simply filter all the prefixes and AS paths for all
routing updates. However, in practice this is impossible as there is no
good source of authorative information, it would be too slow, routers
can't hold such a large amount of filtering data, and there are no good
mechanisms to install filters in routers.

Note that this problem will only get worse as information in BGP is
signed.

About draft-convery-bgpattack-00.txt:

2.1.2 BGP on Cisco routers doesn't show up on a port scan. However,
finding out the addresses for BGP routers is otherwise often fairly
trivial.

2.1.3 (and later): I'm missing the part where the invalid
router/non-router gets access to the physical infrastructure and there
is no mention of compromising the MD5 option.

2.1.5 As BGP sessions are typically connected 99.9% of the time
attacking the service on TCP port 179 will not do much but generate lots
of "connection refused" packets. There are good mechanisms to handle
/32s (filtering) or flooding (update propagation delay, flap dampening).

2.1.6 missing the MD5 and IP filter protection mechanisms.

2.1.7 man "in the middle" is not necessary as it is trivial to pose as
the peer router if there is access to all the traffic.

One thing that isn't mentioned explicitly is introducing a very large
transitive path attribute for the sole purpose of eating up memory. This
can be effective if done on a sufficiently large number of BGP routes
(in the order of ten thousands).

If people don't filter properly you can also do very funny things by
routing the BGP next hop addresses into oblivion.

Iljitsch van Beijnum

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 01:22:26 +0100 (CET)

> Internet Regional Registries.

They are now. However, documentation for some of the old assignments
seems rather iffy. Providing a mapping from the prefix to the router
sourcing that prefix might also be difficult. In other words: how do I
know a certain router belongs to a certian organization? But I guess
that's for the RIRs to figure out.

> Note that just relying on an ISP to advertise this data

What exactly to you want to put in the repository? You could have the
RIRs maintain the prefix to AS mapping. Then it would be necessary to
query the repository to validate this information in a routing update.
Another way to go is for the RIRs to sign the prefix to AS mapping and
the router can check the signature. However, this is very costly in
memory and processing power, and propably also in management if there is
some kind of time to live involved to prevent replays. If the full
prefix to AS mapping information is available out of band anyway, there
is no need to cryptographically protect this information: either it is
the same as the repository data = valid or it is different = invalid.

> construct filters.

I'm not sure I get what you mean.

> moreover, because some (many?) ISPs consider some
> of the policy data about relationships to be sensitive,

Big babies. The AS path information is there for everyone to see anyway.

> it is hard to

At some point in the recent past people would relay email for the whole
world. Today, you are tarred and feathered for that. If there is a need,
it is possible get people to change their behavior.

> another ISP to always do the right thing.

Your ISP can blackhole or sniff your traffic any time they want to. Is
it really useful to build elaborate protection against them modifying a
path attribute or two?

What we need is to make sure people only announce the prefixes they
should announce. Tying a prefix to an AS isn't all that hard. The size
of the data isn't even an issue: 114,000 x (5 + 2 bytes) = 800 kB. It is
harder to make sure someone isn't faking a path to a valid origin AS.
But fortunately we don't have to protect the entire AS path: just the
transit ASes for the source AS should suffice. (Unless I'm mistaken I
explained this in a message last week or so.)

> Not sure what attacks you think fall into category 1. Do you have

If an ISP wants to do nasty things they have more than enough ways to do
it without resorting to modifying BGP updates.

Iljitsch van Beijnum

---

From: Sean Convery <[email-masked]>
Date: Mon, 4 Nov 2002 19:56:20 -0800

comments inline.

On 11/5/02 at 12:20 AM, [email-masked] wrote:
SNIP

First, thanks very much for reviewing the draft!
>finding out the addresses for BGP routers is otherwise often fairly
We'd like to test this with a few implementations.  The BGP RFC doesn't
explicitly state to only allow BGP conversations between configured
peers (though it intuitively makes sense).  I agree there are other ways
to find the address.  Specifically in 2.1.2 subgoal 1 "Establish session
with permissive router" we're assuming you've discovered the address and
are now trying to see if the router will speak BGP or not.

We should define "permissive router" better.  Here we mean a router that
will speak BGP to an IP address not specifically defined as a peer.
Though I don't quite understand why an implementation would do this
(large hub-and-spoke networks perhaps?), we didn't want to rule anything
out.

>is no mention of compromising the MD5 option.
We tried not to presuppose a specific attack environment in this draft.
We only wanted to walk through which attacks were possible.  We're
advocating further research be done (perhaps a second draft) to analyze
these attacks from different perspectives.  As a strawman, I'd like to
see:

Topology:

- ISP BGP Implementation (perhaps different types)
- Enterprise BGP Implementation - as a side rant, much of the
conversation I've seen on idr and rpsec seems to assume an ISP
deployment.  BGP is used plenty in enterprise environments as well.
Here MITM, sniffing, etc. become much more possible.

Attacker:

- blind attacker (no special access to the network)
- insider (some special access such as an employee of the enterprise
using BGP)

The easiest way we've come up with to do the analysis would be to assign
attributes to various parts of the tree based on different topologies
and attackers.  For more info check out the end of section 1 of the
draft.

Regarding MD5, that got its own section 2.1.1.  Any attack against a
system employing MD5 would need to first run through that section of the
tree assuming the overall attack requires the generation of valid TCP
179 messages.

For the entire tree, we assumed no best practices were employed, this
would give us a base set of attacks that could then be weeded down based
on lots of factors.  Rather than reference the end of section 1 again,
let me paste the passage I'm referring to:

"This I-D illustrates a simple BGP attack tree: subsequent analysis
should assign attributes (and possibly values) to each node of the tree.
This allows more quantitative methods to be used in analyzing the attack
tree data. These attributes could include:

    * Impact of the attack
    * Ease of attack execution
    * Cost of the attack
    * Presence of countermeasures (such as best practices)
    * Access/trust requirements to conduct attack

Analysis of this data will yield the subset of attacks that result in
the most damage, are the easiest to launch, the least costly, have the
least access requirements, and are unlikely to be mitigated by current
best practices. Addressing these attacks should be the initial focus of
any improvements to BGP or relevant best practices."

>attacking the service on TCP port 179 will not do much but generate
>lots of "connection refused" packets. There are good mechanisms to
>handle /32s (filtering) or flooding (update propagation delay, flap
>/dampening).
>
I think we need some published test data to decide this either way.
Based on my experience so far, I would bet that attacking TCP 179 will
have some impact on certain implementations.

>2.1.6 missing the MD5 and IP filter protection mechanisms.
See previous response regarding best practices.

>the peer router if there is access to all the traffic.
I'm not sure I understand your comment.  In this attack we're not
assuming access to all the traffic.  Here the attacker is trying to send
a spoofed BGP message.  This tree shows he can do it one of two ways:

1. TCP Sequence # attack + the spoofed BGP message
2. Some type of MITM + the spoofed BGP message

Based on the attacker's location, I agree that some of these attacks
will be more or less likely.

>transitive path attribute for the sole purpose of eating up memory.
>This can be effective if done on a sufficiently large number of BGP
>routes (in the order of ten thousands).
>
Good point, this would probably need to go into Section 2.1.5.4 "Valid
BGP Messages"  It might be a further elaboration on 2.1.5.4.2 "update
flooding"...

>routing the BGP next hop addresses into oblivion.
Can you elaborate on that further?  I think I understand what you are
referring to, I'm just not sure where to put it in the tree.  Is this a
spoofed message or an intercepted and modified message from a valid
peer?

Thanks again for your comments.

Sean

---

From: "Larry J. Blunk" <[email-masked]>
Date: Tue, 05 Nov 2002 03:36:18 -0500

> Internet Regional Registries.

  (minor nit, the preferred term is Regional Internet Registries (RIR's),
   so as not to confuse them with Internet Routing Registries (IRR's).

> They allocate blocks to ISPs and to 

   The problem is that there is generally no such hierarchy for legacy
and provider independent address blocks -- which constitute a significant
percentage of announced space.   In many cases, the originating AS
will be "owned" by a different organization than the address prefix.
There are even cases where the originating AS is in a different RIR
than the address prefix.  Another issue is that many providers
have multiple AS's assigned to them.  Should a provider be able to
specify which of their AS'es is allowed to originate a prefix?

   Clearly, you need to be able to express the
relationship between origin AS and address prefix.  The RPSL
route object represents one mechanism to make this association.  Note
that RIPE (and soon APNIC) requires authorization from the both
the AS owner and address prefix owner in order to create a route object
in their registry.  So they are not just relying on the ISP to
get the route object right.

> the ability to make use of this sort of relatively static data as 

    Again, how do you allow an organization with provider independent
address space switch from one provider's origin AS to another?  I don't see
any other way than with route authorization data (approved by both
the ISP and the owner of the address space).   No matter how you
generate filters, there will clearly be some loss in dynamism.

   Also, I don't understand what "sensitive" policy data is being
exposed here.  What is being published is the "public" origin AS for
a prefix which is already accessible to all.  If you happen to have
an internal network configuration where the "real" origin AS gets
rewritten, simply don't publish that information.  There's no requirement
that the same data in the public registries be used for internal
network configuration.   I am aware of one ISP that runs one registry
for their public routing policy data and another for their internal
proprietary data.

  -Larry Blunk
   Merit

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 09:38:10 +0100 (CET)

> peers (though it intuitively makes sense).

Obviously it would be good to recommend practices that make all kinds of
bad things harder without impact to existing functionality. Cisco's
approach of only allowing TCP connections to port 179 from configured
peers and when there is no session is a good one.

However, Zebra for instance first accepts the connection and then drops
it again if there already is a session or if the address isn't
configured.

> I agree there are other ways to find the address.

http://www.ams-ix.net/cgi-bin/publicmembers.cgi?=db_search=&sort_on=3    :-)

> (large hub-and-spoke networks perhaps?), we didn't want to rule anything

I seem to remember Cisco had a configuration command to enable this
behavior, but I can't find it at the moment. I guess it could come in
handy if you have to set up many neighbors quickly.

> We tried not to presuppose a specific attack environment in this draft.

If you want to steal an IP address you have to be on the physical
subnet. This can happen by design (internet exchange) or accident (telco
screws up) but usually an attacker will have to do some work for this.

> Here MITM, sniffing, etc. become much more possible.

But enterprises aren't typically in the position to propagate much
malicious routing information as their ISPs filter them.

> - blind attacker (no special access to the network)

With TCP MD5 in place they shouldn't be able to do anything except DoS.

> - insider (some special access such as an employee of the enterprise

:-(

> and attackers.  For more info check out the end of section 1 of the

What I'd like to see is a simple web-based tool that has the tree and
allows you to add security measures such as anti-spoofing filters, MD5,
static MAC addresses on exchanges and so on, and then see how many of
the attacks go away. This could be a learning experience. Heck, I might
make something like this.

> tree assuming the overall attack requires the generation of valid TCP

I don't think this is made explicit in every place.

> on lots of factors.

You don't mention a list of best practices... It might be good to
include a list. Actually I've been working on this for a while.

> have some impact on certain implementations.

This should be worth a presentation at a NANOG or RIPE meeting...

> a spoofed BGP message.

For a successful man in the middle attack you must be able to:

AND - sniff original traffic
    - inject replacement traffic
    - block original traffic

However, man in the middle is more difficult to do than simply
completely assume the identity of the neighbor and yields no extra
results.

> This tree shows he can do it one of two ways:

> 1. TCP Sequence # attack + the spoofed BGP message

This will obviously break the existing BGP session pretty quickly and
then all routing information (spoofed or otherwise) from this peer is
removed.

> will be more or less likely.

MD5.  :-)

> spoofed message or an intercepted and modified message from a valid

I suppose it could be either. What you do is inject a route that makes
the next hop address for other BGP routes point to an unexpected place.
For instance, you can announce the /24 for an IX as two /25s with the
next hop address set to your router and then you'll receive all traffic
for all peers connected to the IX. (However, the sessions would probably
go down in this case.) However, this can be stopped with proper inbound
route filters.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 5 Nov 2002 09:53:36 -0500

Larry,

On Tue, Nov 05, 2002 at 03:36:18AM -0500, Larry J. Blunk wrote:
> exposed here.

The issue is that the databases lack "scope".  A generic IRR should
contain objects that are visible in the public Internet.  However,
as you move closer to the provider, or even explore peering or
contractual relationships you will have routes being exchanged
that are not public.  For example, some more specific subnets
(customer specific) that are exchanged between two providers that may
not make it into the global Internet.

For security and sanity purposes, registering the objects would be
nice.  But the scope of the visibility should only be the two providers
in question - per the example above.  Right now, the only scope
we really have is an entire database.

> There's no requirement

But scaling this to one db per relationship is a bit awkward.
Yes, the functionality is available, but the simplicity isn't quite there.

-- 
Jeff Haas 
NextHop Technologies

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Tue, 5 Nov 2002 07:01:43 -0800

> numbers of routes, I'm all for that.

We really need better people managing the filters that we can do today.
Remember, the problem today is that ISPs are _not_ doing what they can do
with what they have. Ingress prefix filtering on the ISP-Customer edge is
haphazard. Ingress prefix filtering on the ISP-ISP side is weak. Egress
filtering on the ISP-ISP side is almost non-existent.

Understanding why people are not doing what they can do with what they have
is critical to anything new that is recommended. Given that we have big ISPs
(in the top ten based on Skitter) who do all three prefix filter modes
around the RIR boundaries on two major vendor's equipment, I would say that
the lack of prefix filtering has more to do with laziness than issues with
"evil" ISPs.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 16:28:36 +0100 (CET)

> haphazard.

In my experience this is done relatively well today.

> Ingress prefix filtering on the ISP-ISP side is weak.

Yes, because the number or filters and the size of the filters gets hard
to control.

> Egress filtering on the ISP-ISP side is almost non-existent.

This could be better but I think most ISPs already do this, the filters
may simply not be strict enough.

> around the RIR boundaries

What do you mean with "around the RIR boundaries"?

> on two major vendor's equipment, I would say that

ISPs aren't evil. (At least, not more than other people.) The problem
with very strict prefix filtering is that you're essentially rebuilding
the entire global routing table as a set of prefix filters. (Well,
actually prefix filters aren't enough as they don't look at the AS
number.) Maybe there are people who do this, and more power to them, but
doing it using today's tools is a nightmare. Only very large networks
can spare people to implement something like this.

I don't think a solution where we daily download the RIR databases and
create route filters from them is the best we can do. This WILL break a
lot of connectivity for a variety of reasons. What I'd like to see is a
standardized way for a router to consult a policy server about the
routing updates it receives. The policy server then looks in its
database and decides whether the route is good or bad. This saves huge
amounts of storing configuration information and processing on the
routers, and everything is in a central place where it can easily be
monitored, controlled and secured. Also, people can choose the level of
security they want: policy server must validate before the route is
accepted, or the route is accepted but removed when the policy server
doesn't like it. The policy server can also push simple fall-back
policies to the routers so they can continue to operate when the policy
servers become unreachable.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2002 12:02:51 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    Iljitsch> However, Zebra for instance first accepts the connection and then drops
    Iljitsch> it again if there already is a session or if the address isn't
    Iljitsch> configured.

  Well, Zebra is just a portable application, not an entire OS.
  We do not (yet?) have a portable way for an application to express
firewall rules to the OS. A good installation of Zebra would use
ipf,ipchains,iptables,etc. to block off port 179 from other origins.

    >> (large hub-and-spoke networks perhaps?), we didn't want to rule anything

    Iljitsch> I seem to remember Cisco had a configuration command to enable this
    Iljitsch> behavior, but I can't find it at the moment. I guess it could come in
    Iljitsch> handy if you have to set up many neighbors quickly.

  I can see it being very useful in a lab environment.

    Iljitsch> What I'd like to see is a simple web-based tool that has the tree and
    Iljitsch> allows you to add security measures such as anti-spoofing filters, MD5,
    Iljitsch> static MAC addresses on exchanges and so on, and then see how many of
    Iljitsch> the attacks go away. This could be a learning experience. Heck, I might
    Iljitsch> make something like this.

  It would be a useful general tool for security analysis of protocols.

  BTW, I found the AND/OR stuff difficult to follow. 
  It seems you can write:
  (A || B || C) && D

  as:
		OR	A
			B
			C
		AND	D

  What's weird is that the OR is to the left of the first item (prefix), while the
AND is between C and D (infix).
  Perhaps I am misreading, and in fact the above describes:
	  A || B || (C && D)

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2002 12:48:43 -0500

>>>>> "Jeffrey" == Jeffrey Haas <[email-masked]> writes:
    Jeffrey> Larry,

    >> Also, I don't understand what "sensitive" policy data is being

    Jeffrey> The issue is that the databases lack "scope".  A generic IRR should
    Jeffrey> contain objects that are visible in the public Internet.  However,
    Jeffrey> as you move closer to the provider, or even explore peering or
    Jeffrey> contractual relationships you will have routes being exchanged
    Jeffrey> that are not public.  For example, some more specific subnets
    Jeffrey> (customer specific) that are exchanged between two providers that may
    Jeffrey> not make it into the global Internet.

    Jeffrey> For security and sanity purposes, registering the objects would be
    Jeffrey> nice.  But the scope of the visibility should only be the two providers
    Jeffrey> in question - per the example above.  Right now, the only scope
    Jeffrey> we really have is an entire database.

  So you are arguing to do this within the protocol.

    Jeffrey> But scaling this to one db per relationship is a bit awkward.
    Jeffrey> Yes, the functionality is available, but the simplicity isn't quite there.

  Signed statements scale easily, and are as easy to filter out as the
advertisements themselves.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Nov 2002 14:53:21 -0500

>that's for the RIRs to figure out.

Yes, the legacy address allocation data currently held by ARIN needs 
revalidation, but in the long run these registries still represent 
the best bet for authoritative data sources.

The question you ask about associating a router with an organization 
is also an important part of BGP security, although in our work we've 
found that what is really needed is associating a router with an AS 
that it represents, rather than with an organization per se.  Since 
the registries are also authoritative for assignment of AS numbers, 
they can serve as appropriate sources for an AS # to organization 
binding, and the organization can then, transitively, authorize its 
routers to represent the AS #('s) that the organization controls.

>the same as the repository data = valid or it is different = invalid.

Your model for how to effect bindings and the verify them may be a 
valid approach, but it is not the one that we've explored in our 
S-BGP work. In our approach, the registries issues X.509 certs to the 
owners of address space and owners of As #'s. These certs enable 
these folks (ISPs and multi-homed subscribers) to sign data that 
attests to address space ownership, origin AS authorization, etc.  I 
don't think it appropriate to detail all of the S-BGP architecture 
here, since we're focusing on requirements vs. solutions, but the 
following URL provides access to the papers we published: 
http://www.net-tech.bbn.com/sbgp/sbgp-index.html

When one talks about getting data from a repository to match against 
received UPDATEs, it is important to pay close attention to the 
dynamics, as I noted earlier. For example, you noted a binding 
between a prefix and an origin AS. This binding can be changed by the 
prefix owner, by establishing a new relationship with an ISP, and the 
registry that allocated the prefix need not be in the loop for this 
change.  So while some form of repository could be used to convey 
this data, the data really can be vouched for by the prefix "owner" 
without getting the registry involved. We don't want to create 
dependencies on interacting with folks (e.g., registry folks) when 
they are not strictly needed, as that could lead to new DoS 
opportunities.

>I'm not sure I get what you mean.

The choice of which IPSs are authorized to advertise which prefixes 
is potentially a dynamic form of binding that is ill served by 
relying on posting to a repository and waiting for every ISP to 
retrieve the newly posted data. When a major outage occurs, ISPs want 
to be able to make charges in these bindings very quickly and have 
the changes propagate very quickly, and that is not consistent with a 
repository model, I think.

>it is possible get people to change their behavior.

In my experience, people change behavior only when they perceive the need.

>it really useful to build elaborate protection against them modifying a

ISPs that are NOT on any authorized path to me ought not be able to 
divert my traffic through themselves, or to black hole my traffic, 
e.g., by advertising a shorter prefix for my net.

>explained this in a message last week or so.)

I think you are mistaken.

>it without resorting to modifying BGP updates.

You are right if you refer to an ISP doing nasty things to its own 
subscribers. The principle of least privilege argues that we should 
try to prevent ISP A from doing unauthorized (bad) things to the 
subscribers of ISP B.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Nov 2002 15:14:24 -0500

Larry,

>(IRR's).

The hierarchy for prefixes allocated prior to the 1996 formation of 
the regional registries is just a short one, from IANA to the owner. 
ARIN has held all of this data but is working to reallocate it to the 
appropriate registries, based on the geopolitical affiliation of the 
owner.  But, it is still accommodated by the hierarchic model I 
described.

There is no problem (at least in the S-BGP work) accommodating the 
situations you describe, e.g., the originating AS differering from 
the prefix owner or an ISP with multiple AS #s being able to specifcy 
which AS originates which prefixes.  We also accommodate AS sets, 
path aggregation, etc.  Yes, all of these real world characteristics 
of BGP must be accommodated by any viable solution.

>get the route object right.

Yes, RPSL can be used to express this data, and the approach used in 
S-BGP is roughly equivalent, but with explicit articulation of how 
the owner securely expresses this relationship.

>generate filters, there will clearly be some loss in dynamism.

I refer you to the S-BGP documents, a URL for which I posted earlier 
today, for the details on how an orgabnization with a prefix that is 
provider independent expresses the origin AS binding.

Yes, if one choose to use filters and to construct them from static 
data sources, then there is a dynamics mismatch.

>for their public routing policy data and another for their internal

If the route registries included only the origin AS info, I agree 
that this would not be too sensitive, but my understanding is that 
these registries also include info about the routes authorized 
between ISPs, including fallback paths, and that's where the info 
becomes more sensitive.

Securing the origin AS for a prefix is a good start, but it falls 
well short of addressing many forms of routing attacks, as I noted in 
a previous message.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Nov 2002 09:52:58 +0100 (CET)

On Tue, 5 Nov 2002, Stephen Kent wrote:

> >If the full

> S-BGP work.

There are other things that aren't explored well enough in S-BGP. One
thing that bothers me a lot is the fact that a routing update must be
generated for each neighbor individually. This breaks a common
optimization where the same update is sent to a large number of
neighbors. I'm not convinced that having some kind of destination
identifier in an update is necessary, but if it is it should still be
possible to somehow group neighbors so the optimization remains intact.

Did you calculate the extra memory needed for full S-BGP deployment
throughout the internet?

And I think a solution where the routers themselves do all the
authenticating is inherently problematic because of performance and
security issues. A flimsy lock on a colo rack isn't enough to protect
your secret keys.

> In our approach, the registries issues X.509 certs to the
> here, since we're focusing on requirements vs. solutions,

Well, we can use S-BGP as an example of what we should require.  :-)

> >>  I would suggest that a

> e.g., by advertising a shorter prefix for my net.

Ok, we're in agreement there. However, I wonder if there isn't a less
heavy-weight way to detect this situation than do public key crypto on
each update. One optimization would be to only check updates that would
install a new better path towards a destination. Also, AS paths are
often very similar across a somewhat large number of routes, so there is
probably a way to check the path once and accept many updates rather
than do it for each update individually.

> I think you are mistaken.

It's a bit longer ago. Here it is again, with slight modifications:

Validating the AS path is difficult if we look at the AS path as
something that can take many shapes. But in reality, it consists only of
two things:

- the part the source of the routing update has a business relationship
  with, and
- the part that the part that the source of the traffic has a business
  relationship with

Suppose:

- AS1 is a customer of AS2
- AS2 is a customer of AS3
- AS5 is a customer of AS4
- ASes 3 and 4 peer

The AS path as seen by AS1 is: 2 3 4 5. AS2 trusts AS3 because they
(presumably) have a tamper-proof and direct connection to them, and they
pay them money to handle the traffic. The same is true for AS1 with AS2.
AS1 also trusts AS3, because indirectly, AS1 is also a customer of AS3
and the connection is through the trusted AS2.

However, AS3 may not necessarily trust AS4, even though they have a
direct connection. ISPs may peer with hundreds of ASes and some of those
send hundreds or thousands of routes. It is hard (using current tools
and mechanisms) for AS3 to verify independently that everything they
hear from AS4 is correct.

This could be remedied by AS5 including all the possible trusted partial
paths in an update and signing it. So AS5 creates an announcement that
includes the address information, a signature from a registry that
confirms the addresses belong to AS5, and the partial path "4 5". When AS1
receives this information with the path 2 3 4 5 it can decide this is a
trustworthy path because it trusts 2 3 and the signature covers 4 5.

(In reality AS5 will be multihomed so the list of possible paths becomes
"4 5", "6 5", "4 6 5" and "6 4 5".)

Or maybe the set of possible transit ASes could be unstructured.

Iljitsch van Beijnum

---

From: [email-masked]
Date: Wed, 6 Nov 2002 08:52:02 -0500 (EST)

>possible to somehow group neighbors so the optimization remains intact.

The separate updates to each neighbor are needed because the neighbor's
identity has to be included in what is signed.  Otherwise, someone could
take a lot of purloined updates from the net, break them up into pieces
and reassemble into whatever sort of AS_Path they wanted.

Yes, this is a bummer because it removes the opportunity to optimize
if you are advertising the same thing to lots of neighbors.

The signature scheme might be expandable so that you sign a set of
neighbor identities into the update, rather than just one.  This would
be useful if you had lots and lots of neighbors that you could break
into a lot of groups of lots of neighbors, where the advertised routes
to each neighbor in one group would be the same - then you would still
get some optimization.  Would such situations be common?

--Sandy

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Nov 2002 15:05:21 +0100 (CET)

> and reassemble into whatever sort of AS_Path they wanted.

I'll have to reread S-BGP as it has been a couple of months or so, so
maybe I'm saying things that are discussed in the draft, but...

Wouldn't AS X be the only one who can successfully send an update with
AS X as the first/last AS in the AS path? If AS Y took this update and
announced it then either it would have to add AS Y as per RFC 1771 and
the path and thus the entire update would be different, or it wouldn't
and a very simple sanity check would fail.

> if you are advertising the same thing to lots of neighbors.

If this was important enough to implement now, it will certainly be an
important optimization if routers have to sign each update.

> get some optimization.  Would such situations be common?

Yes, except maybe for the "lots of groups" part. A lot of traffic is
exchanged at internet exchanges. Typically, all peer routers share the
same settings for outbound updates. For instance, I manage a router with
103 peers in 4 groups, with the largest group having some 40 neighbors.

Iljitsch

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Wed, 6 Nov 2002 07:30:30 -0800

> if you are advertising the same thing to lots of neighbors.

It is also operationally not deployable and capital exclusive. Peer Groups
are a necessity to convergence speeds. No peer groups means really slow
convergence. This is eBGP and iBGP peer groups - both are deployed. The only
thing holding up faster deployment is the ability to teach people the value
of them. Once ISPs know, they draft up a deployment plan and push them out.
The additional benefit peer groups provide is memory optimization. Some
equipment with memory/RIB/FIB requirements designed for the mid-90's need
peer groups as means to optimize memory. So removing this capability means
that you force capital spending and network wide extended maintenance
windows to execute the upgrades.

IMHO - "Security requirements" that force Internet capital spending and
network wide maintenance windows to deploy are not going to be adopted by
the operations community.

Barry

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Nov 2002 12:34:52 -0800

> Peer Groups are a necessity to convergence speeds.

as far as i can tell, this seems to be a vendor-specific artifact

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Nov 2002 16:04:38 -0500

> as far as i can tell, this seems to be a vendor-specific artifact

But a very common one.

---

From: Charles Lynn <[email-masked]>
Date: Wed, 6 Nov 2002 16:20:45 -0500 (EST)

Iljitsch,
				   
> generated for each neighbor individually.

This statement is incorrect.  S-BGP MAY sign a single update, that
includes the AS number(s) of each of the ASes to which the update will
be sent.  The current S-BGP code base supports this.

> I'm not convinced that having some kind of destination

The optimization remains intact.

> Did you calculate the extra memory needed for full S-BGP deployment

The reference

http://www.ir.bbn.com/projects/s-bgp/NDSS00.S-BGP.ps

gives the numbers that were estimated at the time it was presented
(Feb 00).  The net has grown since then, of course, and the numbers
were based primarily on ARIN data.  Note that an initial deployment
would not need memory for a "full deployment throughout the internet"
as I think it is very unlikely that any security mechanisms will see
"full deployment", say within a year or so.  However I agree that the
numbers for a full deployment (of any security mechanism) need to be
examined so the, e.g., the router vendors can work the capacity
requirements into their product lines.  (I think that I've heard the
lament that "routers don't have enough memory for the current size of
the routing tables" for a couple decades. :-)

> security issues.

I'm not an ISP operator, but I would think (please correct me if my
view is off-base) that having to contact an external server to do the
processing whenever a router receives an update - as has been
suggested in some documents I have read - would be much worse, from
the reachability standpoint and the "high value target" perspective.
Do you think otherwise?

The above reference showed that "all the authenticating" is not that
much of a load for a router with a modern processor.  Since the time
the work was presented, crypto chips that can do thousands of
operations per second have become available.  I've heard of designs
for systems that can perform IPsec on 10 GBit links.  Note however
that some high-speed crypto peripherals could not meet their
advertised rate in the S-BGP context due to their way of handling the
switching of public keys.  (It turned out that software crypto was
actually faster than the hardware!)  I'm sure that the hardware folk
can design the chips to satisfy the requirements, if currently available
chip sets are found to be inadequate.  The VPN market should make the
hardware competitive.

> A flimsy lock on a colo rack isn't enough to protect your secret keys.

If someone can get to your hardware, you likely have more to be
concerned about than the secret key.  If the secret key (DSA private
key for S-BGP) is in a well designed piece of crypto hardware, getting
it out without someone noticing would be, I think, a very low
probability event.

> Well, we can use S-BGP as an example of what we should require.  :-)

Yes, please do.  It is an example of what can be done (an existence
proof if you will) that tries to consider the whole system and the
supporting pieces.  Drawing packet layouts and specifying a protocol
are the easy parts.

> However, I wonder if there isn't a less heavy-weight way to detect
> this situation than do public key crypto on each update.

There may be.  We need to consider the alternatives and especially the
requirements.  We should not dismiss options because someone thinks they
are too hard or take too much time or space or whatever.  Once we have
requirements, we can do the detailed engineering to see what solutions
we can collectively find, and what they "cost".

> One optimization would be to only check updates that would
> install a new better path towards a destination.

(The current S-BGP implementation can be configured to do this.)

> Also, AS paths are

Yes.  But the S-BGP experience has been that the data structures (the
S-BGP team thought were) needed to do this took more processing time
and memory than not trying to use that optimization.  Maybe other
implementors, if we turn them loose on the problem, will find otherwise.

> It's a bit longer ago. Here it is again, with slight modifications:
<snip>

> AS2 trusts AS3 

What does it mean to "trust an AS"?  That you "trust" all the
employees of the organization that operates the AS?  That seems to
still be vulnerable to the historic "attacks" where an employee
mis-types something.

Maybe one reason that you have reached the conclusion that only the
first couple hops need protection is because the average AS path
length is very short -- the routing tables that can be found around
the net showed an average length something like 3.5 hops.  Thus the
notion of only needing to protect the first couple hops is "close" to
actually protecting the whole path.  Would you reach the same
conclusion if the average AS path length were, say, six or seven hops?

The notion of signing a list of possible paths seems, to me, more like
an authenticated topology than how packets should be routed at a given
point in time.  Do you have any estimates for how much space it would
take for a full deployment of such a mechanism?

Sandy commented...

> get some optimization.  Would such situations be common?

Note that the "grouping" is unlikely to be "free".  It will take space
to record, processing cycles to implement, and management cycles to
maintain, for each or the posited hundreds or routers in an ISP.

And Iljitsch commented ...

> 103 peers in 4 groups, with the largest group having some 40 neighbors.

(I've been told that many ISPs are moving to private peering
arrangements.)  We certainly need to consider the case you have
described.  We need to get a list of all the topologies that need to
be supported into the requirements list.  Are there any others
(besides private peerings and internet exchanges) that are significant?

Charlie

---

From: Sean Convery <[email-masked]>
Date: Tue, 12 Nov 2002 11:19:27 -0800

>  Perhaps I am misreading, and in fact the above describes:

What it should mean is (A or B or C) AND D

as in:

Attack:
OR  1. Send message to router causing reset
    OR  1. Send RST message to TCP stack
        2. Send BGP Message
        OR  1. Notify
            2. Open
            3. Keepalive
    AND 3. TCP Sequence number Attack (Appendix A.4)
    2. Alter configuration via. compromised router (Appendix A.1)
    
You can send message causing a reset by 1. sending the message to the
TCP stack, or 2. sending a BGP message.  But in both cases you need 3.
the TCP sequence number attack.

There shouldn't be any cases where an AND or OR is between two numbers.
it should alway be on the same line as a goal on the tree.

We tried to explain the notation in the Intro section.  If you can
provide some specific comments on how to make this better (short of
rewriting the CERT paper :)) we'd love to hear them.

Thanks,

Sean

---

From: Sean Convery <[email-masked]>
Date: Tue, 12 Nov 2002 11:03:21 -0800

On 11/5/02 at 9:38 AM, [email-masked] wrote:

SNIP
>malicious routing information as their ISPs filter them.
Right, but they are more than capable of being hacked on the inside
(regardless of filtering), which is one of the things we should be
concerned about.

SNIP
>> The easiest way we've come up with to do the analysis would be to
>> assign attributes to various parts of the tree based on different
>> topologies and attackers.  For more info check out the end of
>> section 1 of the draft.
>
We agree and would love your help. :) Dave Cook is doing some modelling
to create the tree graphically from the source XML file.  We could
probably extend it to do something like this...

>> system employing MD5 would need to first run through that section of
>> the tree assuming the overall attack requires the generation of
>> valid TCP 179 messages.
>
Right, see my previous below response, we're assuming no best practices
in place: 

>> For the entire tree, we assumed no best practices were employed,
>> this would give us a base set of attacks that could then be weeded
>> down based on lots of factors.
>
I would think best practices for BGP would need to be in a separate
draft.  There are lots of BPs spread all over the web, has anyone
grouped them all together for the IETF?

SNIP
>
>>> 2.1.7 man "in the middle" is not necessary as it is trivial to pose
>>> as the peer router if there is access to all the traffic.
>
>> assuming access to all the traffic.  Here the attacker is trying to
>> send a spoofed BGP message.
>
Again, we'd love to test this out. I agree, things could go badly for
the BGP session.
>> Can you elaborate on that further?  I think I understand what you
>> are referring to, I'm just not sure where to put it in the tree.  Is
>> this a spoofed message or an intercepted and modified message from a
>> valid peer?
>
>the next hop address for other BGP routes point to an unexpected
>place. For instance, you can announce the /24 for an IX as two /25s
>with the next hop address set to your router and then you'll receive
>all traffic for all peers connected to the IX. (However, the sessions
>would probably go down in this case.) However, this can be stopped
>with proper inbound route filters.
>
Now I got it.  We do have some info on more specific route introduction,
but it is specific to IGP, We can probably broaden this definition in
2.1.3.

Thanks again,

Sean

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2002 19:37:24 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Sean" == Sean Convery <[email-masked]> writes:
    Sean> You can send message causing a reset by 1. sending the message to the
    Sean> TCP stack, or 2. sending a BGP message.  But in both cases you need 3.
    Sean> the TCP sequence number attack.

    Sean> There shouldn't be any cases where an AND or OR is between two numbers.
    Sean> it should alway be on the same line as a goal on the tree.

  So, I can think of this as persistant prefix :-)
  Once I see "OR", I put OR between each clause (at that level) until I see
something else.

    Sean> We tried to explain the notation in the Intro section.  If you can
    Sean> provide some specific comments on how to make this better (short of

  I'll re-read the intro and see what I can tell.  
  I admit that I was in a rush to get to the meat. Maybe it would be good to
explain the first real instance out in detail. Maybe you already did that,
I'm not online to grab your draft again at the moment.