Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I)

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2005 11:53:27 -0500

>	<SNIP>
>
>>Do you mean to say that correct BGP behavior allows an a speaker to 
>>originate a prefix when the AS in which the speaker operates is not 
>>the owner of the prefix nor has the owner authorized the 
>>advertisement in any fashion?
>
>Can you explain what you mean by "owner" here? The AS authorized to 
>advertise the prefix, or the AS authorized to advertise a superset 
>of that same address space (the aggregate)? If I "own" 10.1.0.0/16, 
>and I assign 10.1.1.0/24 to some other AS, may I still advertise 
>10.1.0.0/16? Or, must I break up the /16, and advertise 254 /24's, 
>now that I've given one of the address blocks within the /16 away?

If an AS 1 receives a /16 allocation, it can delegate a subset of 
that address space, e.g., a /24, to a subscriber. AS 1 need not break 
up its remaining address space into discrete blocks when it 
advertises it, but the subscriber to whom the /24 was delegated does 
need to explicitly authorize itself, or another AS, to originate the 
/24.

When I rea an earlier version of your individual submission I-D, it 
argued that this shows the inability of path advertisements to 
securely propagate info about who owns what.  But the arguments you 
present are fairly narrowly constructed, and I think they ignore the 
syste context that we both agree is an important element of a viable 
security solution. The missing piece of the puzzle, as you might say 
is that there is a need for every AS to be aware of the delegations 
that have taken place, so that traffic for a subscriber with the /24 
is not misrouted to AS 1, as it advertises the /16 that encompasses 
the /24.

>If you think about the answers to these questions, you'll see why 
>you cannot make the assumption you're making above.

On the contrary, having thought about the issues in detail, we 
engineered a solution that seems to address them.  We can argue about 
the viability of a particular solution approach when we are 
discussing such solutions, but at this stage of requirements 
development, we ought to focus on the the basis for security 
requirements more than on the viability of candidate approaches.

>>I think we all understand that there is a difference between 
>>forwarding and routing and thus propagation of a route does not 
>>ensure that traffic will flow over that route. However, the purpose 
>>of advertising a route to a neighbor is to make the neighbor aware 
>>that the advertiser is willing to accept traffic for the indicated 
>>prefixes, and that if such traffic is sent to the advertiser, then 
>>the traffic will be forwarded to the the indicated origin AS. 
>>That's what I believe is true, and your comment above in now way 
>>relates to the notion of
>
>That's specifically what's not true in a real routing system. Again, 
>if I advertise 10.1.0.0/16 with a path of {1, 2}, I'm implying that 
>traffic destined to 10.1.1.1 will "terminate" in AS 2. In fact, it 
>may terminate three or four or more AS hops away, there's no way to 
>tell at all where that traffic is going to terminate.
>
>The advertisement 10.1.0.0/16 {1, 2} actually implies AS 1 has a 
>path to 10.1.0.0/16 it learned from AS 2. It does not imply that AS 
>1 will use this path to forward traffic, nor does it imply that AS 2 
>has agreed to transit traffic to every possible destination within 
>10.1.0.0/16.
>
>>You still have not answered the question of what you mean by a path 
>>"existing." If you mean there are communication links between ASes, 
>>then say so. If you mean that there is local policy in each along 
>>the path that states that traffic for an indicated prefix will be 
>>forwarded to the origin AS if received from the indicated neighbor, 
>>say so.  If you mean something else, say so.
>
>I mean a logical path exists that corresponds to the as path listed 
>in the update. You cannot prove or imply policy along that path.
>
>>>-- Was the update actually originated by/forwarded along this path
>>>    (which only applies to some form of non-repudiation, and nothing else)?
>>
>>As I have said several times, apparently to no avail, this is not 
>>NR. But yes, I agree that this is a separable question from the 
>>bullet immediately above.
>
>Which is why I said "something like non-repudiation," since I don't 
>know of a better term to use in this context. But, I think we 
>understand what we are talking about, even if I'm using the wrong 
>term to describe it. :-)
>
>>>-- Am I authorized to use this path (outside the set of questions
>>>    answerable within BGP today)?
>>
>>I don't know what you are trying to say here.
>
>Exactly what it asks. Given the update 10.1.0.0/16 {1, 2}, am I 
>authorized to transmit traffic to the advertising peer (presumably 
>in AS 1) towards the destination 10.1.1.1? I contend you simply 
>cannot know the answer to that question. Given that same update, can 
>I know that traffic will follow the AS Path in the update to reach 
>10.1.1.1? I cannot know the answer to that question, either.

The BGP spec clearly says that a speaker receiving the advertisement 
in your example is authorized to send traffic for 10.1.1.1 to AS 1, 
absent any more specific advertisements that encompass 10.1.1.1 or 
any local policy that causes you to reject the advertisement. BGP 
also says that yes, that the proper interpretation of the 
advertisement in your example is that if you send traffic for the 
indicated NLRI to AS 1, it will forward the traffic to AS 2. We both 
know that there can be conditions that will cause this to not be 
true, but the BGP spec is very clear on how a speaker is supposed to 
interpret the path in a route.  In the memo I just prepared, I cite 
several passages from the spec that reinforce this. Are we to ignore 
this spec, which is about to become a full standard, as we develop 
security requirements that purport to be for BGP?

>
>>>Trying to munge all of this into a single requirement simply 
>>>muddies the problem, and takes away the designer's ability to 
>>>address them in various ways.
>>
>>the issue is not whether one can identify these as distinct 
>>questions that can be asked about a path or a route. The question 
>>we are addressing is what does BGP say about paths and routes, does 
>>IT ask these questions, and does it make the distinctions you have 
>>made above, when the BGP route computation algorithm is executed?
>
>Then you would restrict the available solutions to only those that 
>secure BGP as a bag of bits, rather than asking what it is that BGP 
>is trying to express, and securing the database as a database.

I am NOT focusing on the bits and ignoring the context in which they 
are interpreted. I think we both agree that the important thing to do 
is to secure BGP routing. I am focusing on what the BGP spec says are 
MUSTS/SHALLS and SHOULDS, as a starting point for security 
requirements. That seems to be the logical place to start. What I 
think you are doing is suggesting that one can articulate a set of 
requirements that are further abstracted from the protocol spec. That 
may be a viable approach, but if we pursue it, I think it is 
incumbent on you to show how the more abstract requirements encompass 
all the features that the protocol mandates and that are security 
relevant. Otherwise the more abstract requirements appear arbitrary.

>Again, I think the correct questions we should ask when writing the 
>requirements are:
>
>-- Can I prove a path exists?

we need a very precise definition of what these words mean. also, I'm 
not sure the word "prove" is ideal here.

>-- Can I prove I'm authorized to use the path?
>
>    (This question, in a sense, is a superset of the question: does every
>    AS along the path have policies set so they will pass traffic I forward
>    along this path to every possible destination within in the address
>    block carried in the update).

I almost agree with the initial wording, but your more detailed 
explanation makes me less comfortable. BGP distinguishes what an AS 
advertises vs. what is local data that need not be disclosed to other 
ASes. The wording above, because it includes local policy info, 
suggests that it requires disclosure of local info, and that does not 
like a suitable basis for a requirement.

>-- Can I prove traffic I forward along this path will actually use it?

"prove" definitely seems like a bad choice of term here. BGP does 
says that the proper interpretation of an advertisement is that the 
ASes along the path will forward traffic consistent with the NLRI 
along the advertised path. However, detecting whether traffic flows 
as advertised is outside the scope of BGP per se. Our security goal 
for BGP should be to provide speakers with the necessary mechanisms 
and infrastructure to enable them to verify the authorization or 
legitimacy (or whatever term we decide is appropriate here) of 
advertisements, so that when each speaker makes a decision on whether 
to accept a route, it does so with authorized/legitimate inputs. 
Given the autonomous nature of the routing system elements, this 
seems to be the best one can do from a preventative, vs. remedial, 
security perspective.

>
>If I can't prove one of these questions is answerable, then it makes 
>no sense to build a requirement for a given security system to prove 
>them, right?

Again, I don't "proof" is an appropriate term to be using here, so I 
can't agree with this statement.

Steve

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2005 12:38:01 -0500

At 10:52 AM -0500 12/29/04, Russ White wrote:
>>>We are clearly talking past each other. You are saying: "This is 
>>>the way BGP works, what BGP assumes." But, you're pushing into BGP 
>>>the concept of "authorization," which is a matter of policy, and 
>>>isn't part of BGP. Beyond this, you say "modulo aggregation." 
>>>That's a hole in the scheme large enough to drive a truck through, 
>>>honestly.
>>
>>BGP is a policy-driven system, Russ. The whole point of local 
>>policy databases is to enable an AS to impose its local policies on 
>>the route determination process, to down select from all the paths 
>>that physically exist, to the subset that each AS wants to 
>>advertise to other ASes. I'm sorry that you have an aversion to the 
>>word 'authorization" but it is implicit in the design of BGP.
>
>Again, we are clearly talking past each other. You're trying to 
>secure the BGP update as a bag of bits. I'm saying to look beyond 
>that bag of bits, and see what's in there. It doesn't matter if I've 
>securely transmitted a bag of bits from point a to point b, with all 
>the things in that bag intact.
>
>BGP doesn't operate that way. BGP operates on routing information. 
>Secure the routing information, not the process used to transmit the 
>routing information.

Lower layer security mechanisms do operate as you suggest, e.g., when 
one uses the TCP/MD5 checksum or IPsec for point to point security 
between a pair of speakers, they do see just a bag of bits. But I am 
not looking at the data in an Update message as bits w/o context. We 
are both trying to secure BGP in the larger context of a routing 
system.

I think the major difference in what you and I propose is based on 
different goals that are still consistent with securing routing as a 
system.  For example, I am emphasizing the need to verify Updates 
because BGP is defined largely in terms of the processing and 
generation of Updates. Thay also represent the means by which 
speakers learn what purports to be the realtime status of paths. So, 
if one wants to create an environment in which speakers have 
confidence in the realtime status of paths, vs. static information 
about Internet topology, one needs some means of securing Update 
processing.

In contrast, what I think you are trying to do is to bound the extent 
to which bogus Updates can differ from static topologies that 
represent a mix of extant links between ASes and local AS policies 
that determine what traffic can traverse which links. This goal would 
reduce the extent to which misconfiguration or an attack can 
adversely affect routing, but this strategy would still allow a 
speaker to accept as valid an Update that is not only not current, 
but maybe one that was never even generated by a legitimate speaker. 
That's a technically easier goal, but it yields a less secure 
outcome. Moreover, if there are practical issues re what information 
ASes have to disclose to achieve this more limited goal, then we may 
be facing just as hard a problem as if we try to enable speakers to 
verify Updates more precisely.

>>I say "modulo aggregation" not because I think we can ignore 
>>aggregation, but because it is easier to make concise statements 
>>about correct operation if one first omits aggregation. We 
>>certainly need to include it in the requirements and in solutions, 
>>but it's good practice to deal with the common, simple cases first, 
>>the move on to the harder ones.
>
>Aggregation is the common case. Aggregation is more common than 
>non-aggregation in the real world. You're subsituting "common" for 
>"simple." Yes, it's simpler to secure BGP without aggregation, but 
>if aggregation then proves the mechanism you've used to secure BGP 
>untrue, or makes certain claims non-provable, then you need to start 
>with aggregation, and work from there.

It has been a while since I looked at BGP data in detail, but when we 
examined Updates in detail a while ago, we saw very little 
aggregation, very little use of AS sets, etc.  Still, I agree with 
your point that any viable solution must accommodate aggregation. 
What I said was that it is easier to make simple, concise statements 
about the correctness of Updates w/o aggregation. That does not mean 
that one cannot make statements about Update correctness that 
accommodate aggregation. The statements just tend to become more 
complex.

>
>>There is no question that, when legitimate aggregation occurs, the 
>>path contained in the Update no longer contains all of the ASes 
>>that were present prior to aggregation. So, yes, it is accurate to 
>>say that the path seen by ASes past the aggregation point omits 
>>some of the ASes that were in the path prior to aggregation. But 
>>your claim that this proves your point that the aggregated path 
>>does not exist, is not true.
>
>*sigh*
>
>Steve, when I send routing information, I'm not sending an update. 
>I'm sending a prefix and a set of attributes. BGP will unbundle 
>these, and send them, in a possibly different form, to a set of 
>peers. You're applying security to the wrong part of the process.

Russ, when you use BGP to send routing info you do it only via an 
Update. The way an Update is processed to effect changes in the 
Adj-RIBN-In and maybe in the Loc-RIB, which in turn may cause an 
Update to be emitted, is dictated by the BGP spec, in a very details, 
three phase algorithm. The spec indicates what values from the 
received Update are used in updating these RIBs and it places 
constraints on how new Updates are created, based on the contents of 
the RIBs. It does not say that a speaker can cobble together a new 
Update in an arbitrary fashion. For example, if an attribute is 
defined as transitive, then the values in it are propagated in an 
Update that is generated based on the RIB entry that was updated 
using the attribute. There are complex rules describing how route 
aggregation is to be performed, and a mandatory, minimum algorithm 
for performing aggregation.

>I don't see any way to solve this argument. You will always treat 
>BGP as a bag of bits, and I will always look beyond the bag of bits 
>at how routing works, in the real world.

Russ, please do not engage in personal attacks in this technical 
debate. It's both offensive and inaccurate for you to assert that you 
know how I view BGP security, in a pejorative fashion, while claiming 
the technical high ground for your perspective.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2005 12:54:20 -0500

Folks

I made a pass through the current version of 
BGP-4, the document that is about to be published 
as a full standard. I tried to extract quotes 
that deal with what I see as significant security 
issues for BGP, based on what the spec says are 
MUSTS/SHALLS and, in some cases, SHOULDS. I do 
have a couple of questions in this memo, areas 
where I as not quite sure what the spec means, of 
where I am not certain how implementations have 
chosen to deals with some subtle aspects of the 
spec.  I'm looking for feedback on this memo, as 
a way of making progress  on some of the issues 
that Russ and I have been debating.

In the Abstract:

The primary function of a BGP speaking system is 
to exchange network reachability information with 
other BGP systems. This network reachability 
information includes information on the list of 
Autonomous Systems (ASs) that reachability 
information traverses. This information is 
sufficient to construct a graph of AS 
connectivity for this reachability from which 
routing loops may be pruned and some policy 
decisions at the AS level may be enforced.

To me this says that BGP embodies the notion that 
an Update nominally traverses the path that it 
contains, although we all agree that there will 
be exceptions, e.g., due to path aggregation.

Later the abstract says:

BGP-4 also introduces mechanisms which allow 
aggregation of routes, including aggregation of 
AS paths.

This is an explicit declaration of route 
aggregation, and an indirect mention of address 
aggregation.

In the Summary of Operation section (3.1) of the document:

In the context of this document we assume that a 
BGP speaker advertises to its peers only those 
routes that it itself uses (in this context a BGP 
speaker is said to "use" a BGP route if it is the 
most preferred BGP route and is used in 
forwarding). All other cases are outside the 
scope of this document.

This text states what it claims is the 
association between routes that a speaker 
advertises and the forwarding function that the 
speaker performs. Your gave an example of an AS 
advertising a route that contains an AS set 
constructed to cause another AS to reject the 
route. In that case I think you said that one of 
more AS set elements was artificially introduced 
to influence those ASes from accepting the route. 
This would seem to violate this part of the BGP 
spec, since the AS advertising this route does 
not "use" (forward traffic via) the indicated 
route, right?

In Section 4.3, the definition of the UPDATE 
message format, in describing the AS-PATH, the 
text says:

The path segment type is a 1-octet long field 
with the following values defined:

      Value      Segment Type

        1         AS_SET: unordered set of ASs a route in the
                     UPDATE message has traversed

        2         AS_SEQUENCE: ordered set of ASs a route in
                     the UPDATE message has traversed

Note that for both AS sequences and for AS sets, 
the specs says that they refer to a route that 
the UPDATE has traversed. This is why I have 
emphasized the need for the security requirements 
document to include this, i.e., the spec 
explicitly says that this is how BGP is supposed 
to work. Yes, we know that there are exceptions 
to this general rule, but this text suggests 
that, to first order, there should be a simple, 
verifiable relationship between an advertised AS 
path and the path traversed by the UPDATEs that 
contributed to the creation of the path.

MED is defined here as well, and it is 
non-transitive. That means that BGP security need 
not worry about imposing any transitive security 
measures to protect this attribute.

AGGREGATOR is defined here. It is transitive, and 
identifies the last AS (and the BGP speaker in 
that AS) that formed an aggregate route contained 
in an UPDATE.

Note that the text discusses inclusion of 
multiple destinations in the NLRI of one UPDATE, 
saying:

An UPDATE message can advertise at most one set 
of path attributes, but multiple destinations, 
provided that the destinations share these 
attributes. All path attributes contained in a 
given UPDATE message apply to all destinations 
carried in the NLRI field of the UPDATE message.

This says that an AS violates the spec if, for 
example, it includes prefixes in the NLRI that 
are not reachable via the path in the UPDATE. 
However, it does not state that all of the 
destinations contained in an advertised prefix 
are reachable via the advertised path. This is 
because subsets of address blocks are often 
further delegated. I think there is an implicit 
statement here that an AS must become aware of 
the delegation (e.g., via receipt of an 
advertisement from an AS representing the 
delegated subsets, or via static configuration 
info) in order to properly route/forward traffic 
for such destinations. Section 9.1.4 discusses 
the issue of overlapping routes and says:

The set of destinations described by the overlap 
represents a portion of the less specific route 
that is feasible, but is not currently in use. 
If a more specific route is later withdrawn, the 
set of destinations described by the overlap will 
still be reachable using the less specific route.

To me this says that, absent knowledge of a more 
specific route, a speaker should route traffic 
based on its knowledge of a less specific route, 
which is the only thing it can do under those 
circumstances. This seems to leave open the 
possibility of configuring a speaker so that even 
if no feasible route to a more specific prefix is 
advertised, the speaker can choose to not use the 
less specific route. For example that is what one 
would want a speaker to do if the speaker knew 
that the more specific prefix were originated by 
a neighbor with no connections to other ASes. So, 
a combination of configuration info and UPDATE 
processing is needed to prevent misrouting of 
traffic for more specific prefixes, in general.

In section 5, the text says:

Once a BGP peer has updated any well-known 
attributes, it MUST pass these attributes in any 
updates it transmits to its peers.

This says clearly that path attributes are 
transitive, passing from Adj-RIB-In to Loc-RIB to 
Adj-RIB-Out. It does not say that a speaker can 
arbitrarily modify the attributes received via an 
UPDATE when the speaker generates a new UPDATE 
based on that input.

In 5.1.2 the text restates the notion that the AS 
path in an UPDATE has traversed the ASes listed 
in the path:

AS_PATH is a well-known mandatory attribute. This 
attribute identifies the autonomous systems 
through which routing information carried in this 
UPDATE message has passed.

This section also describes how a speaker is 
supposed to modify the AS path data from a 
received UPDATE, by adding its own AS number to 
the sequence as the last element, when sending an 
UPDATE to an external BGP peer. If the speaker 
originates a route, then is creates a new AS path 
with its own AS number as the only element. 
(Note that this text does not allow an originator 
to create an AS set as the last element.) The end 
of this subsection explicitly allows for adding 
multiple instances of the ASes own number; this 
is not seen by the spec as conflicting the notion 
of the UPDATE having traversed the path it 
contains, e.g., indicating a loop.

Section 5.1.6 discuses the atomic aggregate 
attribute, and how it is used when an speaker 
aggregates routes. The text states that a speaker 
MUST NOT make any of the advertised prefixes in 
the NLRI more specific, which seems like a good 
candidate for security requirements relative to 
UPDATEs that contain this attribute.

The text also notes that inclusion of this 
attribute creates an exception to the general 
rule that the path in an UPDATE reflects the path 
that the UPDATE traversed:

A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be aware of the fact that the 
actual path to destinations, as specified in the 
NLRI of the route, while having the loop-free 
property, may not be the path specified in the 
AS_PATH attribute of the route.

To me this says that, except where noted by the 
BGP spec, the security requirements should make 
it a goal to be able to check that the advertised 
path is the one traversed by the UPDATE. Later, 
section 9.1.4 seems to suggest that use of this 
attribute is now discouraged. If so, then we have 
fewer reasons for paths in UPDATEs to deviate 
from the paths the UPDATEs traversed. If not, 
then we have an explicit indicator of aggregation 
and an associated check to make.

Section 5.1.7 discusses the Aggregator attribute, 
but this attribute is optional, so security 
requirements can address it, but only in terms of 
"if present Š"

Section 9 describes UPDATE message handling. It 
defines the algorithm that says how a speaker 
processes received UPDATEs, when the "Decision 
Process" is executed, and how UPDATEs are 
constructed when the decision process calls for 
emitting an UPDATE.

Text at the beginning of this section requires 
that all (optional, mandatory, and discretionary) 
transitive attributes be "retained for 
propagation to other BGP speakers." This 
reinforces the notion that UPDATEs emitted by a 
speaker are constructed by taking received 
UPDATEs received by the speaker and processing 
them as specified in this section.

Section 9.1 describes the Decision Process, i.e., 
the three phase algorithm that selects routes for 
advertisement to peers (and for internal use). It 
uses the Adj-RIB-Ins and the PIB as inputs, the 
Loc-RIB as the intermediate database, and the 
Adj-RIB-Outs as the target databases that act as 
drivers of Updates sent to specific peers. It 
includes a description of how and when a speaker 
may choose to perform aggregation.

The text notes that "It is critical that BGP 
speakers within an AS do not make conflicting 
decisions regarding route selection that would 
cause forwarding loops to occur." The proposed 
security requirements goal of partial deployment 
of a BGP security solution within a single AS may 
run afoul of this warning; speakers running the a 
secure BGP implementation may reach different 
decisions from ones running "vanilla" BGP in the 
same AS. That's why I suggested that we not make 
it a requirement to be able to deploy a BGP 
security solution incrementally within an AS.

Section 9.1.4 describes how a speaker deals with 
overlapping routes, a topic we have discussed on 
numerous occasions. It explicitly allows a 
speaker to aggregate a more and a less specific 
route into a single advertisement, if both routes 
have the same next hop. If an aggregated route is 
advertised, there are two choices:
-	include all ASes used to form the aggregate in an AS set
-	add the atomic aggregate attribute to the route

The text advises that the atomic aggregate 
attribute is informational, given the current 
state of CIDR support, and I interpret this to 
mean that the first option is the one that is 
most commonly employed. Is that true? If so, then 
all the ASes involved in forming the aggregate 
are present and can be used in verifying the 
legitimacy of the aggregation. If not, then the 
atomic aggregate attribute should be present and 
at least it serves as an explicit flag to say 
that the advertised route is an exception to the 
general rule.

It is not clear from the spec what checks a 
speaker can/should perform for a route flagged 
with this attribute, and the text makes it clear 
that this is a case in which the path in the 
UPDATE is not necessarily representative of the 
path via which the contributing UPDATEs flowed. 
Still, there is an obvious security-relevant 
check that this text describes, i.e., a speaker 
is expressly prohibited from deaggregating NLRI 
that appears in a route with the atomic aggregate 
attribute.

Section 9.2.2.1 and 9.2.2.2 discusses aggregation 
of NLRI and AS path data, with most of the 
details in the latter section. The wording re 
NLRI aggregation is a bit vague:

In cases where there is a correspondence between 
the address structure and the systems under 
control of an autonomous system administrator, it 
will be possible to reduce the size of the NLRI 
carried in the UPDATE messages.

Does this mean anything other than a speaker can 
be configured to aggregate prefixes when the AS 
operator is responsible for the component 
prefixes, and if they are "adjacent" in the 
address space? Does anyone have a clearer 
statement of this that can be traced to previous 
versions of to other RFCs?

The rules for aggregating routes are complex and 
I'm not sure I understand them completely. The 
easiest case is when two routes learned by a 
speaker for different NLRI have exactly the same 
path. In that case one can construct a new route 
that includes the NLRI from both routes. When 
combining routes with different path attributes, 
but the same NLRI, I think the rules say that the 
path advertised as a result of aggregation must 
satisfy the following criteria
-	every AS that appears in the resulting 
aggregated path must appear in all of the routes 
that contributed to the aggregated route.
-	all AS sets in the result must appear in 
at least one of the paths that was aggregated, 
and no duplicate AS sets can appear in the 
aggregated route.
-	the order of every pair of individual 
ASes (sequence elements, not sets) in the result 
does no violate the ordering of these ASes in any 
of the paths that were aggregated and where they 
were present.
-	an individual AS may be replicated in the 
aggregated route only if the copies are adjacent 
(i.e., no loops can be introduced).

There are additional rules about how to deal with 
the atomic and aggregator attributes if present 
in any of the routes to be aggregated. These 
rules for route aggregation appear to provide 
more precise constraints than in section 9.1. I 
suggest that our security requirements call for 
measures to enforce these rules, since BGP goes 
to such great length to specify them.

The subsection ends with an algorithm that 
conforms to the rules, and another algorithm is 
presented in appendix F.6. I have a question: Do 
BGP implementations use these algorithms, or is 
there diversity in the ways that aggregated 
routes are constructed, in practice?

Section 9.4 briefly describes route origination, 
but it does not see to provide useful constraints 
that we can employ in developing security 
requirements. It primarily refers to IGP-acquired 
routes, which are outside the scope of BGP 
security measures.
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2005 12:49:31 -0500

At 10:58 AM -0500 12/29/04, Russ White wrote:
>>>-- The wording I've suggested will allow soBGP, S-BGP, IRV, and 
>>>SPV to meet them, I think.
>>
>>In contrast, what I see in your wording is explicitly designed to 
>>accommodate only soBGP!
>
>In other words, you believe that S-BGP doesn't prove the things I've 
>suggested as requirements?

I didn't say that. I have not tried to see if your characterization 
of requirements is one that can be satisfied by S-BGP. What concerns 
me is that, in many cases, the proposed requirements are not directly 
traceable to the BGP specs, and they do seem to match the model 
adopted by soBGP.

>What I believe is this: The requirements, as I've suggested them, 
>and as the current draft reads, can be met by S-BGP, IRV, SPV, and, 
>by chance, soBGP, as well. You're claim is that you can get "more 
>security" than what's in the current draft, and in my wording.

SPV parallels S-BGP in many ways, so it is probably fair to say that 
both would be able to meet similarly stated requirements, except when 
one considers performance issues.  IRV seems analogous parallel to 
soBGP, and so the same statement can probably be made for that pair 
or proposals. But, the best answers to the question of 
solution/requirements compatibility probably will come from the 
proponents of each approach, not from others.

My observation is that some of the proposed requirements appear to be 
solution-motivated, rather than being derived from the BGP spec. For 
example, BGP has no notion of a reference topology that reflects 
"valid" routes on a global scale and that can be accessed by speakers 
to determine whether to accept a route in an Update. BGP does allow 
for local policy filters, but these are intended to reflect locally 
known topology info, something that is feasible for each AS to know 
about it's neighbors. So, my complaint about some of the requirements 
is that they seem to favor specific solutions or classes of solutions 
rather than being solution neutral and derived from the BGP spec 
itself.

>My counter to this is your claim for "more security" falls apart 
>when you consider the way routing really works, including 
>aggregation. Your counter claim is that aggregation doesn't 
>matter--secure the process, not the data, because, magically, 
>securing the process always secures the data.

Russ, I did NOT say that aggregation does not matter. Of course it 
does. What I said was that the simplest characterization of Udate 
validity does not accommodate some forms of aggregation. That does 
not mean that one cannot provide more complex statements of validity 
that do capture the various forms of aggregation.

>I know which I prefer--secure the data, not the process. Secure the 
>data with the reality of aggregation in mind, with the way the 
>protocol is implemented and deployed as fundamental assumptions.

There is certainly merit in the notion of ensuring the accuracy of 
the data, irrespective of the process by which the accuracy is 
established.  If we can find a way to express that, without favoring 
one solution technology over another then I concur. But, the text 
proposed so far does not do that, in my opinion. I think that the BGP 
spec needs to be the basis for security requirements for BGP.

>The wordings I've suggested allow any security system proposed to 
>claim "more security in specific case x," and it also leaves the 
>community free to evaluate that claim of "more security" in light of 
>the real world. I believe this is an acceptable compromise position, 
>in the long run, and the only way these drafts will move forward.

I'm all in favor of moving forward, and compromise is sometime the 
only way to do that. But the current text is unacceptable, for the 
reasons I cited above.

>
>Would you like to move forward, or stay in the same argument for the 
>rest of forever?

What I would like is to see proposed requirements that are traceable 
to the BGP spec and that do not favor any specific solution 
technology. To that end I have prepared a memo based on the latest 
BGP I-D (the one about to be issued as the full standard version RFC 
for BGP), which tries to capture security-relevant requirements from 
the text, and to relate them to some of the discussions we have been 
having.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 5 Jan 2005 15:47:06 -0500 (Eastern Standard Time)

> What I would like is to see proposed requirements that are traceable to 
> the BGP spec and that do not favor any specific solution technology. To 
> that end I have prepared a memo based on the latest BGP I-D (the one 
> about to be issued as the full standard version RFC for BGP), which tries 
> to capture security-relevant requirements from the text, and to relate 
> them to some of the discussions we have been having.

In other words, the only acceptable solution, to you, is to secure the 
process, and hope the data is magically secured by securing the process.

The requirements should state what information must be verifiable, and in 
what way, for the system to be considered secure. I've tried to give 
several examples of this, but you either don't understand them, or move the 
discussion directly back to soBGP vs S-BGP, which I've completely avoided 
in all the phases here. For instance, if you were considering credit card 
information, would you consider securing the data--the siganture, the 
authorization, and the card number, etc.? Or would you consider securing 
the process--the paper the reciept is on, the color of the signing pen, 
etc?

I would take the description of the system, as it operates, attempt to pull 
out the data that needs ot be secured, and then write a set of requirements 
around that data. You are, on the other hand, saying the only legitimate 
security is that which "follows the processing of the original 
information," without reference to the information itself.

As long as we talk past each other, we will never get past this 
disagreement. You either have to look at a security system as trying to 
secure the data within the system, or securing the process of handling that 
data.

It seems to me that you would rathe focus on one--securing the 
process--over the over--securing the data--simply because it fits the model 
of the security solution you've already proposed. I prefer the one that 
allows the maximum flexibility in designing any given security system, and 
letting operators and designers determine their own tradeoffs when 
designing and deploying a solution at some point in the future.

:-)

Russ

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jan 2005 23:09:06 +0100

On 5-jan-05, at 18:54, Stephen Kent wrote:

>> The primary function of a BGP speaking system is to exchange network 
>> reachability information with other BGP systems. This network 
>> reachability information includes information on the list of 
>> Autonomous Systems (ASs) that reachability information traverses.

> To me this says that BGP embodies the notion that an Update nominally 
> traverses the path that it contains

It "contains information on", which isn't exactly the same thing.

> although we all agree that there will be exceptions, e.g., due to path 
> aggregation.

Not sure if we agree on this... (See below)

>> BGP-4 also introduces mechanisms which allow aggregation of routes, 
>> including aggregation of AS paths.

Yuck! Is this supposed to be an update of RFC 1771? At the very least 
they should remove implicit references to BGP3!?!

>> In the context of this document we assume that a BGP speaker 
>> advertises to its peers only those routes that it itself uses (in 
>> this context a BGP speaker is said to "use" a BGP route if it is the 
>> most preferred BGP route and is used in forwarding). All other cases 
>> are outside the scope of this document.

> This text states what it claims is the association between routes that 
> a speaker advertises and the forwarding function that the speaker 
> performs. Your

You = ?

> gave an example of an AS advertising a route that contains an AS set 
> constructed to cause another AS to reject the route. In that case I 
> think you said that one of more AS set elements was artificially 
> introduced to influence those ASes from accepting the route. This 
> would seem to violate this part of the BGP spec, since the AS 
> advertising this route does not "use" (forward traffic via) the 
> indicated route, right?

Is there a definition of "route"? I think it means "NLRI + path 
attributes", in which case there is no violation. (At least not on the 
router level; it's not impossible that an AS advertises a certain route 
but packets follow another.)

> Note that for both AS sequences and for AS sets, the specs says that 
> they refer to a route that the UPDATE has traversed. This is why I 
> have emphasized the need for the security requirements document to 
> include this, i.e., the spec explicitly says that this is how BGP is 
> supposed to work.

I think this type of aggregation is obsolete. I don't follow IDR, but I 
believe their mission here is to describe the current situation, and 
since this stuff is out there they can't remove it. However, IMNSHO it 
would be a huge mistake to address this stuff in a secure version of 
BGP since it means tons of headaches for something that nobody (for a 
very large class of "nobody") uses. (Might be good to scan the global 
routing table for AS sets and atomic aggregates, though.)

>> An UPDATE message can advertise at most one set of path attributes, 
>> but multiple destinations, provided that the destinations share these 
>> attributes. All path attributes contained in a given UPDATE message 
>> apply to all destinations carried in the NLRI field of the UPDATE 
>> message.

> This says that an AS violates the spec if, for example, it includes 
> prefixes in the NLRI that are not reachable via the path in the 
> UPDATE.

Why would anyone advertise reachability for unreachable destination 
NLRI? Not that advertisement guarantees reachability.

>> The set of destinations described by the overlap represents a portion 
>> of the less specific route that is feasible, but is not currently in 
>> use.

??? No idea what this means...

> This seems to leave open the possibility of configuring a speaker so 
> that even if no feasible route to a more specific prefix is 
> advertised, the speaker can choose to not use the less specific route.

How? The only way this could happen is if there is a packet filter or a 
non-BGP route that gets in the way. Both are outside the scope.

> For example that is what one would want a speaker to do if the speaker 
> knew that the more specific prefix were originated by a neighbor with 
> no connections to other ASes. So, a combination of configuration info 
> and UPDATE processing is needed to prevent misrouting of traffic for 
> more specific prefixes, in general.

How is BGP supposed to know this stuff? And how are other ASes supposed 
to evaluate this AS' claims? Doesn't make sense. You advertise, you 
route untill you hit a directly connected interface (which could be 
null0 of course).

> Section 5.1.6 discuses the atomic aggregate attribute, and how it is 
> used when an speaker aggregates routes. The text states that a speaker 
> MUST NOT make any of the advertised prefixes in the NLRI more specific

(remember this)

> The text notes that "It is critical that BGP speakers within an AS do 
> not make conflicting decisions regarding route selection that would 
> cause forwarding loops to occur."

Critical is an understatement.

> The proposed security requirements goal of partial deployment of a BGP 
> security solution within a single AS may run afoul of this warning; 
> speakers running the a secure BGP implementation may reach different 
> decisions from ones running "vanilla" BGP in the same AS. That's why I 
> suggested that we not make it a requirement to be able to deploy a BGP 

I'm not sure if that's reasonable. (Ever try to upgrade an AS with 600 
routers?) Mandating AS-level flag days also isn't necessary, I don't 
think: the requirement here is that routers don't select CONFLICTING 
routes. It is perfectly legal for one router to reject routes another 
router wants to use. So the secure routers simply use a smaller subset 
of all possible routers (the verifiable ones).

So if router A is secure and sees paths 1 and 3, and router B is 
insecure and sees path 2, with path 1 being the worst and path 3 being 
the best, and only path 1 is verifiable, A will select path 1 (2 and 3 
aren't secure) but B will select 2 because it is "better" than 1. B 
would ideally select 3, but this isn't allowed because that would 
create a loop. It's also something that can't happen because A only 
sends 1 to B as 1 is the one it uses itself.

> If an aggregated route is advertised, there are two choices:

Don't feel like looking it up, but isn't it both rather than either?

>> In cases where there is a correspondence between the address 
>> structure and the systems under control of an autonomous system 
>> administrator, it will be possible to reduce the size of the NLRI 

If you say so... Not sure what they're getting at.

> The rules for aggregating routes are complex and I'm not sure I 
> understand them completely.

I think the part that you're overlooking is that all of this is nothing 
more than a way for BGP4 and BGP3 to coexist. In order to gain the CIDR 
benefits before the very last AS is upgraded to BGP4, BGP4 
implementations can aggregate routes that are sourced by a BGP3 AS. So 
if AS X has 192.0.0.0/20 but they run BGP3 so they announce 16 /24s, AS 
Y can turn this into a single CIDR route. Conversely, CIDR routes can 
be broken down into classful routes for BGP3 consumption. Since the 
aggregation wreaks havoc on the AS path, an AS_SET is added that 
includes all the ASes that aren't in the new path, and the 
ATOMIC_AGGREGATE attribute is added to make sure the CIDR route isn't 
broken down into a bunch of classful routers with a now shorter AS 
path. (The more specifics with short AS paths would suck all the 
traffic away from the real destination.)

All of this is COMPLETELY obsolete. I believe these mechanisms are 
still in use to aggregate intra-AS routes (which isn't really 
appropriate) but if anyone is using this inter-AS, I don't see how they 
can be doing something legit.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2005 18:40:25 -0500

At 11:09 PM +0100 1/5/05, Iljitsch van Beijnum wrote:
>>>The primary function of a BGP speaking system is to exchange 
>>>network reachability information with other BGP systems. This 
>>>network reachability information includes information on the list 
>>>of Autonomous Systems (ASs) that reachability information 
>>>traverses.
>
>>To me this says that BGP embodies the notion that an Update 
>>nominally traverses the path that it contains
>

You're right that the wording is slightly different here, but later 
parts of the document make precisely the statement I made, so I don't 
feel too bad about this one example not being perfectly aligned. 
Anyway, how would you characterize "contains information on?"

>
>>although we all agree that there will be exceptions, e.g., due to 
>>path aggregation.
>

OK, I'll read on ...

>
>>>BGP-4 also introduces mechanisms which allow aggregation of 
>>>routes, including aggregation of AS paths.
>
>Yuck! Is this supposed to be an update of RFC 1771? At the very 
>least they should remove implicit references to BGP3!?!

Hey, it's not my document :-)
>>>this context a BGP speaker is said to "use" a BGP route if it is 
>>>the most preferred BGP route and is used in forwarding). All other 
>>>cases are outside the scope of this document.
>
>>This text states what it claims is the association between routes 
>>that a speaker advertises and the forwarding function that the 
>>speaker performs. Your
>
>You = ?

sorry, the "your" here refers to Russ. When I started to assemble the 
memo it was in response to one of Russ's messages.  Then, at the end, 
I decided to send it as a separate message to the list.

>
>>gave an example of an AS advertising a route that contains an AS 
>>set constructed to cause another AS to reject the route. In that 
>>case I think you said that one of more AS set elements was 
>>artificially introduced to influence those ASes from accepting the 
>>route. This would seem to violate this part of the BGP spec, since 
>>the AS advertising this route does not "use" (forward traffic via) 
>>the indicated route, right?
>
>attributes", in which case there is no violation. (At least not on 
>the router level; it's not impossible that an AS advertises a 
>certain route but packets follow another.)

yes, a route is NLRI plus path info. We agree that it is possible 
that the path taken by traffic will diverge from the advertised 
route, but the cited text in the BGP spec says that this should not 
be the case. certainly the text in the spec does not condone 
advertising a route with bogus AS entries as a means of preventing 
some AS from accepting the route.

>
>>Note that for both AS sequences and for AS sets, the specs says 
>>that they refer to a route that the UPDATE has traversed. This is 
>>why I have emphasized the need for the security requirements 
>>document to include this, i.e., the spec explicitly says that this 
>>is how BGP is supposed to work.
>
>I think this type of aggregation is obsolete. I don't follow IDR, 
>but I believe their mission here is to describe the current 
>situation, and since this stuff is out there they can't remove it. 
>However, IMNSHO it would be a huge mistake to address this stuff in 
>a secure version of BGP since it means tons of headaches for 
>something that nobody (for a very large class of "nobody") uses. 
>(Might be good to scan the global routing table for AS sets and 
>atomic aggregates, though.)

After sending the message I asked a colleague to look at 2004 RV data 
and see how often the atomic aggregate and aggregator attribute shows 
up.  The answer, based on examining about 3 months of data (so far) 
is that about 6-8% of the Updates had the atomic attribute and 7-9% 
had aggregator. So about 14-16% of all Updates had one or the other 
form of aggregation indicated.

RPSEC and IDR are both in the routing area, not the operations area. 
So, I do think that the BGP spec is the appropriate starting place 
for a security requirements document that says it is for BGP.

>
>>>An UPDATE message can advertise at most one set of path 
>>>attributes, but multiple destinations, provided that the 
>>>destinations share these attributes. All path attributes contained 
>>>in a given UPDATE message apply to all destinations carried in the 
>>>NLRI field of the UPDATE message.
>

I  was just noting some things that BGP explicitly says are no-nos 
and thus things that we should consider as security requirements.

>
>>>The set of destinations described by the overlap represents a 
>>>portion of the less specific route that is feasible, but is not 
>>>currently in use.
>

This is the text from the spec, and I too thought it was less than 
crystal clear.

>
>>This seems to leave open the possibility of configuring a speaker 
>>so that even if no feasible route to a more specific prefix is 
>How? The only way this could happen is if there is a packet filter 
>or a non-BGP route that gets in the way. Both are outside the scope.

Right. But people do use filters (or local policy, or whatever one 
chooses to call it) to protect themselves against such errors or 
attacks, don't they? BGP does make explicit provision for such local 
overrides of BGP-supplied routes and so it does seem reasonable, from 
a system security perspective, to consider what can be done to 
provide info in a secure fashion to facilitate configuring these 
policies. I think this is a big part of what Russ has advocated, and 
I agree that there is a need for such data in security solutions. 
It's just a matter of the extent to which such data is relied upon, 
and how one ensures its accuracy./.

>
>>For example that is what one would want a speaker to do if the 
>>speaker knew that the more specific prefix were originated by a 
>>neighbor with no connections to other ASes. So, a combination of 
>>configuration info and UPDATE processing is needed to prevent 
>>misrouting of traffic for more specific prefixes, in general.
>
>How is BGP supposed to know this stuff? And how are other ASes 
>supposed to evaluate this AS' claims? Doesn't make sense. You 
>advertise, you route untill you hit a directly connected interface 
>(which could be null0 of course).

Again, I think this falls under the heading of local policy/filter 
data. The IRR model is designed to provide data of this sort, but it 
lacks suitable security controls to make it as reliable as one would 
want, i think.

>
>>Section 5.1.6 discuses the atomic aggregate attribute, and how it 
>>is used when an speaker aggregates routes. The text states that a 
>>speaker MUST NOT make any of the advertised prefixes in the NLRI 
>>more specific
>
>(remember this)
>
>>The text notes that "It is critical that BGP speakers within an AS 
>>do not make conflicting decisions regarding route selection that 
>>would cause forwarding loops to occur."
>
>>The proposed security requirements goal of partial deployment of a 
>>BGP security solution within a single AS may run afoul of this 
>>warning; speakers running the a secure BGP implementation may reach 
>>different decisions from ones running "vanilla" BGP in the same AS. 
>>That's why I suggested that we not make it a requirement to be able 
>>to deploy a BGP security solution incrementally within an AS.
>
>I'm not sure if that's reasonable. (Ever try to upgrade an AS with 
>600 routers?) Mandating AS-level flag days also isn't necessary, I 
>don't think: the requirement here is that routers don't select 
>CONFLICTING routes. It is perfectly legal for one router to reject 
>routes another router wants to use. So the secure routers simply use 
>a smaller subset of all possible routers (the verifiable ones).

if one were deploying security software in an AS, one could first 
deploy it to al the routers, but not enable use of th security 
features until it was fully deployed. I admit to having never 
configured ANY router. However, when BBN ran the Arpanet and the 
Defense Data Network, we updated packet switch software remotely, in 
each switch in the net, then turned on new features in all of them, 
via remote management, in a very short time.  Admittedly those nets 
were 200+ switches, not 600, but the principle was the same, i.e, 
tolerating transient routing instability in a net during the time it 
takes to turn on the new features.

Still, you are right that if one could ensure that the security 
software selected a subset of the routes being used by the other 
routers, that would not conflict with the requirement I cited.

>insecure and sees path 2, with path 1 being the worst and path 3 
>being the best, and only path 1 is verifiable, A will select path 1 
>(2 and 3 aren't secure) but B will select 2 because it is "better" 
>than 1. B would ideally select 3, but this isn't allowed because 
>that would create a loop. It's also something that can't happen 
>because A only sends 1 to B as 1 is the one it uses itself.

I didn't follow your example in detail. I am willing to believe that 
partial deployment within an AS might be OK, but I do worry that 
there are a lot of ways for it to fail.

>If you say so... Not sure what they're getting at.

this is another puzzling piece of text, and it's one that I really do 
want to better understand.

>I think the part that you're overlooking is that all of this is 
>nothing more than a way for BGP4 and BGP3 to coexist. In order to 
>gain the CIDR benefits before the very last AS is upgraded to BGP4, 
>BGP4 implementations can aggregate routes that are sourced by a BGP3 
>AS. So if AS X has 192.0.0.0/20 but they run BGP3 so they announce 
>16 /24s, AS Y can turn this into a single CIDR route. Conversely, 
>CIDR routes can be broken down into classful routes for BGP3 
>consumption. Since the aggregation wreaks havoc on the AS path, an 
>AS_SET is added that includes all the ASes that aren't in the new 
>path, and the ATOMIC_AGGREGATE attribute is added to make sure the 
>CIDR route isn't broken down into a bunch of classful routers with a 
>now shorter AS path. (The more specifics with short AS paths would 
>suck all the traffic away from the real destination.)
>
>appropriate) but if anyone is using this inter-AS, I don't see how 
>they can be doing something legit.

I was not aware of the backwards compatibility motivation you cite 
for the rules. Also, the statistics I noted above on how often atomic 
still appears in Updates suggest that there are a number of operators 
who may not realize why the attribute is no longer needed.

Without your explanation of the context, the rules seemed 
appropriate, i.e., they seem to state reasonable constraints on how 
to construct an aggregated route given various routes as inputs. Are 
you saying that there are no constraints now on how a speaker is 
supposed to create an aggregated route from the routes a speaker 
receives from its peers?

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 5 Jan 2005 19:23:35 -0500 (Eastern Standard Time)

> yes, a route is NLRI plus path info. We agree that it is possible that 
> the path taken by traffic will diverge from the advertised route, but the 
> cited text in the BGP spec says that this should not be the case. 
> certainly the text in the spec does not condone advertising a route with 
> bogus AS entries as a means of preventing some AS from accepting the 
> route.

What you've not acknowledged is the problem is more extensive than this. 
The NLRI in the udpate is also aggregated, and the aggregate may contain 
information about routes the originator of the aggregate does not have 
authorization to advertise.

The problem is, you want this: If you assign a prefix to someone else, they 
should always advertise that longer prefix past any possible aggregation.

In the real world, this is false. The _point_ of aggregation is for this 
not to be true.

> RPSEC and IDR are both in the routing area, not the operations area. So, 
> I do think that the BGP spec is the appropriate starting place for a 
> security requirements document that says it is for BGP.

This is a non-sequitor. There are many paths to security, only one of which 
involves securing the process by which information is handled.

Based on your statement, the routing area must never consider the 
application of any protocol it is involved in. Rather, it's all a matter of 
algorithms and packet descriptions, and no question of application, 
deployment, or implementation should enter into the discussion. However, if 
you actually look at the requirements for a protocol to become a standard, 
at least three documents are required:

-- A protocol specification.
-- An implementation report.
-- A report on field experience with the protocol, in actual deployments.

> Without your explanation of the context, the rules seemed appropriate, 
> i.e., they seem to state reasonable constraints on how to construct an 
> aggregated route given various routes as inputs. Are you saying that 
> there are no constraints now on how a speaker is supposed to create an 
> aggregated route from the routes a speaker receives from its peers?

In reality, most aggregates are not generated by creating an aggregate 
using the rules in the BGP specification. In fact, most aggregates are 
originated by simply advertising the shorter prefix aggregate, and 
filtering the longer prefix prefixes within the aggregate's space. For 
instance, in Cisco configuration terms:

ip route 10.1.0.0 255.255.0.0 null0
!
router bgp xxxx
  redistribute static

And then the appropriate filter to kill off everything within 10.1/16, 
minus those routes your customers have asked you not to aggregate. This 
doesn't violate the BGP specification in any way, and creates an aggregate 
without an AS SET.

This is what I think we mean when we say the AS SET isn't often used in 
real world BGP deployments. It's not that people don't use it, it's just 
that the majority of people don't, and the common usage is moving away from 
using AS SETs rather than towards it.

:-)

Russ

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Jan 2005 16:06:10 +0100

On 6-jan-05, at 0:40, Stephen Kent wrote:

> the path taken by traffic will diverge from the advertised route, but 
> the cited text in the BGP spec says that this should not be the case.

But how can this be enforced?

> up.  The answer, based on examining about 3 months of data (so far) is 
> that about 6-8% of the Updates had the atomic attribute and 7-9% had 
> aggregator. So about 14-16% of all Updates had one or the other form 
> of aggregation indicated.

So no overlap? Strange. And this is much more than I expected.

> features until it was fully deployed.

I should hope so.  :-)

> I admit to having never configured ANY router.

Smart move. Leave this to the trained professionals...

> However, when BBN ran the Arpanet and the Defense Data Network, we 
> updated packet switch software remotely, in each switch in the net, 
> then turned on new features in all of them, via remote management, in 
> a very short time.  Admittedly those nets were 200+ switches, not 600, 
> but the principle was the same, i.e, tolerating transient routing 
> instability in a net during the time it takes to turn on the new 
> features.

The trouble is that the internet as a whole is orders of magnitude 
larger than the ARPANET. Even single tier-1 networks are considerably 
larger than the ARPANET. And they are in competition, so it's important 
to not tick off customers with lengthy downtimes for maintenance.

> routers, that would not conflict with the requirement I cited.

Ok.

>> than 1. B would ideally select 3, but this isn't allowed because that 
>> would create a loop. It's also something that can't happen because A 
>> only sends 1 to B as 1 is the one it uses itself.

> partial deployment within an AS might be OK, but I do worry that there 
> are a lot of ways for it to fail.

(With "sees" I mean "receives from an external AS.)

I imagine that people will want to run the security stuff in some sort 
of "monitor" mode first, so that they get to see which routes would be 
rejected without them actually being rejected yet. Going from nothing 
to completely secure in one big leap would be too much for most people, 
I imagine.

Also, an important problem is going to be the routing information that 
is in fact good, but can't be verified as such. Especially in the 
beginning this will be a large class because people have to get the 
hang of the new system.

>> Don't feel like looking it up, but isn't it both rather than either?

Answer: yes most of the time. See section 9.1.4 of RFC 1771.

>> AS.

[...]

> I was not aware of the backwards compatibility motivation you cite for 
> the rules.

I'm starting to doubt myself now... I can't find any source for this 
information: it's not in the RFCs or in Internet Routing Architectures. 
So either it must have been in something more obscure or I came up with 
this explanation on my own without realizing it...

> Also, the statistics I noted above on how often atomic still appears 
> in Updates suggest that there are a number of operators who may not 
> realize why the attribute is no longer needed.

> aggregated route from the routes a speaker receives from its peers?

As Russ said, most aggregates aren't generated using aggregate creation 
mechanisms, but simply by sourcing the aggregate as a new prefix and 
filtering out the more specifics.

I'll even go further and claim that most aggregates aren't really 
aggregates, but people getting address space from an ISP's PA block and 
then announcing this space under their own AS. Obviously the entire PA 
block will also be announced under the ISP's AS. Usually, the ISP in 
question will also propagate the more specific. (If they didn't, there 
wouldn't be any incoming traffic through this ISP as the more specific 
points to another ISP.)

Now all of this non-RFC-compliant aggregation works without any 
problems because of the longest match first rule. However, if we want 
to have the actual aggregation benefits, we need to get rid of the more 
specifics. The problem with this is that if you do this in one AS, the 
next AS is probably going to hear the aggregate and the more specific 
from different sources. I.e.:

   sourceAS
    /   \
ISPA   ISPB
    \   /
    ISPC
      |
    (inet)

Assuming ISP A has 96.0.0.0/8 and the source AS announces 96.96.96.0/24.

So if ISP A doesn't propagate the /24 to the ISP C, ISP C will see the 
/8 from A and the /24 from B. In the current situation ISP C will allow 
both the /8 and the /24 through, so there is no aggregation as seen by 
anyone behind ISP C. With aggressive aggregation, the /24 would go away 
(to come back when the /8 disappears, one hopes) but then the link over 
ISP becomes useless. So what we really want is for ISP C to compare the 
AS path and/or other metrics and select the path over B if this is 
better, but ignore this path and use the aggregate if A is better. (C 
would still most likely only propagate the aggregate downstream, 
though.)

The BGP RFC allows for this, and mandates that the ISP B AS is listed 
in an AS_SET for the aggregate, and that the ATOMIC_AGGREGATE attribute 
is added as an indication of what's going on. However, unless I'm 
mistaken, all current implementations take the longest match first rule 
as gospel, so none of this comes into play.

So to answer your question: if noone is listening, it doesn't matter if 
what you're saying is wrong. So in practice there are no limitations on 
how you can aggregate.

Of course this will have to change when we add security, because we 
can't allow an unauthorized source to originate an aggregate. However, 
this doesn't mean only the holder of the address space gets to 
aggregate: people may trust others to aggregate for them.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Jan 2005 10:11:16 -0500

At 7:23 PM -0500 1/5/05, Russ White wrote:
>What you've not acknowledged is the problem is more extensive than 
>this. The NLRI in the udpate is also aggregated, and the aggregate 
>may contain information about routes the originator of the aggregate 
>does not have authorization to advertise.

The last phrase above is very worrisome. if the speaker has included 
NLRI that it "does not have authorization to advertise" then this 
seems to be both a violation of the spirit (if not the letter) of the 
BGP spec, and it seems impossible to provide coherent security for 
the system if one wants to permit such behavior. Obviously, in the 
worst case, if we define a security system that allows a speaker to 
advertise NLRI without any notion of authorization, then we 
implicitly allow advertisements that can result in black holes, etc. 
So, there must be a better way to characterize what we want in terms 
of "valid" advertisements.

>The problem is, you want this: If you assign a prefix to someone 
>else, they should always advertise that longer prefix past any 
>possible aggregation.
>
>In the real world, this is false. The _point_ of aggregation is for 
>this not to be true.

The point of aggregation is to reduce the size of routing tables and 
to reduce the size of Updates, while still providing accurate routing 
data. It's OK to create an aggregate that encompasses a longer 
prefix, so long as doing so does not misrepresent what the speaker 
has been authorized to advertise, either via direct or transitive 
authorization by the prefix holders.

>>RPSEC and IDR are both in the routing area, not the operations 
>>area. So, I do think that the BGP spec is the appropriate starting 
>>place for a security requirements document that says it is for BGP.
>
>This is a non-sequitor. There are many paths to security, only one 
>of which involves securing the process by which information is 
>handled.

Russ, you continue to ignore what I say, and instead substitute what 
you want to argue about. I made a simple statement, which is not at 
all a non-sequitor. What I said was almost a tautology, i.e., one 
should define security for a protocol starting with the definition of 
the protocol.

>application of any protocol it is involved in. Rather, it's all a 
>matter of algorithms and packet descriptions, and no question of 
>application, deployment, or implementation should enter into the 
>discussion. However, if you actually look at the requirements for a 
>protocol to become a standard, at least three documents are required:
>

The criteria for standards advancement tries to ensure that the 
protocol, as defined in the first document, is capable of being 
implemented in an interoperable fashion (based on experience reported 
in the second document). If field experience shows that the spec does 
not match what is deployed and interoperable, then the spec needs to 
change. For example, if one finds that a specified feature is not 
implemented and thus has not bee demonstrated to be interoperable, 
the feature cannot be retained as a MUST in the spec as the spec is 
advanced. The third document is not a substitute for a revised spec.

>>to construct an aggregated route given various routes as inputs. 
>>Are you saying that there are no constraints now on how a speaker 
>>is supposed to create an aggregated route from the routes a speaker 
>>receives from its peers?
>
>In reality, most aggregates are not generated by creating an 
>aggregate using the rules in the BGP specification. In fact, most 
>aggregates are originated by simply advertising the shorter prefix 
>aggregate, and filtering the longer prefix prefixes within the 
>aggregate's space. For instance, in Cisco configuration terms:
>
>And then the appropriate filter to kill off everything within 
>10.1/16, minus those routes your customers have asked you not to 
>aggregate. This doesn't violate the BGP specification in any way, 
>and creates an aggregate without an AS SET.

Tow observations:
	- if the aggregation is done in a way inconsistent with the 
cited rules, that that would seem to be non-compliant, and it calls 
into question why the BGP-4 spec is being advanced with the rules 
still in it.

	- the example above is lacking context, and its expressed in 
CLI jargon that I don't speak, so it does not help explain your point 
to me. please try again.

>This is what I think we mean when we say the AS SET isn't often used 
>in real world BGP deployments. It's not that people don't use it, 
>it's just that the majority of people don't, and the common usage is 
>moving away from using AS SETs rather than towards it.

I said that we did not see many AS SETs when we analyzed BGP data a 
few years ago, so we are not disagreeing on that point.

One thing that is missing from this discussion if a simple, clear 
characterization of what you assert are the allowed ways for speakers 
or ASes to perform aggregation, and why each way is reasonable, in a 
system context.  It would be preferable if there were RFCs that you 
could cite to justify the behaviors you describe, so that we have an 
objective basis for evaluating them. Is your concern that there is no 
way to do this, algorithmically, and thus you emphasize examining the 
outcome of route propagation rather that defining the rules that 
characterize allowed aggregation, etc?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Jan 2005 10:11:16 -0500

Tow observations:

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 6 Jan 2005 11:26:26 -0500 (Eastern Standard Time)

> The last phrase above is very worrisome. if the speaker has included NLRI 
> that it "does not have authorization to advertise" then this seems to be 
> both a violation of the spirit (if not the letter) of the BGP spec, and 
> it seems impossible to provide coherent security for the system if one 
> wants to permit such behavior. Obviously, in the worst case, if we define 
> a security system that allows a speaker to advertise NLRI without any 
> notion of authorization, then we implicitly allow advertisements that can 
> result in black holes, etc. So, there must be a better way to 
> characterize what we want in terms of "valid" advertisements.

ISP A "owns" 10.1.0.0/16. They allocate 10.1.1.0/24 to their customer, so 
the customer now "owns" 10.1.1.0/24. How do you "stop" the ISP from 
advertising 10.1.0.0/16 at this point, as a part of the /16? If the ISP 
doesn't have an advertisement for 10.1.1.0/24, then the ISP is disallowed 
from advertising 10.1.0.0/16, because they don't have authorization for 
_every component_ of that aggregate?

Obviously, you don't. Address block ownership overlaps in the same way 
aggregation overlaps. I think I've said this several times on this thread. 
This single fact invalidates the entire concept of securing BGP as a "set 
of processes," and forces you to look at how to secure the data itself, in 
some meaningful way.

> The point of aggregation is to reduce the size of routing tables and to 
> reduce the size of Updates, while still providing accurate routing data. 
> It's OK to create an aggregate that encompasses a longer prefix, so long 
> as doing so does not misrepresent what the speaker has been authorized to 
> advertise, either via direct or transitive authorization by the prefix 
> holders.

Again, how do you _prove_ this? You can't, beacause it's impossible. The 
entire draft "Considerations in Validating the Path in BGP" proves this 
through examples. I've not seen a single refutation of those arguments, 
here or elsewhere. The ambiguous concept of ownership of address space 
combined with the ability to filter longer prefix matches and advertise an 
aggregate you didn't originate make this impossible to prove. Can you show 
otherwise?

>> This is a non-sequitor. There are many paths to security, only one of 
>> which involves securing the process by which information is handled.
>
> Russ, you continue to ignore what I say, and instead substitute what you 
> want to argue about. I made a simple statement, which is not at all a 
> non-sequitor. What I said was almost a tautology, i.e., one should define 
> security for a protocol starting with the definition of the protocol.

No, you should define security for a system based on what information 
within the system needs to be secured, and leave flexibility about how to 
secure those pieces of data. Once again, this is akin to securing credit 
card transactions by working from the process used to handle credit card 
transactions, rather than starting from the data you need to be secured.

> 	- if the aggregation is done in a way inconsistent with the cited 
> rules, that that would seem to be non-compliant, and it calls into 
> question why the BGP-4 spec is being advanced with the rules still in it.

You missed the point that this isn't out of compliance. This is perfectly 
normal. If I own 10.1.0.0/16, I can originate it any way I want to. I'm not 
restricted to including the AS' of anyone advertising a longer prefix 
falling within that shorter prefix.

In fact, the entire concept of an "aggregate" is muddying the discussion, 
somewhat. There are overlapping prefixes. Sometimes they represent 
aggregates, sometimes they don't. You're taking a very procedural approach 
to the problem, and missing a lot of the actual core of the actual problem.

> characterization of what you assert are the allowed ways for speakers or 
> ASes to perform aggregation, and why each way is reasonable, in a system 
> context. It would be preferable if there were RFCs that you could cite to 
> justify the behaviors you describe, so that we have an objective basis 
> for evaluating them. Is your concern that there is no way to do this, 
> algorithmically, and thus you emphasize examining the outcome of route 
> propagation rather that defining the rules that characterize allowed 
> aggregation, etc?

If I "own" an address block, I'm authorized to advertise it. You're trying 
to get to the point of saying:

-- If you don't have an advertisement for every suballocation under your 
allocation, authorizing you to advertise each possible piece of that 
aggregate, then you can't advertise that aggregate.

-- Even if you have every one of these advertisements, you MUST include the 
AS of every AS you've received such "authorization" from.

This, essentially, means: You can't aggregate to provide the security 
you're claiming we should require in the draft. The concept of "transitive 
authorization," in the terms you're trying to apply it BGP, simply doesn't 
exist.

You can point out all sorts of phrases and comments in the draft, but you 
have to temper these statements with the actual operation of BGP in the 
real world, with real address ownership concepts, real aggregation, and 
real route origination policies.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Jan 2005 11:26:30 -0500

At 3:47 PM -0500 1/5/05, Russ White wrote:
>>What I would like is to see proposed requirements that are 
>>traceable to the BGP spec and that do not favor any specific 
>>solution technology. To that end I have prepared a memo based on 
>>the latest BGP I-D (the one about to be issued as the full standard 
>>version RFC for BGP), which tries to capture security-relevant 
>>requirements from the text, and to relate them to some of the 
>>discussions we have been having.
>
>In other words, the only acceptable solution, to you, is to secure 
>the process, and hope the data is magically secured by securing the 
>process.

I think this is an grossly unfair characterization.

BGP is a protocol, which defines of formats for messages and an 
algorithm for processing these messages, in the context of local 
databases. If we define security for BGP in terms of generating the 
"right" routes even when the systems is under attack, we need to 
begin with the process that generates the routes under benign 
conditions.

I agree that one may be able to generate rules for characterizing 
what routes are authorized/valid/... independent of the process by 
which they are generated. BUT, if you want to do that, rather than 
focusing on securing the process, the burden is on you to show that 
the results are equivalent.

>The requirements should state what information must be verifiable, 
>and in what way, for the system to be considered secure. I've tried 
>to give several examples of this, but you either don't understand 
>them, or move the discussion directly back to soBGP vs S-BGP, which 
>I've completely avoided in all the phases here. For instance, if you 
>were considering credit card information, would you consider 
>securing the data--the siganture, the authorization, and the card 
>number, etc.? Or would you consider securing the process--the paper 
>the reciept is on, the color of the signing pen, etc?

You have provided some analogies, but I noted some problems with 
them. Your example above, I fear, is similarly flawed.

In the credit card space there are valid accounts and authorized 
users. The primary security goal here is to ensure that charges are 
associated with valid accounts and incurred on behalf of authorized 
users. That's the high level security goal and it is very much 
independent of process. It applies whether the cards are used in card 
present or MOTO transactions.

But, the standards that exist for the credit card industry do not 
strike me as analogous to those for BGP. They relate to formats for 
CC numbers, card size, mag stripe format, and low-level security 
mechanisms for communication. These standards address different ways 
of using credit cards in different contexts, and none of them happen 
to overlap with the examples you cite above, e.g., credit slip paper 
and pen color!

>I would take the description of the system, as it operates, attempt 
>to pull out the data that needs ot be secured, and then write a set 
>of requirements around that data. You are, on the other hand, saying 
>the only legitimate security is that which "follows the processing 
>of the original information," without reference to the information 
>itself.

I am saying that the definition of how BGP routing is supposed to 
work needs to be based on the BGP spec. Its an IETF standard and an 
objective basis from which  to work. What IETF standard description 
of "the system" would you propose to use as the basis for developing 
security requirements for BGP?

>disagreement. You either have to look at a security system as trying 
>to secure the data within the system, or securing the process of 
>handling that data.
>
>process--over the over--securing the data--simply because it fits 
>the model of the security solution you've already proposed. I prefer 
>the one that allows the maximum flexibility in designing any given 
>security system, and letting operators and designers determine their 
>own tradeoffs when designing and deploying a solution at some point 
>in the future.

We both have prejudices in approaching this problem.  One can fairly 
say that I used the BGP spec as the basis for developing the security 
requirements model that we then addressed with S-BGP. Likewise, you 
adopted an operations-oriented view of security when you developed 
soBGP. That does not make either approach intrinsically valid or 
invalid.

But, what you refer to as an approach that allows for "maximum 
flexibility ..." just happens to be the same one you used, and so it 
does reflect that bias, and that is a problem.

We have a fundamental disagreement about what constitutes a 
legitimate basis for deriving BGP security requirements.  I 
understand your point of view, but I disagree. Since you are co-chair 
of this WG you have an obvious conflict of interest problem in trying 
to resolve this at the WG chair level. Perhaps the right thing to do 
at this stage is to bring the issue to the attention of the IESG.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 6 Jan 2005 11:52:18 -0500 (Eastern Standard Time)

> You have provided some analogies, but I noted some problems with them. 
> Your example above, I fear, is similarly flawed.
>
> In the credit card space there are valid accounts and authorized users. 
> The primary security goal here is to ensure that charges are associated 
> with valid accounts and incurred on behalf of authorized users. That's 
> the high level security goal and it is very much independent of process. 
> It applies whether the cards are used in card present or MOTO 
> transactions.
>
> But, the standards that exist for the credit card industry do not strike 
> me as analogous to those for BGP. They relate to formats for CC numbers, 
> card size, mag stripe format, and low-level security mechanisms for 
> communication. These standards address different ways of using credit 
> cards in different contexts, and none of them happen to overlap with the 
> examples you cite above, e.g., credit slip paper and pen color!

And I disagree, perhaps because I'm a routing geek. :-)

BGP is, specifically, a "communications process." BGP is not the _only_ 
path through which you can get routing information. It interacts with other 
routing processes, and other sources of routing information, including 
things like manual configuration, traffic optimizers, intrusion systems, 
and a host of other systems.

So, to me, BGP is exactly like the standards you discuss in the credit card 
industry. It specifies things like the type of paper and color of pen 
(packet format), the process whereby you set up a connection to accept 
credit card information (peering process), etc. I separate the data from 
the process, because I work with routing protocols every day.

In fact, I think routing is much less rigerous than people looking in from 
the outside imagine, especially when reading the specs. Information is 
placed in a set of BGP tables, which is then filtered, prodded, modified, 
etc, and then placed in the routing table. It's more of an SQL merge rather 
than a strict "put this there." This is then prodded, and placed in a 
forwarding table, possibly in a completely different format.

Routes carry communities which impact the policy of the receiver, routes 
are filtered, and their attributes are changed. Sometimes one route is 
advertised based on the existance of another route. Longer prefixes are 
sometimes allowed through an "aggregation point," routes are re-originated 
rather than aggregated, and a number of other things can happen in the real 
world.

> I am saying that the definition of how BGP routing is supposed to work 
> needs to be based on the BGP spec. Its an IETF standard and an objective 
> basis from which to work. What IETF standard description of "the system" 
> would you propose to use as the basis for developing security 
> requirements for BGP?

The real world, preferrably.

> We both have prejudices in approaching this problem.  One can fairly say 
> that I used the BGP spec as the basis for developing the security 
> adopted an operations-oriented view of security when you developed soBGP. 
> That does not make either approach intrinsically valid or invalid.

And at some point, the WG has to decide which of these two models is valid. 
I believe that I've made a strong case to consider the operational use as a 
valid model, because of gaps in the alternative model.

> We have a fundamental disagreement about what constitutes a legitimate 
> basis for deriving BGP security requirements.  I understand your point of 
> view, but I disagree. Since you are co-chair of this WG you have an 
> obvious conflict of interest problem in trying to resolve this at the WG 
> chair level. Perhaps the right thing to do at this stage is to bring the 
> issue to the attention of the IESG.

I believe I've been more than fair in every discussion, and attempted to 
simply discuss the models at hand, in terms of requirements.

If you believe it should be taken before the IESG, I would encourage you to 
do so. I believe a review of the email threads will show that I've 
attempted, on every occasion, to bring in all possible solutions, and argue 
from a technical, rather than a procedural, standpoint, about which model 
is best. I've seen no technical argument about why the model based on the 
specification is best, other than simply stating it is.

:-)

Russ

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Jan 2005 20:47:45 +0100

On 6-jan-05, at 17:26, Stephen Kent wrote:

> "right" routes even when the systems is under attack, we need to begin 
> with the process that generates the routes under benign conditions.

> I agree that one may be able to generate rules for characterizing what 
> routes are authorized/valid/... independent of the process by which 
> they are generated. BUT, if you want to do that, rather than focusing 
> on securing the process, the burden is on you to show that the results 
> are equivalent.

Aren't there really just two things that we want/need protection 
against:

1. Someone sourcing a prefix that doesn't belong to them

This is the easy part: some magic PKI dust solves this part real good.

2. Someone announcing reachability to a prefix or AS that they 
shouldn't announce

This is the tricky part. How do we know when someone is announcing 
reachability illegitimately? We can't go by the source, both because of 
the information explosion this causes and a wealth of practical issues, 
and also because even if the source says that AS X isn't supposed to be 
in their transit path, the destination may feel otherwise so the path 
turns out OK anyway.

Note that both soBGP and S-BGP (when I last looked at them) didn't have 
mechanisms to handle this properly.

All other bad stuff that an attacker could make happen by subverting 
BGP can also happen for legitimate reasons, so I don't see how we can 
realistically protect against that.

There is one other thing, though: it would be very nice if we could 
somehow determine whether traffic we send over a certain route actually 
makes it to the destination AS. This would be incredibly helpful even 
for regular misconfiguration and other routine brokenness, but also in 
the cases where an attacker solicits traffic but doesn't forward it to 
the real destination.

> present or MOTO transactions.

If we make the credit card owner an AS and make a payment a route, then 
we want traffic = money to follow legitimate routes, not fake ones. 
Pretty similar.  :-)

> needs to be based on the BGP spec. Its an IETF standard and an 
> objective basis from which  to work.

With just one tiny flaw: the standard doesn't fully describe what's out 
there in the real world. I believe IDR is trying to remedy this, but 
I'm not sure about how successful their efforts are. (Moving target and 
all.)

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Jan 2005 17:15:45 -0500

At 11:26 AM -0500 1/6/05, Russ White wrote:
>>>may contain information about routes the originator of the 
>>>aggregate does not have authorization to advertise.
>>
>>The last phrase above is very worrisome. if the speaker has 
>>included NLRI that it "does not have authorization to advertise" 
>>then this seems to be both a violation of the spirit (if not the 
>>letter) of the BGP spec, and it seems impossible to provide 
>>coherent security for the system if one wants to permit such 
>>behavior. Obviously, in the worst case, if we define a security 
>>system that allows a speaker to advertise NLRI without any notion 
>>of authorization, then we implicitly allow advertisements that can 
>ISP A "owns" 10.1.0.0/16. They allocate 10.1.1.0/24 to their 
>customer, so the customer now "owns" 10.1.1.0/24. How do you "stop" 
>the ISP from advertising 10.1.0.0/16 at this point, as a part of the 
>/16? If the ISP doesn't have an advertisement for 10.1.1.0/24, then 
>the ISP is disallowed from advertising 10.1.0.0/16, because they 
>don't have authorization for _every component_ of that aggregate?

You would not want to stop ISP A from advertising the /16. It is 
authorized to do so by its initial allocation of this prefix from an 
RIR or IANA. I'm not sure where you have derived the notion that the 
ISP is not authorized to advertise the /16 because of its allocation 
of the /24 to a subscriber.  This is certainly NOT an S-BGP concept. 
The words you are using suggest to me that you have a vague notion of 
what I mean when I speak about authorization, but that notion is 
inaccurate. I think several of my previous messages have included 
text that make clear that this sort of allocation by an ISP is NOT a 
problem.

>Obviously, you don't. Address block ownership overlaps in the same 
>way aggregation overlaps. I think I've said this several times on 
>this thread. This single fact invalidates the entire concept of 
>securing BGP as a "set of processes," and forces you to look at how 
>to secure the data itself, in some meaningful way.

I'm sorry to have to say this, Russ, but you are just plain wrong 
here. It seems to me that the problem is that you think you 
understand what I mean what I talk about authorization, but you have 
some misconceptions and that is coloring what you say.

>>The point of aggregation is to reduce the size of routing tables 
>>and to reduce the size of Updates, while still providing accurate 
>>routing data. It's OK to create an aggregate that encompasses a 
>>longer prefix, so long as doing so does not misrepresent what the 
>>speaker has been authorized to advertise, either via direct or 
>>transitive authorization by the prefix holders.
>
>Again, how do you _prove_ this? You can't, beacause it's impossible. 
>The entire draft "Considerations in Validating the Path in BGP" 
>proves this through examples. I've not seen a single refutation of 
>those arguments, here or elsewhere. The ambiguous concept of 
>ownership of address space combined with the ability to filter 
>longer prefix matches and advertise an aggregate you didn't 
>originate make this impossible to prove. Can you show otherwise?

Your individual contribution I-D makes arguments based on assumptions 
about what one can infer from examining path data as transmitted in 
BGP. That's fair, but it ignores the potential to augment that data 
based on data that a speaker received but did not normally include in 
an Update, and on the ability to distribute relatively static data 
via external means. The real world environment to which you 
frequently refer relies on externally distributed data to help 
mitigate errors and malicious Update data (e.g., IRRs), so the idea 
of relying on such data is both consistent with the BGP spec (the 
PIB) and with deployment practice. So, I don't understand why you 
persist in ignoring that obvious source of additional inputs to the 
route computation process, if it is secured and the data is 
distributed in this fashion is consistent with the dynamics 
characteristic of such a distribution process.

>>Russ, you continue to ignore what I say, and instead substitute 
>>what you want to argue about. I made a simple statement, which is 
>>not at all a non-sequitor. What I said was almost a tautology, 
>>i.e., one should define security for a protocol starting with the 
>>definition of the protocol.
>
>No, you should define security for a system based on what 
>information within the system needs to be secured, and leave 
>flexibility about how to secure those pieces of data. Once again, 
>this is akin to securing credit card transactions by working from 
>the process used to handle credit card transactions, rather than 
>starting from the data you need to be secured.

Sorry, but this attempted analogy is still flawed and does not 
warrant further discussion.

>You missed the point that this isn't out of compliance. This is 
>perfectly normal. If I own 10.1.0.0/16, I can originate it any way I 
>want to. I'm not restricted to including the AS' of anyone 
>advertising a longer prefix falling within that shorter prefix.
>
>In fact, the entire concept of an "aggregate" is muddying the 
>discussion, somewhat. There are overlapping prefixes. Sometimes they 
>represent aggregates, sometimes they don't. You're taking a very 
>procedural approach to the problem, and missing a lot of the actual 
>core of the actual problem.

YOU are the one who keeps making arguments based on aggregation 
examples! if you think that they are muddying the discussion, don't 
use them.

>>characterization of what you assert are the allowed ways for 
>>speakers or ASes to perform aggregation, and why each way is 
>>reasonable, in a system context. It would be preferable if there 
>>were RFCs that you could cite to justify the behaviors you 
>>describe, so that we have an objective basis for evaluating them. 
>>Is your concern that there is no way to do this, algorithmically, 
>>and thus you emphasize examining the outcome of route propagation 
>>rather that defining the rules that characterize allowed 
>>aggregation, etc?
>
>If I "own" an address block, I'm authorized to advertise it. You're 
>trying to get to the point of saying:
>
>-- If you don't have an advertisement for every suballocation under 
>your allocation, authorizing you to advertise each possible piece of 
>that aggregate, then you can't advertise that aggregate.

I have never said that, so this is an erroneous characterization of 
my position.

>-- Even if you have every one of these advertisements, you MUST 
>include the AS of every AS you've received such "authorization" from.

This too is wrong. What you seem to be doing is stating YOUR 
interpretation of my comments. Don't do that; it's a waste of 
everyone's time, and it's annoying.

>This, essentially, means: You can't aggregate to provide the 
>security you're claiming we should require in the draft. The concept 
>of "transitive authorization," in the terms you're trying to apply 
>it BGP, simply doesn't exist.

I hate to see the discussion degrade to this level again, but your 
statement is just wrong. It's wrong for reasons I have cited in the 
past and which do not merit restating here, since you appear to 
ignore them.

>You can point out all sorts of phrases and comments in the draft, 
>but you have to temper these statements with the actual operation of 
>BGP in the real world, with real address ownership concepts, real 
>aggregation, and real route origination policies.

As best I can tell, you have a seriously flawed perception of what I 
have said, which causes you to make arguments that are not valid 
criticisms of the positions I have espoused.  Nonetheless, the 
central issue is whether we are going to generate BGP security 
requirements based on IETF standards, or to use characterizations of 
"real world" BGP that have no basis in IETF standards track 
documentation. I vote for door #1.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Jan 2005 15:59:37 -0500

At 11:52 AM -0500 1/6/05, Russ White wrote:
>>independent of process. It applies whether the cards are used in 
>>card present or MOTO transactions.
>>
>>mechanisms for communication. These standards address different 
>>ways of using credit cards in different contexts, and none of them 
>>happen to overlap with the examples you cite above, e.g., credit 
>>slip paper and pen color!
>
>BGP is, specifically, a "communications process." BGP is not the 
>_only_ path through which you can get routing information. It 
>interacts with other routing processes, and other sources of routing 
>information, including things like manual configuration, traffic 
>optimizers, intrusion systems, and a host of other systems.

The BGP spec recognizes inputs from BGP, IGPs, EGP (historically), 
and manual configuration. If your configuration gets info from the 
other sources your cite above, that are not in the BGP spec, they 
fall under the manual/local configuration umbrella.

>So, to me, BGP is exactly like the standards you discuss in the 
>credit card industry. It specifies things like the type of paper and 
>color of pen (packet format), the process whereby you set up a 
>connection to accept credit card information (peering process), etc. 
>I separate the data from the process, because I work with routing 
>protocols every day.

as a security geek, I'll have to say that we just disagree on the 
validity of your analogy :-)

>In fact, I think routing is much less rigerous than people looking 
>in from the outside imagine, especially when reading the specs. 
>Information is placed in a set of BGP tables, which is then 
>filtered, prodded, modified, etc, and then placed in the routing 
>table. It's more of an SQL merge rather than a strict "put this 
>there." This is then prodded, and placed in a forwarding table, 
>possibly in a completely different format.

So you're saying that BGP, as deployed and operated, bears only scant 
resemblance to the IETF spec for the protocol. if so, then I 
certainly think an attempt to generate security requirements for the 
system you describe belongs in a WG under the operations area, not in 
the area where the BGP spec is maintained.

>Routes carry communities which impact the policy of the receiver, 
>routes are filtered, and their attributes are changed. Sometimes one 
>route is advertised based on the existance of another route. Longer 
>prefixes are sometimes allowed through an "aggregation point," 
>routes are re-originated rather than aggregated, and a number of 
>other things can happen in the real world.
>
>>of "the system" would you propose to use as the basis for 
>>developing security requirements for BGP?
>

so, I take this concise response to mean that you have no IETF 
standards documents to cite.

>>We both have prejudices in approaching this problem.  One can 
>>fairly say that I used the BGP spec as the basis for developing the 
>>security requirements model that we then addressed with S-BGP. 
>>Likewise, you adopted an operations-oriented view of security when 
>>you developed soBGP. That does not make either approach 
>>intrinsically valid or invalid.
>
>And at some point, the WG has to decide which of these two models is 
>valid. I believe that I've made a strong case to consider the 
>operational use as a valid model, because of gaps in the alternative 
>model.

more precisely, because of your perception of gaps in a standards-based model.

>>understand your point of view, but I disagree. Since you are 
>>co-chair of this WG you have an obvious conflict of interest 
>>problem in trying to resolve this at the WG chair level. Perhaps 
>>the right thing to do at this stage is to bring the issue to the 
>>attention of the IESG.
>
>I believe I've been more than fair in every discussion, and 
>attempted to simply discuss the models at hand, in terms of 
>requirements.
>
>If you believe it should be taken before the IESG, I would encourage 
>you to do so. I believe a review of the email threads will show that 
>I've attempted, on every occasion, to bring in all possible 
>solutions, and argue from a technical, rather than a procedural, 
>standpoint, about which model is best. I've seen no technical 
>argument about why the model based on the specification is best, 
>other than simply stating it is.

At least we agree on the appropriateness of trying to resolve this at 
a higher level of IETF management.

I'll take the action to initiate an IESG level review of the basic 
question of what should be the basis for the security requirements 
that this WG is chartered to develop.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 6 Jan 2005 18:22:44 -0500 (Eastern Standard Time)

>> ISP A "owns" 10.1.0.0/16. They allocate 10.1.1.0/24 to their customer, 
>> so the customer now "owns" 10.1.1.0/24. How do you "stop" the ISP from 
>> doesn't have an advertisement for 10.1.1.0/24, then the ISP is 
>> disallowed from advertising 10.1.0.0/16, because they don't have 
>> authorization for _every component_ of that aggregate?
>
> authorized to do so by its initial allocation of this prefix from an RIR 
> or IANA. I'm not sure where you have derived the notion that the ISP is 
> not authorized to advertise the /16 because of its allocation of the /24 
> to a subscriber.  This is certainly NOT an S-BGP concept. The words you 
> are using suggest to me that you have a vague notion of what I mean when 
> I speak about authorization, but that notion is inaccurate. I think 
> several of my previous messages have included text that make clear that 
> this sort of allocation by an ISP is NOT a problem.

> I have never said that, so this is an erroneous characterization of my 
> position.
>
> This too is wrong. What you seem to be doing is stating YOUR interpretation 
> of my comments. Don't do that; it's a waste of everyone's time, and it's 
> annoying.
>
> I hate to see the discussion degrade to this level again, but your statement 
> is just wrong. It's wrong for reasons I have cited in the past and which do 
> not merit restating here, since you appear to ignore them.

I'm not ignoring them, I'm simply taking the sum total of what you're 
saying and reaching logical conclusions. If we can only take the BGP 
specification as our basis, then suppose I have this:

   -- A owns 10.1.0.0/16.
   -- A suballocates 10.1.1.0/24 to B.

   -- C receives an update containing 10.1.0.0/16 from A. How can C prove
   that B has authorized A to advertise 10.1.1.0/24, which happens to be a
   part of 10.1.0.0/16?

If we go solely on the BGP specification, then A _must_ place B in it's AS 
SET, correct? But, what if it's reoriginating the route, rather than 
aggregating using a mechanism specified in the BGP specification?

How do we handle it when B explicitely refuses to allow A to advertise 
10.1.1.0/24? Should A be forced to not advertise 10.1.0.0/16?

I've not seen an explaination for how the authorization "chain" actually 
works in this case. You state that A shouldn't stop advertising 10.1.0.0/16 
(above), but 10.1.1.0/24 is _contained within_ that address space. It's no 
good to say that A isn't actually advertising 10.1.1.0/24, because it most 
certainly is advertising 10.1.1.0/24, as a part of 10.1.0.0/16. There's no 
way around that, because routers will forward a packet towards 10.1.1.1 to 
10.1.0.0/16 just as readily as they will to 10.1.1.0/24.

You even stated, in an earlier email:

> If the speaker has included NLRI that it "does not have authorization to 
> advertise" then this seems to be both a violation of the spirit (if not 
> the letter) of the BGP spec, and it seems impossible to provide coherent 
> security for the system if one wants to permit such behavior.

Clearly such situations exist, I've just described one, above, and the 
draft I've pointed you to has specific examples. As long as we can agree 
that 10.1.1.0/24 is a part of 10.1.0.0/16 (and I'll assume we can agree on 
that point, at least), then what you've described above occurs on a regular 
basis within the Internet today. What I'm describing falls outside the BGP 
specification, but within the system as a whole.

This strikes me as a strong justification for basing security requirements 
on the way things really work, rather than the BGP specification itself.

So, at worst, I'm confused. I'm not ignoring you, I'm not trying to 
misconstrue your statements, I just don't understand how you're argument 
refutes the real world examples I've given. I take your statements at face 
value, and try to understand how they actually apply, based on my 
understanding of routing, address allocation, and the other elements of any 
large internetwork as a working system.

> As best I can tell, you have a seriously flawed perception of what I have 
> said, which causes you to make arguments that are not valid criticisms of 
> the positions I have espoused.  Nonetheless, the central issue is whether 
> we are going to generate BGP security requirements based on IETF 
> standards, or to use characterizations of "real world" BGP that have no 
> basis in IETF standards track documentation. I vote for door #1.

And I believe, as I've stated and shown many times (in fact, just above), 
using the "objective standard" of BGP to build these security requirements 
leaves holes.

Regardless of your attempts at striking at me personally, Steve, I don't 
see how you can get around building a set of requirements based on what 
exists, rather than the BGP specification, which is only part of the way 
things really work. The BGP specification doesn't specify, for instance, 
how address blocks will be allocated, by whom, and under what conditions. 
The BGP specification doesn't specify how the capabilities within the 
protocol will actually be configured and used, for instance, for filtering 
and origination of routes.

I still don't see a technical argument proving using the BGP specification 
as the sole basis for defining security requirements is the right way to go 
about building a security requirements document. Simply saying my arguments 
are invalid doesn't get me anywhere, I need you to explain why they are 
invalid. Refute my examples, explain how the authorization chain works in 
the example above.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Jan 2005 16:39:45 -0500

Russ,

>	<SNIP>
>I'm not ignoring them, I'm simply taking the sum total of what 
>you're saying and reaching logical conclusions. If we can only take 
>the BGP specification as our basis, then suppose I have this:
>
>   -- A owns 10.1.0.0/16.

The BGP spec deals with processing Updates, and does not address the 
infrastructure that supports address allocation, as we both know. 
But, BGP does make explicit provision for use of locally configured 
policy data that can augment what a speaker/AS knows, independent of 
what is received via Updates. So, if one focuses on security 
requirements derived from the spec, one is free to address the 
question of how C can be made aware of info such as the 
sub-allocation of the /24 from A to B, based on such locally 
configured data, in a secure fashion. I think it fair to say that BGP 
defines Updates as the means to convey dynamic data about routes, 
whereas locally configured policy info is viewed as a means of 
conveying more static data that can affect route selection. Thus, 
when one considers the types of data that should be distributed 
external to BGP, for local configuration, that data should be 
similarly static.

>If we go solely on the BGP specification, then A _must_ place B in 
>it's AS SET, correct? But, what if it's reoriginating the route, 
>rather than aggregating using a mechanism specified in the BGP 
>specification?

The BGP spec allows A to originate the /16. It would also be OK to 
create a issue a separate Update, with B as the origin, for the /24. 
But, I don't think the spec mandates this. I'm not sure what the term 
"re-originating" means, so I don't know how to interpret the second 
part of your question.

>How do we handle it when B explicitely refuses to allow A to 
>advertise 10.1.1.0/24? Should A be forced to not advertise 
>10.1.0.0/16?

BGP does NOT say that A is not supposed to advertise the /16 just 
because a sub-allocation out of the /16 is no longer reachable via A. 
I cited specific text from the BGP spec that deals with this, in my 
memo so I will not bother restating the reasoning here.

>I've not seen an explaination for how the authorization "chain" 
>actually works in this case. You state that A shouldn't stop 
>advertising 10.1.0.0/16 (above), but 10.1.1.0/24 is _contained 
>within_ that address space. It's no good to say that A isn't 
>actually advertising 10.1.1.0/24, because it most certainly is 
>advertising 10.1.1.0/24, as a part of 10.1.0.0/16. There's no way 
>around that, because routers will forward a packet towards 10.1.1.1 
>to 10.1.0.0/16 just as readily as they will to 10.1.1.0/24.

Routers will forward packets based on the most specific 
advertisements they learn. So, yes, IF a router does not learn about 
a path for a /24 that is no longer reachable via the AS path that 
terminates at the holder of the /16 that subsumes the /24, then the 
traffic will be routed to the /16. That is precisely what BGP says 
should happen, even though it may cause packets to be routed to an As 
that will discard them. Thus, from a security perspective, our goal 
is to find ways to enable the holder of the /24 to make other ASes 
aware of the fact that the holder of the /16 is no longer authorized 
to advertise this specific prefix. And, of course, we need to do it 
in a fashion consistent with the BGP spec.

>>If the speaker has included NLRI that it "does not have 
>>authorization to advertise" then this seems to be both a violation 
>>of the spirit (if not the letter) of the BGP spec, and it seems 
>>impossible to provide coherent security for the system if one wants 
>>to permit such behavior.
>
>Clearly such situations exist, I've just described one, above, and 
>the draft I've pointed you to has specific examples. As long as we 
>can agree that 10.1.1.0/24 is a part of 10.1.0.0/16 (and I'll assume 
>we can agree on that point, at least), then what you've described 
>above occurs on a regular basis within the Internet today. What I'm 
>describing falls outside the BGP specification, but within the 
>system as a whole.

By quoting my words out of the larger context of the discussion, they 
do give the impression you cite. The holder of a prefix is authorized 
to advertise the whole prefix, period. I think my comment, that you 
cited above, was addressing an example in which you were suggesting 
that an AS could arbitrarily advertise prefixes without any form of 
authorization. The response I just provided above (in this message) 
explains what I think BGP states.

>This strikes me as a strong justification for basing security 
>requirements on the way things really work, rather than the BGP 
>specification itself.

see the comments I provided above, to counter the analysis, and thus 
refute this inference.

>misconstrue your statements, I just don't understand how you're 
>argument refutes the real world examples I've given. I take your 
>statements at face value, and try to understand how they actually 
>apply, based on my understanding of routing, address allocation, and 
>the other elements of any large internetwork as a working system.

well  we all get confused at times and we all forget things that have 
been said earlier, so I don't mean to be unduly harsh in that regard. 
So, I'll try to restate what I think the BGP spec says, in regard to 
this specific topic:

	1. BGP calls for routers to route packets based on the 
combination of the advertisements received via Updates, and via 
locally configured information, with the later having precedence over 
the former.

	2. A router is expected to route traffic based on the longest 
prefix (known to the router) that matches the traffic destination 
address.

So, your /24 vs. /16 example is addressed by these two simple rules. 
It does say that misrouting can occur, e.g., if an AS is not aware of 
the fact that a /24 is no longer reachable via a path that terminates 
at the (subsuming) /16 holder's AS. That's a limitation of the 
protocol design, and I believe that this is precisely what happens in 
practice. To the extent that ASes are configured with externally 
provided info that tells them that, for example, the holder of the 
/24 no longer authorizes the AS that originates, then they can avoid 
this problem. But, static routes to distant ASes are not very 
attractive, so there are clear limitations to using local policy info 
to address this problem. However, an intermediate measure it to make 
available information about which ASes are authorized to originate 
which prefixes, based on both the address allocation hierarchy AND on 
subsequent sub-allocations, so that speakers can use this locally 
configured info as part of the process for deciding whether to accept 
a route.

>>As best I can tell, you have a seriously flawed perception of what 
>>I have said, which causes you to make arguments that are not valid 
>>requirements based on IETF standards, or to use characterizations 
>>of "real world" BGP that have no basis in IETF standards track 
>And I believe, as I've stated and shown many times (in fact, just 
>above), using the "objective standard" of BGP to build these 
>security requirements leaves holes.

I think my responses to your comments refute this assertion.

>Regardless of your attempts at striking at me personally, Steve, I 
>don't see how you can get around building a set of requirements 
>based on what exists, rather than the BGP specification, which is 
>only part of the way things really work. The BGP specification 
>doesn't specify, for instance, how address blocks will be allocated, 
>by whom, and under what conditions. The BGP specification doesn't 
>specify how the capabilities within the protocol will actually be 
>configured and used, for instance, for filtering and origination of 
>routes.

I have not attempting to "[strike] you personally," Russ. if I had, 
there probably would be bruises :-)

We agree that BGP does not discuss  how addresses are allocated. And, 
yes, that is an important aspect of how routing works and how secure 
routing must work. But, BGP does take address allocation into 
account, e.g., a big difference between BGP-4 and 3 is the reliance 
in CIDR allocation,  which is prominently mentioned in the spec. And, 
BGP makes application of local policies an important part of the 
route selection and advertisement algorithm. It leaves the details up 
to local managers and vendors. So what?

>I still don't see a technical argument proving using the BGP 
>specification as the sole basis for defining security requirements 
>is the right way to go about building a security requirements 
>document. Simply saying my arguments are invalid doesn't get me 
>anywhere, I need you to explain why they are invalid. Refute my 
>examples, explain how the authorization chain works in the example 
>above.

I have explained how authorization works, every time you have requested.

if you can't understand why using the spec for a protocol is the 
appropriate primary basis for developing security requirements for 
that protocol, I'm afraid I a at a loss to help.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 7 Jan 2005 17:09:09 -0500 (Eastern Standard Time)

> infrastructure that supports address allocation, as we both know.

Which is a strong justification to base the requirements on deployed 
systems, as they operate, rather than the BGP specification itself.

> The BGP spec allows A to originate the /16. It would also be OK to create a 
> issue a separate Update, with B as the origin, for the /24. But, I don't 
> think the spec mandates this. I'm not sure what the term "re-originating" 
> means, so I don't know how to interpret the second part of your question.

Re-origination, in this context, means that A is advertising the /16, 
rather than the aggregate.

> BGP does NOT say that A is not supposed to advertise the /16 just because 
> a sub-allocation out of the /16 is no longer reachable via A. I cited 
> specific text from the BGP spec that deals with this, in my memo so I 
> will not bother restating the reasoning here.

The /24 is a _part_ of the /16. Since the /24 is a _part_ of the /16, how 
does A advertise the /16 without advertising the /24? IF A cannot advertise 
the /16 without including the /24, and A does not have authorization to 
advertise the /24, then it _cannot_ advertise the /16.

I think you're missing the point that the /24 is contained within the /16.

> Routers will forward packets based on the most specific advertisements 
> they learn. So, yes, IF a router does not learn about a path for a /24 
> that is no longer reachable via the AS path that terminates at the holder 
> of the /16 that subsumes the /24, then the traffic will be routed to the 
> /16. That is precisely what BGP says should happen, even though it may 
> cause packets to be routed to an As that will discard them. Thus, from a 
> security perspective, our goal is to find ways to enable the holder of 
> the /24 to make other ASes aware of the fact that the holder of the /16 
> is no longer authorized to advertise this specific prefix. And, of 
> course, we need to do it in a fashion consistent with the BGP spec.

How can you gaurentee this? Will you force BGP speakers to forward updates 
with longer length prefixes than the updates they already have? Can you 
explain a system where A and B are both forced to readvertise the /24, and 
C can tell if they aren't?

> By quoting my words out of the larger context of the discussion, they do 
> give the impression you cite. The holder of a prefix is authorized to 
> advertise the whole prefix, period. I think my comment, that you cited 
> above, was addressing an example in which you were suggesting that an AS 
> could arbitrarily advertise prefixes without any form of authorization. 
> The response I just provided above (in this message) explains what I 
> think BGP states.

Again, look at what I said above. The /24 is _contained within_ the /16. If 
A is advertising the /16, which _contains_ the /24, then it is advertising 
space it's not authorized to advertise. Which then relates back to your 
statement above, and is the reason I quoted it.

> see the comments I provided above, to counter the analysis, and thus 

And I've just refuted your comments above. :-)

> 	1. BGP calls for routers to route packets based on the combination 
> of the advertisements received via Updates, and via locally configured 
> information, with the later having precedence over the former.

Actually, BGP doesn't call for anything about forwarding or routing. BGP 
describes how to build a local database, from which you can build a 
forwarding table.

> prefix (known to the router) that matches the traffic destination 

That's not in the BGP spec, either, as far as I know.

> So, your /24 vs. /16 example is addressed by these two simple rules. It 
> does say that misrouting can occur, e.g., if an AS is not aware of the 
> fact that a /24 is no longer reachable via a path that terminates at the 
> (subsuming) /16 holder's AS. That's a limitation of the protocol design, 
> and I believe that this is precisely what happens in practice.

Yes, but it breaks the concept of authorization you're claiming to have 
proven.

You have two choices:

-- You provide authorization for the update.

-- You provide authorization for the information in the update.

In the first case, you have to realize that BGP doesn't treat an update as 
an "atomic thing." The update contains data that's received, processed, and 
readvertised. The update itself is a meaningless thing within BGP, a 
transport mechanism.

What's important is the data within the update. And the data shows that the 
concept of authorization you're trying to state is possible, simply isn't 
possible.

> I think my responses to your comments refute this assertion.

I disagree. Once again, you're treating the BGP update as an "atomic thing" 
that you can somehow secure. I think the nature of the data carried _must_ 
be considered. You're somehow equating "validating" the update with 
"validating" the information in the update.

> We agree that BGP does not discuss how addresses are allocated. And, yes, 
> that is an important aspect of how routing works and how secure routing 
> must work. But, BGP does take address allocation into account, e.g., a 
> big difference between BGP-4 and 3 is the reliance in CIDR allocation, 
> which is prominently mentioned in the spec. And, BGP makes application of 
> local policies an important part of the route selection and advertisement 
> algorithm. It leaves the details up to local managers and vendors. So 
> what?

If allocation is important, and it's outside the BGP specification, then 
clearly basing the requirements document on the specification only looks at 
a part of the solution.

> I have explained how authorization works, every time you have requested.

Only from the perspective of the updates. You've not explained it from the 
perspective of the data within the update. You're probably going to say the 
data's not in the BGP specification, the updates are. My point exactly--by 
ignoring the questions we can ask about the data, you're missing the 
biggest part of the problem.

> appropriate primary basis for developing security requirements for that 
> protocol, I'm afraid I a at a loss to help.

And, I'm at the same impasse. If you can't understand why using the 
specification fails to adress/ask the fundamental questions we can and 
should be asking, then I'm at a loss, as well.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Jan 2005 18:40:15 -0500

At 4:06 PM +0100 1/6/05, Iljitsch van Beijnum wrote:
>>be the case.

BGP security cannot enforce a match between forwarding and routing. 
The best it can do is to help secure the data used in the route 
computation process, so that IF the speaker is relying on the 
correspondence between routing and forwarding, then it is making use 
of valid routing data in making routing decisions.

>
>>After sending the message I asked a colleague to look at 2004 RV 
>>data and see how often the atomic aggregate and aggregator 
>>attribute shows up.  The answer, based on examining about 3 months 
>>of data (so far) is that about 6-8% of the Updates had the atomic 
>>attribute and 7-9% had aggregator. So about 14-16% of all Updates 
>>had one or the other form of aggregation indicated.
>

Do you mean overlap in the sense of both attributes appearing in the 
same Update? I asked my colleague to look for either attribute, and 
he gave me stats based on that request. I'll go back and ask him to 
see how often an Update contains both attributes.

>>then turned on new features in all of them, via remote management, 
>>in a very short time.  Admittedly those nets were 200+ switches, 
>>not 600, but the principle was the same, i.e, tolerating transient 
>>routing instability in a net during the time it takes to turn on 
>>the new features.
>
>larger than the ARPANET. Even single tier-1 networks are 
>considerably larger than the ARPANET. And they are in competition, 
>so it's important to not tick off customers with lengthy downtimes 
>for maintenance.

no argument there. but the issue would seem to be how bad would the 
disruption be while the routers in a single, large AS, switched over. 
If, as you suggested, routers not yet running in secure mode and 
routers that have switched over can coexist for a prolonged period, 
while the latter select a non-conflicting subset of the routes used 
by the former, then why should the disruption for a fast changeover 
be awful?

>>>being the best, and only path 1 is verifiable, A will select path 
>>>1 (2 and 3 aren't secure) but B will select 2 because it is 
>>>"better" than 1. B would ideally select 3, but this isn't allowed 
>>>because that would create a loop. It's also something that can't 
>>>happen because A only sends 1 to B as 1 is the one it uses itself.
>
>>I didn't follow your example in detail. I am willing to believe 
>>that partial deployment within an AS might be OK, but I do worry 
>>that there are a lot of ways for it to fail.
>
>I imagine that people will want to run the security stuff in some 
>sort of "monitor" mode first, so that they get to see which routes 
>would be rejected without them actually being rejected yet. Going 
>from nothing to completely secure in one big leap would be too much 
>for most people, I imagine.

I agree entirely. When we built the first firewalls in the late 80's 
we allowed them to be run in a mode where we logged traffic that 
would be dropped if "a given rule set were enabled, to allow folks to 
become comfortable with the effect of turning on the rules. The same 
thing would be appropriate here.

>
>Also, an important problem is going to be the routing information 
>that is in fact good, but can't be verified as such. Especially in 
>the beginning this will be a large class because people have to get 
>the hang of the new system.

Right. incremental deployment means that you will get a mix of 
verified and unverified routing info, and we need to have simple 
rules on how to deal with this mix, and to report exceptions in an 
effort to help tune the rules.

>	<SNIP
>>for the rules.
>information: it's not in the RFCs or in Internet Routing 
>Architectures. So either it must have been in something more obscure 
>or I came up with this explanation on my own without realizing it...

it would be nice to know the rationale. who do you think we should ask, Yakov?

>
>>Also, the statistics I noted above on how often atomic still 
>>appears in Updates suggest that there are a number of operators who 
>>may not realize why the attribute is no longer needed.
>
>As Russ said, most aggregates aren't generated using aggregate 
>creation mechanisms, but simply by sourcing the aggregate as a new 
>prefix and filtering out the more specifics.

I'm afraid I don't understand how to interpret those words. Could you 
rephrase this, maybe add more detail and an example? Oh, never mind, 
I see you're provided a great example below.  Thanks.

>aggregates, but people getting address space from an ISP's PA block 
>and then announcing this space under their own AS. Obviously the 
>entire PA block will also be announced under the ISP's AS. Usually, 
>the ISP in question will also propagate the more specific. (If they 
>didn't, there wouldn't be any incoming traffic through this ISP as 
>the more specific points to another ISP.)

I understand that mechanism, which does not seem like aggregation to 
me, and which is easy to accommodate, by having the ISP that hands 
out the address space to a subscriber record that in a suitable, 
secure, fashion, that the subscriber can use to then authorize 
another ISP to originate the delegated prefix.

>problems because of the longest match first rule. However, if we 
>want to have the actual aggregation benefits, we need to get rid of 
>the more specifics. The problem with this is that if you do this in 
>one AS, the next AS is probably going to hear the aggregate and the 
>more specific from different sources. I.e.:
>
>   sourceAS
>    /   \
>ISPA   ISPB
>    \   /
>    ISPC
>      |
>    (inet)
>

and, ISP B announces the /24 to C, because that's what sourceAS 
announces to it, right?

>So if ISP A doesn't propagate the /24 to the ISP C, ISP C will see 
>the /8 from A and the /24 from B. In the current situation ISP C 
>will allow both the /8 and the /24 through, so there is no 
>aggregation as seen by anyone behind ISP C. With aggressive 
>aggregation, the /24 would go away (to come back when the /8 
>disappears, one hopes) but then the link over ISP becomes useless. 
>So what we really want is for ISP C to compare the AS path and/or 
>other metrics and select the path over B if this is better, but 
>ignore this path and use the aggregate if A is better. (C would 
>still most likely only propagate the aggregate downstream, though.)

On one hand its OK for ISP C to propagate only the /8, because C is a 
valid AS to route to both the /8 and the /24. The question, relative 
to the BGP spec, is what AS is advertised as the origin. It's 
legitimate to advertise just A, since it IS the "owner" for the /8, 
and nobody downstream would know the difference if they didn't know, 
independently, that the /24 had been delegated to sourceAS. if they 
did know this fact, then they might be justifiably suspicious of the 
advertisement, unless there was some way for them to know that 
sourceAs was still connected to A. Another possibility would be to 
advertise an AS set with A and ISPB as the origin, which would at 
least be consistent with external knowledge of sourceAS's delegation 
and its subsequent authorization of ISPB to advertise the /24.

A more interesting situation arises if source AS has another path to 
the rest of the Internet, say via ISPD, which does not connect back 
to ISPC. Now if C advertises just the /8, and not the /24, traffic 
for sourceAS will not flow via ISPC IF other ASes learn of the /24 
for sourceAS via ISPD. In that case, ISPC needs to advertise the /24, 
not just the /8, to enable both paths to sourceAS, right?

>The BGP RFC allows for this, and mandates that the ISP B AS is 
>listed in an AS_SET for the aggregate, and that the ATOMIC_AGGREGATE 
>attribute is added as an indication of what's going on. However, 
>unless I'm mistaken, all current implementations take the longest 
>match first rule as gospel, so none of this comes into play.

So, if the /24 is not aggregated this works fine for both your 
example and my slightly more elaborate one, even if nobody pays 
attention to the ATOMIC_AGGREGATE attribute. yes, I understand.

>So to answer your question: if noone is listening, it doesn't matter 
>if what you're saying is wrong. So in practice there are no 
>limitations on how you can aggregate.

nice "if a tree falls in the forest ..." analogy! But, if no one 
listens, all sorts of mayhem can occur, and we do see that happening 
sometimes.

>can't allow an unauthorized source to originate an aggregate. 
>However, this doesn't mean only the holder of the address space gets 
>to aggregate: people may trust others to aggregate for them.

I'll try to briefly explain what S-BGP calls for in cases like this, 
as an example of how we addressed this sort of issue.

(As an aside, I really dislike the use of the term "trust" in this 
context. If we start thinking in terms of trust relationships among 
ISPs, then we create opportunities for a security failure or a config 
error at one ISP to affect many others. Instead I like to think in 
terms of the authoritative sources of info for different forms of 
info. so, for example we have IANA and RIRs as sources for prefix and 
AS # allocations, and ISPs as sources for sub-allocations of 
prefixes.  Prefix holders, both ISPs of subscribers, are sources for 
authorizing ASes to advertise prefixes.)

In S-BGP, when ISPA allocated the /24 to sourceAS, it generated a 
cert for sourceAS expressing this allocation. ISPA would already have 
a cert that contained the /8 allocation from the RIR or IANA, or 
whoever allocated the /8 to ISPA. Thus the allocation of the /24 to 
sourceAS is OK, relative to the PKI model that we proposed, and that 
matches the address allocation (not advertisement) hierarchy.

Now, sourceAs, when it signs up with ISPB, issues a digitally signed 
blob, called an address attestation, to ISPB, which is the way than 
an address holder explicitly authorizes a specified AS to originate a 
prefix. ISPA issues an address attestation to itself, to advertise 
the /8 that it holds.  sourceAS also issues an address attestation to 
ISPA for the /24, to authorizing ISPA to still orignate the /24. 
(This is appropriate because sourceAS might have taken its business 
elsewhere and thus we nee to know whether ISPA is still authorized by 
the current holder of the /24 to originate it.)

The address attestations could be sent via Updates, but it seemed a 
waste t space to do so, because every AS potentially needs to be able 
to verify every address attestation for every routable prefix. So, 
S-BGP calls for distribution of this (signed) data via repositories. 
This also seems reasonable since the rate of change of this data is 
not that fast, i.e., address holders do not change the ISPs they 
authorized to originate their prefixes very frequently.

Now ISPA and ISPB send their advertisements to ISPC. ISPC, using data 
from the statically distributed address attestation database, sees 
that both A and B are authorized to originate the /24, and ISPA is 
authorized to originate the /8, so it accepts the advertisements from 
both. Now, when ISPC sends an advertisement to other ASes, there is 
the question of who is advertised as the origin. If either A or B or 
both appear, other ASes will accept that, because the address 
attestations support all of these assertions about who can originate 
the /24.

If, using my example, there is an ISPD that souceAS authorizes to 
originate the /24, then then there would be an entry in the address 
attestation database for that ISP as well. Thus ASes receiving 
advertisements from both C and D would view A, B, and D as legitimate 
origins for the /24. Note, however, that if sourceAS left ISPA, and 
no longer wanted that ISP to originate the /24, all sourceAs has to 
do is withdraw the address attestation for A. Then, A could advertise 
the /8, but, due to the longer match rule, the /24 advertised through 
B and D would take precedence, as one would want.

One can ask what other ASes would do if they fail to receive 
advertisements for the /24 from B or D. BGP says that a speaker will 
route based on a less specific prefix UNLESS it is aware of the 
existence of the more specific prefix. The knowledge of the more 
specific prefix is normally via Updates, but the local policy feature 
admits the potential to manually acquire info about a more specific 
prefixes. Use of IRR databases is an example of how to do this today, 
though very imperfectly. In S-BGP, the address attestation database 
represents a source for configuring the info of what ASes are 
authorized by prefix holders to advertise which prefixes. Thus 
provides a way for ASes to decide if they want to route the /24 
traffic to A, even when they know that ASes other than A are 
authorized to originate the /24, and A is not so authorized.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Jan 2005 18:30:38 -0500

At 8:47 PM +0100 1/6/05, Iljitsch van Beijnum wrote:
>Aren't there really just two things that we want/need protection against:
>

It's not trivial, as my example in another message shows, but it is 
largely a matter of a PKI plus other signed stuff to accommodate the 
issue of not only who holds/owns a prefix, but who that holder 
authorizes to advertise it.

>reachability illegitimately? We can't go by the source, both because 
>of the information explosion this causes and a wealth of practical 
>issues, and also because even if the source says that AS X isn't 
>supposed to be in their transit path, the destination may feel 
>otherwise so the path turns out OK anyway.
>
>Note that both soBGP and S-BGP (when I last looked at them) didn't 
>have mechanisms to handle this properly.

well, I can't speak for soBGP, but this is certainly what we 
attempted to do in S-BGP. I think we defined a way to do it, but it 
isn't free in terms of memory and computational costs. In talking 
with folks like Randy Bush, I learned that some of the estimates we 
made for memory were too conservative, so it might not be so bad in 
that regard. Also, now that there are some opportunities for using 
elliptic curve crypto w/o the sort of licensing problems that causes 
us to avoid it originally, we could reduce the amount of space that 
signatures occupy and speed up processing as well. (Folks at 
Dartmouth suggested use of ECC, but until patent issues were resolved 
it didn't seem to be a viable path.)  On the down side, experience 
with worms has shown that the computational costs can deviate from 
the average by more than we had expected, so one still worries about 
the computation costs of S-BGP.

Other proposals, that have appeared in the literature have worse 
performance problems. For example, some folks have expressed 
enthusiasm for SPV. But careful analysis of the SPV mechanisms 
suggests that it requires carriage and storage of signature data that 
is about 5 times bigger than for S-BGP! Also, the 20-fold performance 
improvement claimed (relative to S-BGP) does not take into account 
the signature deferral heuristic proposed for S-BGP in later work, 
which would significantly reduce the apparent benefits claimed by SPV.

>BGP can also happen for legitimate reasons, so I don't see how we 
>can realistically protect against that.

yes, given the great flexibility allowed by the local policy feature 
of BGP, it's hard to put very tight bounds on what is advertised.

>somehow determine whether traffic we send over a certain route 
>actually makes it to the destination AS. This would be incredibly 
>helpful even for regular misconfiguration and other routine 
>brokenness, but also in the cases where an attacker solicits traffic 
>but doesn't forward it to the real destination.

I see that as a monitoring aspect of security analogous to IDS use in 
an enterprise security environment. It's a useful feature to detect 
some forms of attacks, but not all, e.g., if one reroutes traffic to 
facilitate passive or active wiretapping, monitoring to detect 
whether the destination receives traffic will not detect such 
rerouting.

>If we make the credit card owner an AS and make a payment a route, 
>then we want traffic = money to follow legitimate routes, not fake 
>ones. Pretty similar.  :-)

We might care about the path a payment takes IF we are concerned 
about disclosure of the CC number, or for privacy purposes. But, 
that's quite a stretch for an analogy. Also, note that real threats 
to credit card abuse in the Internet context generally do not arise 
due to communication security failures (e.g., failure to protect the 
CC # en route), but rather arise because of the entity to whom we 
disclose the numbers (e.g., a bad web site).

>With just one tiny flaw: the standard doesn't fully describe what's 
>out there in the real world. I believe IDR is trying to remedy this, 
>but I'm not sure about how successful their efforts are. (Moving 
>target and all.)

Depending on the motivation for the deviations from the standard, 
this may or may not be a good justification for adopting other bases 
for security requirements. After all, some spammers attack BGP 
successfully, maybe often enough, to count as real world deviation 
from the standard.  Do we want to accommodate that in a security 
requirement :-) ?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Jan 2005 10:24:46 -0500

At 5:09 PM -0500 1/7/05, Russ White wrote:
>>The BGP spec deals with processing Updates, and does not address 
>>the infrastructure that supports address allocation, as we both 
>>know.
>

No, it's a justification for keeping in mind the role of the 
infrastructure in developing the security requirements.

Warning label: "Do not discard baby with bath water."

>>because a sub-allocation out of the /16 is no longer reachable via 
>>A. I cited specific text from the BGP spec that deals with this, in 
>>my memo so I will not bother restating the reasoning here.
>
>The /24 is a _part_ of the /16. Since the /24 is a _part_ of the 
>/16, how does A advertise the /16 without advertising the /24? IF A 
>cannot advertise the /16 without including the /24, and A does not 
>have authorization to advertise the /24, then it _cannot_ advertise 
>the /16.

I have explained how I interpret what the BGP spec says when there 
are overlapping prefixes, and I cited the relevant text. I don't know 
what more I can do to explain this, Russ.

Looking at the rest of your message, we seem to be rehashing 
questions for which I fee I have provided detailed responses, often 
with cites to relevant BGP spec text in support of my answers. This 
it does not seem a good use of my time or yours, or of the members of 
the WG to continue in this discussion, in this fashion.

I will prepare a message the IESG raising the issues we both agreed 
need to be resolved before we can progress.  I'll copy the list on 
the message, and when we get a resolution to this issue, then, 
hopefully, we can make progress.

Steve