Subject: [RPSEC] Interior vs exterior?

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 13 Oct 2002 15:03:40 +0200 (CEST)

Hi,

I just subscribed to the rpsec list.

After reading the archives, I was wondering: does it make sense to handle
security for IGPs and BGP (or even other EGPs..?) at the same time? The
threat models don't overlap all that much.

It seems to me that the most likely threat to an IGP is an unauthorized
person trying to associate himself with the network. This isn't really a
threat in BGP since there is no neighbor discovery.

In BGP, a very likely threat is that of an AS sourcing an announcement for
prefixes it has no business announcing. This happens by mistake all the
time. Another threat would be changes to the routing information in
transit, but if the original announcement can be validated, this threat
doesn't amount to much.

Iljitsch van Beijnum

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

---

From: Tony Tauber <[email-masked]>
Date: Wed, 16 Oct 2002 10:23:07 -0400 (EDT)

> I just subscribed to the rpsec list.

Welcome.

> After reading the archives, I was wondering: does it make sense to
> handle security for IGPs and BGP (or even other EGPs..?) at the same
> time? The threat models don't overlap all that much.
>
> It seems to me that the most likely threat to an IGP is an
> unauthorized person trying to associate himself with the network.
> This isn't really a threat in BGP since there is no neighbor
> discovery.

Let's try and generalize a bit more and talk in more primitive terms.

What do you mean by "associate"?
What do you mean by "neighbor discovery"?

Take one or more existing protocols and describe concretely what
happens during that operation.

> In BGP, a very likely threat is that of an AS sourcing an
> announcement for prefixes it has no business announcing. This
> happens by mistake all the time.

Good.  That one has been reasonably mapped out in the past with
various proposed solutions.

The bottom line is that EGPs implicitly require trust of something
beyond one's administrative control.  People seem to agree that it's
a big issue but haven't gotten amazing traction with any solutions.

Generally, the response has been some sort of registry/PKI which has
the usual political, economic, and enforcement issues associated with
those approaches.

> Another threat would be changes to the routing information in
> transit, but if the original announcement can be validated, this
> threat doesn't amount to much.

Not so sure that that's not a problem as the nature of BGP is that the
updates get modified by intervening systems.  There's lots that can go
wrong if people can send an update which directs traffic supposedly
for some far-off AS to them but they can't (or won't) deliver it.

That actually renders the problem quite complex if you think about the
need (or reasonable desire) to verify both the as-path and the
next-hop.  The next-hop is what really affects forwarding but the
as-path affects the decision process leading up to that.

Add to this that as-path as well as other attributes can (sometimes
must) be changed by intervening ASs as a matter of normal operation
and administrative policy and things are quite sticky there.

Indeed, the richness of the information *inside* BGP (and quite
possibly any successor protocol) makes it difficult to protect.

To throw it out there: Would it be safe to say that IGPs don't suffer
from that class of problem at all?

We can talk about the easier problem of protecting the transport
layer against injection of spoofed packets with either bogus
information or which results in a DoS.  Perhaps we can agree that
the MD5 approach is sufficient there and has also been made use of
in some other protocols.  Sandy Murphy's now expired BGP protection
I-D mentioned that MD5 doesn't provide the level of anti-replay
protection of IPsec, FWIW.

As those might not use TCP, does MD5 really fill the bill there?

There are likely more questions, but maybe these will yield useful
discussion.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Oct 2002 19:35:20 +0200 (CEST)

> What do you mean by "neighbor discovery"?

My background is in operations, so I may not be up with the lingo...

I mean form adjacencies and the hello protocol. Someone could simply
connect a router to someone else's network and start interacting with the
routers there using the IGP of choice. OSPF has password authentication to
avoid this happening by mistake and can use cryptographic authentication
as well so attackers can't simply sniff the password.

(Although someone with physical access to the router could perform the
password recovery procedure.)

> happens during that operation.

OSPF:

- router wakes up
- router starts to send hellos
- router sees its own id in neighbor hellos
- router forms an adjacency with the designated router listed in neighbor
  hellos

See section 7 in RFC 2328.

> a big issue but haven't gotten amazing traction with any solutions.

One interesting question is: where is the authorative information about
what is correct? I don't even think there is any kind of formal
requirement to register routing information in a routing registry, and
many people don't. The people that do, often make mistakes or register
incomplete information. So at this time, the actual global routing table
is probably the place with the best information about what should be in
the global routing table...

> the usual political, economic, and enforcement issues associated with

I don't think enforcement is an issue. If not registering means you are
filtered, you will register.

> possibly any successor protocol) makes it difficult to protect.

This 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 trusts, and
- the part that the part that the source of the traffic trusts

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. 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 nearly impossible 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".)

Unfortunately, this will take a fairly large amount of extra memory over
what we do now in BGP. One optimization would be to cover a larger number
of prefixes with the same path attributes (I don't think this happens much
in practice with BGP) but that only yields significant results if
multihomed networks no longer originate their own routes but let their
ISPs do this under the ISP AS. But this leads to instability problems...

> from that class of problem at all?

In theory, two parts of the network running the same IGP might not trust
each other. But then the problem of the authorative information comes
right back. I would be very surprised if the number of IGP attacks were
higher than the number of unintentional IGP screwups. Having the same
information in two places increases the potential for mistakes a lot,
while it doesn't do much to prevent them. This is only useful when the
number of attacks is high relative to the number of mistakes.

> information or which results in a DoS.

Don't we have IPSec for that?

> Perhaps we can agree that

Do you have a link or title?

I would think a replay attack against BGP would be incredibly hard to
sucessfully execute. You first have to trick the other side into using the
same sequence numbers as the replayed attack, and then the other side has
to send the exact same size and number of packets or you lose your
sequence number synchronization.

> As those might not use TCP, does MD5 really fill the bill there?

I guess it would be possible include sequence numbers or timestamps to
prevent replays. And isn't MD5 considered weak now?

> There are likely more questions, but maybe these will yield useful

About your agenda question: one thing I would be interested in discussing
in Atlanta is the idea of offloading security and policy decisions in
interdomain routing to non-router systems. However, this may come close to
falling outside the charter. I don't want to take time away from
discussions that fit better with the charter.

The idea is that routers don't have the flexibility (as they can't be
programmed by their users), the CPU power or the permanent storage
capacity to handle this well. Just sending stuff to a policy server and
wait for aproval to come back lets the router focus on routing. But the
fact that routers can function autonomously is an important feature that
we don't want to lose. Having both will be complex.

Iljitsch

---

From: [email-masked]
Date: Wed, 16 Oct 2002 18:05:38 +0000 (UCT)

> > the usual political, economic, and enforcement issues associated with

well,
	the centralized nature of the IRR system is problematic.
	an approach that was attempted to push the responsibility
	out to the folks that hold the delegations.
	see:  http://www.isi.edu/~bmanning/inet98.html
	for a method that preserves the semantics of RPSL,
	while ensuring that the end sites are responsible for
	the accuracy of the information published.
	This only works if we can secure the DNS tho... :)
	
--bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 Oct 2002 12:03:37 +0200 (CEST)

On Wed, 16 Oct 2002 [email-masked] wrote:

> > incomplete information.

> 	This only works if we can secure the DNS tho... :)

I did a quick read, so I may have missed some things...

A few problems/questions:

- Currently, the RR does syntax checking. This has saved me a number of
  times, and I'm sure there are many people that have an even harder time
  getting this right than I do.

- Supposedly, the information would reside inside the network advertising
  a routing policy itself. What happens if this network is unreachable?

- What about delays and inconsistencies that arise when new delegations
  must be created and/or information is changed but still cached in
  certain places?

I love the DNS to death, but I think we should be very careful about
overloading it. (If only to keep the DNS guys off our back...) It might be
good to create a new distributed database for routing information (and
potentially other stuff), that can address some of the DNS weaknesses.

---

From: [email-masked]
Date: Fri, 18 Oct 2002 17:12:08 +0000 (UCT)

>   getting this right than I do.

	typos will eat your lunch every time.  thats why many folks
	are using GUIs for data entry and backend tools to generate
	the data.

>   a routing policy itself. What happens if this network is unreachable?

	RFC 1219.  DNS servers should be on different pwoer grids, e.g.
	physically diverse.  So when your master dies or your network
	is degraded by backhoe fade, you have slaved the data to (at least)
	one other remote server. 

	(e.g. what happens when the network "fades" to the centralized
	site? :)

>   must be created and/or information is changed but still cached in

	What about them? 

> potentially other stuff), that can address some of the DNS weaknesses.

	Not nearly as big an overload as (NAPTR, ENUM, IDN, DNSSEC...)
	Its a bunch of TXT RRs for crying out loud.  No change in
	the DNS at all.  Its a simple matter of implementation.
	
	Its not goofy, like the proposal to validate all routes received
	by checking them in the DNS -BEFORE- using them.  This is an
	OOB check that the route received is being announced as intended
	by the proper delegee.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Oct 2002 14:19:10 -0400

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

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    bmanning> the centralized nature of the IRR system is problematic.
    bmanning> an approach that was attempted to push the responsibility
    bmanning> out to the folks that hold the delegations.
    bmanning> see:  http://www.isi.edu/~bmanning/inet98.html
    bmanning> for a method that preserves the semantics of RPSL,
    bmanning> while ensuring that the end sites are responsible for
    bmanning> the accuracy of the information published.
    bmanning> This only works if we can secure the DNS tho... :)

    Iljitsch> I did a quick read, so I may have missed some things...

    Iljitsch> A few problems/questions:

    Iljitsch> - Currently, the RR does syntax checking. This has saved me a
    Iljitsch> number of times, and I'm sure there are many people that have
    Iljitsch> an even harder time getting this right than I do.

  There are two goals which are orthogonal:

  1) make the IRR more available, and provide integrity checking to it.
  2) make the end-sites responsible for content.

    Iljitsch> - Supposedly, the information would reside inside the network
    Iljitsch> advertising 
    Iljitsch>   a routing policy itself. What happens if this network is
    Iljitsch>   unreachable? 

  Same as what happens with other DNS info - you have to have secondaries.
We can even, initially, replicate the current IRR by having the RIRs
secondary all zones themselves.

    Iljitsch> - What about delays and inconsistencies that arise when new
    Iljitsch> delegations 
    Iljitsch>   must be created and/or information is changed but still
    Iljitsch>   cached in 
    Iljitsch>   certain places?

  Bill's paper points out that we currently live with 36+ hour delays in
the data.

  As for DNS vs "something else". We don't have a "something else" yet,
so let's just assume a "DNS-like" solution - one that supports secure
replication, authentication and online queries.

]       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"); [

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 Oct 2002 21:57:57 +0200 (CEST)

> 	is degraded by backhoe fade, you have slaved the data to (at least)

Yes, but this secondary server can only repeat the existing data. If the
outage is caused by incorrect filters derived from an incorrect routing
policy, there is no clear recovery path.

> 	What about them?

Ever since people started refusing to have their resolvers talk to
outsiders, the DNS has been a lot harder to debug. The RR system is not
without problems because you never know when people updated their filters.
But by having this in the DNS you add another layer of uncertainty: you
don't know when they created their filters AND you don't know the version
number for the zone they used.

> 	OOB check that the route received is being announced as intended

Lets not forget that this can't really work anyway since no router can
hold the configuration necessary to filter every announcement.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Oct 2002 16:25:54 -0500

Tony,

>	<SNIP>

I would avoid using the term "trust" here as much as possible. In the 
case of BGP, for example, there exists an explicit address allocation 
hierarchy that is authoritative for who owns what set of addresses. 
If one uses that data as a basis for deciding the veracity of an 
advertisement by an AS that claims to be the first hop for a block of 
addresses, then one is relying on authoritative data rather than some 
value-based "trust" model.

>the usual political, economic, and enforcement issues associated with

Could you be more specific with regard to the "issues" you allude to 
here? The IRRs are established and authoritative and using them as 
the basis for address allocation knowledge and for AS ownership 
presumably has many fewer problems than requiring ISPs to public data 
in route registries, where concerns over disclosure of business 
sensitive data arise.

>and administrative policy and things are quite sticky there.

yes, it's not trivial to verify that the UPDATE you receive is valid, 
given the allowed changed along the route, but it is possible 
starting with the externally known data.

>from that class of problem at all?

to the extent that an IGP is sued within one administrative boundary, 
life is simpler, but of one worries about compromise of routers 
within the scope of an IGP, the fundamental problem to be solved is 
essentially the same. it's just that IGPs typically employ algorithms 
that admit fewer local policy inputs that are invisible to the 
outside.

>protection of IPsec, FWIW.

The MD5/TCP checksum hack is not sufficient, in several dimensions:
	- from a crypto standpoint it is the wrong way to use a hash 
function to generate a MAC
	- it lacks automated key management, which makes it 
impractical to manage
	- because it operates at the TCP layer, it leaves more of the 
stack open to attack, vs. use of IPsec

Steve