Subject: RE: [RPSEC] proposed message to the IESG

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 Jan 2005 11:54:59 -0500 (EST)

>I have to agree with Russ, when is saying that "BGP is explicitely
>designed to transfer information".

Actually, this pretty much says nothing.  Can anyone think of a
protocol that is NOT "explicitely (sic) designed to transfer
information". (Sorry, Russ.)

>So, in this way we have to work to secure the "transport layer" not the
>information witch BGP is transfer.

Agreed.  And as that's presently part of the spec (in the IESG queue)
we're pretty safe saying this.

>Regarding, the authenticity of the information passed through the BGP,
>YES we should care also by this, but I think that this is a different
>side of the "BGP security".

Yes, there are two sources of problems - the outsiders, who can
be excluded by protecting the transport, and the legitimate peers.
Protecting against the legitimate peers in a distributed computation
like a routing protocol is much more difficult.  And that's what
we're arguing about.

--Sandy

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

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 16:04:06 -0500 (EST)

>> Russ, you seem to be saying that if a tier-1 AS allocates a subblock of its
>> allocated address space, that it is technically NOT ALLOWED to continue
>> to advertise that address space.  Is that a correct statement of what
>> you are saying?
>...
>It is
>normally a bad idea for the owner of a less specific chunk of prefixes who
>has allocated a more specific prefix to a customer to advertise that more
>specific prefix on their own (unless they are propagating a BGP advert).

I'm not exactly reading email in order here, so I just came to this
response to my message last Friday.  It seems to answer the question
I posed this morning, at least as far as saying whether it is allowed.
The answer being "It is normally a bad idea."

So does that mean that the security protections should try to
prohibit this?

And is the "bad idea" specific to announcing the same more specific
prefix?  Have you seen operationally that people objected to less
specifics being announced that contained their more specific prefix?

Since the less specific prefix is not going to replace their own
more specific in places that receive both, it would be less dangerous
to the customer, right?

>However, even with static allocations I would be hard pressed to find common
>examples of an ISP bothering (or desiring etc.) to advertise a specifically
>allocated sub-block.

But we have to consider the malicious case where someone may do any
manner of illogical things.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 18:37:54 -0500 (EST)

>Let me ask this: If you were teaching a class on IPsec to a bunch of 
>routing geeks, would you use "colliqual" terms, like "IPsec tunnel" to 
>explain how it works, or would you delve into the real terms, and 
>operation, immediately? Does the IPsec draft use the term "tunnel?"

A bad example from your point of view.

You betcha the IPsec draft uses the term tunnel.  "tunnel", "tunnel mode",
"AH tunnel", "ESP tunnel" - all through RFC 240[1,2,6,7,9].

>Before I answer your question directly, and while you're thinking about the
>question above

:-)

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 18:56:09 -0500 (EST)

>I'll point something out here.... The variety of things people do with BGP 
>would astound you. The cases are almost unbelievable. Just cruise through 
>the knobs available in the major vendor's implementations, and try to 
>figure out what they're there for. Yet I've seen every one of those things 
>used, in real life. Conditional advertisement, conditional injection, AS 
>Path stripping, local AS spoofing, AS migration and merge, re-origination, 
>aggregation, ....

What we need to do is figure out what operational twists are used,
which are so common or so needed that people would not do without,
which behaviors could be exploited to cause harm,
then judge which to accept as part of what must be secured
and which can be prohibited by a security protection.

Against this we put the behaviors that we know we really want to
counter.

We can use the lists of what we want to preserve and what we want
to squash to help build the security requirements.

>Let me put it another way: Is there any sense in which the policy will not 
>be based on the desirability of forwarding traffic via the advertised 
>route?

As you've pointed out, there's no end to the "variety of things people
do with BGP".  It's tough to try to decide what the motivation behind
some of those policies might be.  I really don't know the answer to
your question.  For some cases I've seen, the motivation seems to be
a desire to cause another provider trouble, whether there's an effect
on traffic at all.

>A---B---C---D
>|           |
>+-----------+
>
>What you're asking is what if A advertises 10.1.1.0/24 to B, but B 
>advertises that route with a path of {D,A} to C, rather than just {A}, 
>correct?

Well, no, actually.  I was talking about B getting in an update
containing an AS_PATH of length two, no matter what the contents,
and choosing that route but sending a route with a path of {{D,A,B} to C.
In other words, replace the AS_PATH of length 2 with some other path
of length 2.  With valid adjacencies.
Just exploring how exactly you mean "valid adjacencies" as a verification
metric for AS_PATHs.

I would think this would not protect against loops.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 19:07:28 -0500 (EST)

>I'm surprised you don't find this rather loose definition of ownership 
>problematic at all. It's a lot like me selling a room in my house, and the 
>new owner and I both listing it on our tax returns, isn't it? Would it 
>bother you if a credit card company gave you a number from a block, then 
>used that block to charge something, with the result that your bill 
>increased? If it wouldn't bother you, can I have your credit card 

But like I've said security authorizations don't always (frequently don't)
get consumed by being delegated.  It's not like resources which can
only be used by a single entity at a time.  Some things can be
shared usage and I think you've argued emphatically that you want
to be able to advertise less specifics even when the more specific
has been suballocated - an example of dual use.

Granting someone read access to my files doesn't make it necessary for
me to loose read access.  Granting someone signature authority on
my credit card doesn't mean I loose signature authority.

Honestly, Russ - weren't you arguing that operationally the requirement
was that the less specific was allowed to be advertised even if the
more specific subblock was allocated to someone else?  Why are
you complaining that I agree with you?

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 19:24:58 -0500 (EST)

>Asking why is always met with: "It's 
>what the spec says," and no other anwers or questions, based on operational 
>and implementation experience, are allowed.

I don't agree that we should ignore operational experience.  But it is
real tough to generate security protections unless you have a good
description of what's being protected.  As Joel said, it's tough to
secure unwritten semantics.  Even those operational uses that don't
match what the spec says have to be considered if the security protections
are going to be acceptable, deployable and all that.

Which is not to say that if we can point to any particular current
use of a behavior, then that behavior automatically must be
included in the requirements and the security protections have to
allow it.

I asked a lot of messages ago if anyone wanted to write up the
current operational practice.  We have to have that, at least the
ones that people want to preserve.

--Sandy

P.S.  A short off the top of my head list:
prepending your own AS
confederations
truncating private AS's from an AS_PATH
using private AS's between consenting adult ISP's

Injection of foreign AS into AS_PATH - I don't think this has reached
consensus yet as useful enough to keep, but it's been brought up.

Noone mentioned communities?  I've seen a Black Hat presentation
suggesting how these could be used to steal traffic, but not recent.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jan 2005 13:18:09 -0500

Russ and all:

I would like to know if the conflicts between the BGP spec
And operational practices are between the
Draft BGP specification or the RFC 1771.

Sue Hares

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 21, 2005 12:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [RPSEC] proposed message to the IESG

> Finally, you close with "This document is intended to present a set 
> of requirements from the operator community to the folks creating the 
> standards ..."  I have to admit that I do not recall hearing that 
> characterization of the goal for this document. The WG charter does 
> not convey the notion that this document is to represent the operator 
> view of security requirements for BGP.

I don't see a need for the document to represent *only* the operator
view of security requirements for BGP. However, if the operator view
is not represented at all, there is a high probability that anything
based on this document would be ignored by many operators.

Working for an operator myself, I clearly feel that if there is a
conflict between the BGP spec and the way BGP is actually used by a
significant number of operators, the operational practices need to be
taken into consideration - and the conflict should be explicitly
spelled out.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Sandy Murphy <[email-masked]>
Date: Wed, 26 Jan 2005 13:56:24 -0500 (EST)

>        Many of the DV characteristics are "rumor" based protocols -
>which by        nature give the security folks fits.

I like the "rumor" characterization.  I sometimes liken it to a
"whisper game".  (The "give the security folks fits" part is also
accurate as a depiction of the difficulty factor.)

--Sandy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jan 2005 14:01:17 -0500

Russ:
The RPSL protocol for the IRR had a authorization on the policy passed
(per RFC 2725).  It is possible to create something like the IRRs with
policy and delegation that can be used to handle authorization that
provides allocation policy. 

It is possible to go to IRRs as a source of "trusted bgp policy" on
aggregation or ownership of routes.  It is possible for this trust to be
given to the IRR and delegated from the IRR.

This hierarchical delegation can be called a transitive trust model or a
web of trust model.  

When you mean transitive trust, do you mean to:
	- exclude the IRR and RPSL mechanisms or
	- include the IRR and RPLS mechanisms?

Sue

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: Friday, January 21, 2005 11:36 AM
To: Sandy Murphy
Cc: [email-masked]
Subject: Re: [RPSEC] proposed message to the IESG

>> -- Overlapping address spaces exist.
>
> I don't know what you mean by this.  I get the mental image of the
same 
> address being used by two hosts, but surely that's not what's meant,
so 
> I'm guessing you mean that authorization for the same address space
can 
> overlap - that is, two organizations can be allocated the same address

> space.

In a sense, yes, and in a sense, no.

-- A is allocated 10.1.0.0/16.
-- A suballocates 10.1.1.0/24 to B.

IMHO, we care about routes, not updates, and routes contain prefixes.
One 
of the questions we can ask about those prefixes is: Is the originator 
authorized to advertise the address space in the route? In this case, A
can 
advertise 10.1.0.0/16, and the answer is yes, even though it actually 
contains 10.1.1.0/24, for which the answer is technically no.

So, in a sense, this address space, 10.1.1.0/24, is legally "owned" by
two 
entities within the system. Other than redoing the entire allocation 
scheme, or disallowing aggregation (forcing A not to advertise
10.1.0.0/16 
when it suballocates space out of it), I don't see how you get around
this 
problem.

It's certainly easier to just say: "We'll just worry about the path the 
update takes, and not worry about this problem. We'll assume that if
you're 
authorized to readvertise the update, you're authorized to transit for
this 
address space, and we'll also assume you're authorized to allow me to 
readvertise this address space."

IMHO, this sort of transitive trust can't exist within a routing system.
We 
need to focus on the questions we can ask, and base the requirements on 
them, rather than the process used to handle updates according to the
BGP 
specification.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Jan 2005 10:00:32 -0500

Bill and Tom:

I agree.  BGP as a protocol implemented in the world includes many
specifications.  (AS the IDR web page will attest to). 

BGP as an implemented protocol does include AS Confederations,
Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping. (etc).

Any plans to focus on a secure BGP that does not support current
operational BGP would find itself limited in it's deployment. 

Sue

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, January 26, 2005 8:19 PM
To: Tom Petch
Cc: Blaine Christian; Susan Hares; [email-masked]
Subject: Re: [RPSEC] proposed message to the IESG

> > " This specification covers only the exchange of IP version 4
network
> >    reachability information."
> >
> > Which seems to state that all the other uses for BGP are not covered
under
> > the draft.  Is that true?
> 
> Yes.
> 
> I think this is a key point.  Look hard and you will not find
Confederations,
> Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc
etc in
> this draft, all very valid aspects of BGP.  The aim of this draft does
not
> include those functions (although the relevant RFC are listed as
informative
> references with no references in this draft to them:-).
> 
> So is BGP security looking at the scope of BGP as defined in this
basic document
> (give or take some operator licence with prepending or aggregation);
or at the
> scope of BGP as defined in a much wider set of RFC and I-D?  If the
latter,
> which documents are included?

	it would seem best to stay tightly focused on the core spec,
	since new stuff is allowed (and used to be encouraged) to emerge
	to deal w/ changing situations... like the short list above!