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

From: Russ White <[email-masked]>
Date: Mon, 27 Dec 2004 15:24:21 -0500 (Eastern Standard Time)

Part of the comments we've received on this draft is there's no real 
"intro" section, to speak of, or rather something that explains what it is 
we're trying to secure. So, I've written some _possible_ text up, and would 
like to see it discussed, modified, and possibly inserted in the next 
version.

:-)

Russ

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

--

System Description

BGP is described in [BGP] as a routing protocol. Essentially, BGP
speakers exchange information about reachable destinations in an
internetwork through a peering session. Once this information has been
exchanged, each BGP speaker locally determines a loop free path to
each reachable destination, based on local policy, policy indicators
(or policies) carried in the update, and the AS Path carried in the
BGP update.

There are at least two points at which BGP could be secured, examining
this short description:

  o The session between two BGP speakers can be secured such that BGP
    data received by one of the BGP speakers can be cryptographically
    verified to have been transmitted by the other speaker.

  o The policy indicators carried within the update can be verified in
    some way, if the receiving BGP speaker knows the correct policies of
    each AS along the AS Path.

To this point, we've simply treated the BGP update as an independant
set of data, completely outside the context of what that data is used
for, or the data's use on a large scale throughout the
internetwork. There are, however, several questions we can ask about
the data carried within the update, in a larger sense. For instance,
the receiving BGP speaker could also attempt to check:

  o The authorization of the originating autonomous system, as listed
    in the AS Path of the BGP update, can be verified. This means the BGP
    speaker can check that the originating AS, as listed in the AS Path of
    the update, is actually authorized to originate the destination
    address indicated.

  o The validity of the AS Path carried within the update.

This last check, the validity of the AS Path carried within the
update, is a matter of some contention. There are various views on
what can be verified using the AS Path:

  o That the path listed in the AS Path actually exists, the AS Path
    describes a real path to the destination within the operating
    internetwork.

  o That the update has actually travelled the path listed in the AS
    Path of the update itself.

  o That the transmitter of this update is authorized by some previous
    transmitter to advertise the reachable destinations contained within
    the update.

While the first two are arguably provable within the context of BGP,
the third is questionable because of aggregation and filtering
normally applied within the internetworks BGP actually operates in,
and because of ambiguities in the concept of IP address ownership
within those systems. In this draft, then, we do not attmept to set
requirements dealing with the third issue, but leave this as an area
of study for the various systems designed for securing BGP.

We could use some discussion on this wording, and its concepts, before
adopting it as a part of the draft.

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Dec 2004 18:24:26 -0500

Russ,

Since Alex suggested that it would be be better for me to provide 
text, than to just comment on text, I have taken the liberty of 
drafting a fair amount of new text for the intro.  I did have a few 
questions on some of your original text; the questions are marked by 
angle brackets. The original text is plain, new text is bold. I used 
standard security terms (RFC 2828) to characterize requirements, and 
I noted the issue of the dynamics of the two different forms of 
inputs to the BGP routing algorithm. I also tried to characterize the 
two types of inputs to the algorithm in a more general fashion.

Steve
------

System Description

BGP is described in [BGP] as a routing protocol. Each pair of BGP 
speakers exchanges information about reachable destinations (address 
prefixes) in an internetwork through a peering session. Once this 
information has been exchanged, each BGP speaker locally determines a 
loop free path to each reachable destination, based on local policy, 
policy indicators

<what is a "policy indicator?" is this term used in the BGP RFC?

(or policies) <what policies are carried in UPDATEs? are you 
referring to community value attributes? if so, it would be better to 
use that term, and give examples that illustrate how some of these 
values act as policy info.>

carried in the update, and the AS Path carried in the BGP update.

A principle goal for BGP security is to ensure that BGP speakers can 
execute the BGP route selection algorithm using inputs that are 
accurate. These inputs come from two sources, as indicated above: 
UPDATEs received via peering sessions and local policy data 
introduced by the managers of the AS to which each speaker belongs. 
This suggests that security requirements for BGP should address the 
integrity and authenticity of both sources of inputs. Note that the 
two data sources have different characteristics in terms of the 
dynamics of the data, i.e., data in UPDATEs is presumed to be

1. A BGP speaker operates on the assumption that the peering session 
between it and another BGP speaker is secure, specifically:
	- the peer is the one identified in a configuration database
	- that all traffic received via the peering session 
originates from the peer, has not been modified en route, and is 
"fresh."

Using common security terminology, a BGP speaker requires peer-entity 
authentication and connection-oriented integrity for the session.

<note that the wording immediately above does not mandate use of 
cryptography, but rather establishes requirements, consistent with 
the focus of this document on requirements, vs. solution mechanisms.>

Much of the data contained in an UPDATE often originates from an AS 
other than the immediate peer of a BGP speaker that receives the 
UPDATE. The security requirements defined for a peering session 
(above) cannot establish the integrity and authenticity of much of 
the content of an UPDATE, since those requirements address only 
immediate, pairwise integrity and authenticity security features. BGP 
specifies how each AS along the path is supposed to process the data 
it receives to produce any UPDATEs that are emitted as a result of 
receiving an UPDATE. Thus another aspect of securing UPDATE-based 
(vs. locally configured) inputs is to allow a BGP speaker to 
determine if the content of an UPDATE is "valid" as defined by the 
BGP processing specifications.

This is a challenging requirement because BGP allows each AS along a 
path considerable discretion in processing a received UPDATE. 
However, there are many aspects of processing that are verifiable, at 
least in principle.
     - The last AS in the path is the origin AS, and it should be 
possible to verify the authorization of the AS in question to 
originate the prefixes in the UPDATE.
     - The AS path contained in the UPDATE nominally indicates the 
path traveled by the UPDATE. Note that the use of aggregation by ASes 
may cause the AS path to omit some ASes via which the UPDATE was 
propagated, so one has to exercise care in evaluating this aspect of 
UPDATE validity. However, one can verify some aspect of path 
validity, e.g., no AS should appear in a path unless a speaker from 
the AS in question emitted the UPDATE (or an UPDATE from which this 
UPDATE is derived). Also, the order of the ASes in the path should 
reflect the order that UPDATEs traversed these ASes, etc. Since 
UPDATEs represent realtime inputs to the route calculation process it 
is desirable that verification of UPDATE validity be based on 
realtime data.

2. The local policy data used by a speaker is configured by managers 
for the AS to which the speaker belongs, as noted above. Some of this 
data represents purely local information for which the AS is 
authoritative, e.g., agreements to forward transit traffic based on 
contractual arrangements. For such data, only locally-applied 
security procedures can be employed to help ensure accuracy. However, 
other data may be gleaned from authoritative sources and thus an 
architecture for BGP security should establish mechanisms to 
facilitate secure distribution of this data.

Security for this data implies that each AS can identify the source 
of the data, determine that the data has not been modified en route, 
and be able to determine whether the source is authoritative for the 
data in question. Since there is no requirement that this data be 
acquired directly from each source (BGP does not specify how the data 
is acquired and it is common for such data to be distributed via 
repositories operated by third parties), connectionless integrity and 
data origin authentication, are the appropriate security 
requirements. Note that since this data is fairly static, 
verification of its accuracy can be based on similarly static 
measures without significant loss of security functionality.
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Mon, 27 Dec 2004 20:27:28 -0500 (Eastern Standard Time)

> <what is a "policy indicator?" is this term used in the BGP RFC?

This isn't used in the BGP drafts, but it's easier to come up with some 
term than to try and add each individual thing a BGP speaker may make a 
decision on, such as the MED, various communities, etc. Note communities 
and extended communities, often used to express policy, are not covered in 
the base BGP draft, so there's no need to be concerned with these concepts 
there.

> (or policies) <what policies are carried in UPDATEs? are you referring to 
> community value attributes? if so, it would be better to use that term, and 
> give examples that illustrate how some of these values act as policy info.>

I think it might be better to add a definition to define some local term, 
within the draft, to mean communities+meds+any future things someone might 
dream up. It would make the document more easily readable, probably (?).

> execute the BGP route selection algorithm using inputs that are accurate.

I wouldn't phrase it this way. BGP primarily wants to find loop free paths 
through an internetwork, not execture an algorithm. It executes an 
algorithm in order to find loop free paths, but the algorithm isn't the 
focus of the protocol, the final result--loop free paths--is.

> These inputs come from two sources, as indicated above: UPDATEs received 
> via peering sessions and local policy data introduced by the managers of 
> the AS to which each speaker belongs. This suggests that security 
> requirements for BGP should address the integrity and authenticity of 
> both sources of inputs. Note that the two data sources have different 
> characteristics in terms of the dynamics of the data, i.e., data in 
> UPDATEs is presumed to be

> 1. A BGP speaker operates on the assumption that the peering session between 
> it and another BGP speaker is secure, specifically:
> 	- that all traffic received via the peering session originates from 
> the peer, has not been modified en route, and is "fresh."
>
> cryptography, but rather establishes requirements, consistent with the focus 
> of this document on requirements, vs. solution mechanisms.>

This sounds fine to me....

> Much of the data contained in an UPDATE often originates from an AS other 
> than the immediate peer of a BGP speaker that receives the UPDATE. The 
> security requirements defined for a peering session (above) cannot 
> establish the integrity and authenticity of much of the content of an 
> UPDATE, since those requirements address only immediate, pairwise 
> integrity and authenticity security features. BGP specifies how each AS 
> along the path is supposed to process the data it receives to produce any 
> UPDATEs that are emitted as a result of receiving an UPDATE. Thus another 
> aspect of securing UPDATE-based (vs. locally configured) inputs is to 
> allow a BGP speaker to determine if the content of an UPDATE is "valid" 
> as defined by the BGP processing specifications.

> This is a challenging requirement because BGP allows each AS along a path 
> considerable discretion in processing a received UPDATE. However, there are 
> many aspects of processing that are verifiable, at least in principle.

>    - The last AS in the path is the origin AS, and it should be possible to 
> verify the authorization of the AS in question to originate the prefixes in 
> the UPDATE.

I think this should actually be the first AS in the update, but different 
people use different terms for this. It depends on whether the last person 
puts the last as in the path, or the last person puts the first as in the 
path.

>    - The AS path contained in the UPDATE nominally indicates the path 
> traveled by the UPDATE. Note that the use of aggregation by ASes may 
> cause the AS path to omit some ASes via which the UPDATE was propagated, 
> so one has to exercise care in evaluating this aspect of UPDATE validity. 
> However, one can verify some aspect of path validity, e.g., no AS should 
> appear in a path unless a speaker from the AS in question emitted the 
> UPDATE (or an UPDATE from which this UPDATE is derived). Also, the order 
> of the ASes in the path should reflect the order that UPDATEs traversed 
> these ASes, etc. Since UPDATEs represent realtime inputs to the route 
> calculation process it is desirable that verification of UPDATE validity 
> be based on realtime data.

And this is where I'll disagree. The worry isn't over the validity of the 
information in a specific update, in terms of "has it been altered," but 
rather the validity of what's in the update verses what the real world 
looks like. In other words, it's not that someone has replaced "these" bits 
with "those" bits, it just matters if the replacement will cause invalid 
routing decisions to be made.

It's hard to think of metaphors for this, but I would say it's similar to 
making certain the plastic card containing your credit card numbers looks 
the same as the plastic card the credit card company issued you. That's not 
a valuable piece of validity in the credit card world--we're more worried 
about the authenticity of the information the card contains, than the 
authenticity of the card itself.

Again, I don't care if it's the original update, only that the information 
in the update represents the real world. When I'm trying to decide if an 
update carries valid information or not, I don't care where it came from, I 
care about whether the information it carries reflects the real world. In 
other words, if someone hands me a BGP update, I don't want to trust Jack 
more than I trust Jill, just because Jack is Jack. I want to be able to 
evaluate Jack's and Jill's information based on reality.

I have a two pointed challenges for you:

-- First, prove BGP cares that the path contained in an update is the path 
the update actually took. It's well known that the update path is 
manipulated for many legitimate reasons today.

-- Second, find a requirement to actually back up your assertion that this 
is important. The only point where what you're discussing here matters is 
in non-repudiation, not in update validity. See above on the concept of 
what's in the update verses the actual update.

I don't see any reason to include language of this type--pushing concepts 
into BGP that don't exist in the protocol itself, and pushing the focus 
onto a subsidiary point, while ignoring the larger point.

> 2. The local policy data used by a speaker is configured by managers for 
> the AS to which the speaker belongs, as noted above. Some of this data 
> represents purely local information for which the AS is authoritative, 
> e.g., agreements to forward transit traffic based on contractual 
> arrangements. For such data, only locally-applied security procedures can 
> be employed to help ensure accuracy. However, other data may be gleaned 
> from authoritative sources and thus an architecture for BGP security 
> should establish mechanisms to facilitate secure distribution of this 
> data.
>
> Security for this data implies that each AS can identify the source of 
> the data, determine that the data has not been modified en route, and be 
> able to determine whether the source is authoritative for the data in 
> question. Since there is no requirement that this data be acquired 
> directly from each source (BGP does not specify how the data is acquired 
> and it is common for such data to be distributed via repositories 
> operated by third parties), connectionless integrity and data origin 
> authentication, are the appropriate security requirements. Note that 
> since this data is fairly static, verification of its accuracy can be 
> based on similarly static measures without significant loss of security 
> functionality.

I don't know that I understand these two paragraphs at all, really (?). Are 
you saying that each AS should have a way to propogate policy to all other 
AS' without embedding that information in BGP? It seems to me that this 
should be down in the requirements sections, if we're going to add this 
sort of requirement, rather than in the intro?

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Mon, 27 Dec 2004 21:11:03 -0500 (Eastern Standard Time)

>> traveled by the UPDATE. Note that the use of aggregation by ASes may cause 
>> the AS path to omit some ASes via which the UPDATE was propagated, so one 
>> has to exercise care in evaluating this aspect of UPDATE validity. However, 
>> one can verify some aspect of path validity, e.g., no AS should appear in a 
>> path unless a speaker from the AS in question emitted the UPDATE (or an 
>> UPDATE from which this UPDATE is derived). Also, the order of the ASes in 
>> the path should reflect the order that UPDATEs traversed these ASes, etc. 
>> Since UPDATEs represent realtime inputs to the route calculation process it 
>> is desirable that verification of UPDATE validity be based on realtime 
>> data.
>
> looks like. In other words, it's not that someone has replaced "these" 
> bits with "those" bits, it just matters if the replacement will cause 
> invalid routing decisions to be made.

Actually, I was thinking about this some more, and I have another possible 
way to put it. Suppose you have this:

A---B---C---D

Suppose A sends an update to B, and this update finally gets to D through 
some process. Now, there are two questions we can ask about this update:

-- Did the update actually traverse the path A/B/C/D?

-- Does the path A/B/C/D actually exist?

I think these are two fundamentally different questions--one is a question 
about non-repudiation, the other about the validity of the information 
contained in the update. I don't know that we should assume answering the 
first question always answers the second question, and even if we did, I 
don't think such an assumption should be buried in the document.

Each question should really be called out on its own, so we get at the real 
requirements at hand, rather than assuming we don't need the answer the 
second question if we answer the first.

I hope that makes more sense (?).

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Dec 2004 13:20:48 -0500

At 9:11 PM -0500 12/27/04, Russ White wrote:
>>>path traveled by the UPDATE. Note that the use of aggregation by 
>>>ASes may cause the AS path to omit some ASes via which the UPDATE 
>>>was propagated, so one has to exercise care in evaluating this 
>>>aspect of UPDATE validity. However, one can verify some aspect of 
>>>path validity, e.g., no AS should appear in a path unless a 
>>>speaker from the AS in question emitted the UPDATE (or an UPDATE 
>>>from which this UPDATE is derived). Also, the order of the ASes in 
>>>the path should reflect the order that UPDATEs traversed these 
>>>ASes, etc. Since UPDATEs represent realtime inputs to the route 
>>>calculation process it is desirable that verification of UPDATE 
>>>validity be based on realtime data.
>>
>>And this is where I'll disagree. The worry isn't over the validity 
>>of the information in a specific update, in terms of "has it been 
>>altered," but rather the validity of what's in the update verses 
>>what the real world looks like. In other words, it's not that 
>>someone has replaced "these" bits with "those" bits, it just 
>>matters if the replacement will cause invalid routing decisions to 
>>be made.
>
>Actually, I was thinking about this some more, and I have another 
>possible way to put it. Suppose you have this:
>
>A---B---C---D
>
>Suppose A sends an update to B, and this update finally gets to D 
>through some process. Now, there are two questions we can ask about 
>this update:
>
>I think these are two fundamentally different questions--one is a 
>question about non-repudiation, the other about the validity of the 
>information contained in the update. I don't know that we should 
>assume answering the first question always answers the second 
>question, and even if we did, I don't think such an assumption 
>should be buried in the document.

As I noted elsewhere, NR is not the right security term here, but I 
understand the question you are raising. I think the answer is that 
we do care about how the Update got to D, at least to some extent.

There are lots of inter-As links in the Internet, but each AS decides 
what traffic is allowed to traverse which links, in a local sense. 
BGP is the way that ASes tell one another the subset of path info 
that they want to advertise, and for what traffic (based on 
destination address prefix matching rules) vs. the much larger set of 
paths (sequences of links) that exist, or even paths that exist but 
are restricted to other sets of NLRI.

This says that even if we receive an Update that represents a path 
that exists, that does not necessarily imply that the route 
represented by the Update has been authorized by the ASes along the 
path. Moreover, there is an issue of timeliness, i.e., do these ASes 
currently authorize advertisement of this route?

I'm not saying that one cannot find other ways to verify that all of 
the ASes along the path authorize propagation of the route in an 
Update. But, I am saying that the simplest model is the one that the 
BGP spec defines. if we try to develop another model that promises to 
yield the same answer, we will have a much harder job, since we will 
bneed to demonstrate that the results are equivalent in all cases.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Dec 2004 13:56:01 -0500

At 8:27 PM -0500 12/27/04, Russ White wrote:
>>speakers exchanges information about reachable destinations 
>>(address prefixes) in an internetwork through a peering session. 
>>Once this information has been exchanged, each BGP speaker locally 
>>determines a loop free path to each reachable destination, based on 
>>local policy, policy indicators
>
>This isn't used in the BGP drafts, but it's easier to come up with 
>some term than to try and add each individual thing a BGP speaker 
>may make a decision on, such as the MED, various communities, etc. 
>Note communities and extended communities, often used to express 
>policy, are not covered in the base BGP draft, so there's no need to 
>be concerned with these concepts there.

Well, if they are no to be included, we just need a concise 
definition of what you do want to include, and an example for clarity.

>>referring to community value attributes? if so, it would be better 
>>to use that term, and give examples that illustrate how some of 
>>these values act as policy info.>
>
>I think it might be better to add a definition to define some local 
>term, within the draft, to mean communities+meds+any future things 
>someone might dream up. It would make the document more easily 
>readable, probably (?).
>
>>A principle goal for BGP security is to ensure that BGP speakers 
>>can execute the BGP route selection algorithm using inputs that are 
>>accurate.
>
>I wouldn't phrase it this way. BGP primarily wants to find loop free 
>paths through an internetwork, not execture an algorithm. It 
>executes an algorithm in order to find loop free paths, but the 
>algorithm isn't the focus of the protocol, the final result--loop 
>free paths--is.

I agree that the ultimate goal is to become aware of paths, but since 
we agree that the PBGP specs  says that the means by which the paths 
are computed is via the algorithm defined in the spec, it seems 
appropriate to emphasize that aspect.

>
>>These inputs come from two sources, as indicated above: UPDATEs 
>>received via peering sessions and local policy data introduced by 
>>the managers of the AS to which each speaker belongs. This suggests 
>>that security requirements for BGP should address the integrity and 
>>authenticity of both sources of inputs. Note that the two data 
>>sources have different characteristics in terms of the dynamics of 
>>the data, i.e., data in UPDATEs is presumed to be
>
>>1. A BGP speaker operates on the assumption that the peering 
>>session between it and another BGP speaker is secure, specifically:
>>Using common security terminology, a BGP speaker requires 
>>peer-entity authentication and connection-oriented integrity for 
>>the session.
>>

OK.

>>immediate, pairwise integrity and authenticity security features. 
>>BGP specifies how each AS along the path is supposed to process the 
>>data it receives to produce any UPDATEs that are emitted as a 
>>result of receiving an UPDATE. Thus another aspect of securing 
>>UPDATE-based (vs. locally configured) inputs is to allow a BGP 
>>speaker to determine if the content of an UPDATE is "valid" as 
>>defined by the BGP processing specifications.
>
>>This is a challenging requirement because BGP allows each AS along 
>>a path considerable discretion in processing a received UPDATE. 
>>However, there are many aspects of processing that are verifiable, 
>>at least in principle.
>
>I think this should actually be the first AS in the update, but 
>different people use different terms for this. It depends on whether 
>the last person puts the last as in the path, or the last person 
>puts the first as in the path.

I have to admit that I get confused about first vs. last here! 
Whatever folks says is right is fine with me, so long as we are 
consistent :-).

>>path validity, e.g., no AS should appear in a path unless a speaker 
>>from the AS in question emitted the UPDATE (or an UPDATE from which 
>>this UPDATE is derived). Also, the order of the ASes in the path 
>>should reflect the order that UPDATEs traversed these ASes, etc. 
>>Since UPDATEs represent realtime inputs to the route calculation 
>>process it is desirable that verification of UPDATE validity be 
>>based on realtime data.
>
>someone has replaced "these" bits with "those" bits, it just matters 
>if the replacement will cause invalid routing decisions to be made.

I guess if I were Bill (Clinton or Gates) I would say it depends on 
what you mean by "invalid." If a speaker (or an on-the-wire attacker) 
changes bits in a fashion not consistent with the Update processing 
algorithm, then the result is inaccurate, relative to what the spec 
says should happen.  Presumably we want to allow speakers to detect 
misbehavior if it would result in misrouting, right? I think you are 
suggesting that we don't need to detect misbehavior so long as the 
results of the misbehavior are "valid." Well, that may be true, but 
if you want to assert this, you have to demonstrate that an 
alternative security model is equivalent to what one would get if one 
adopted the simple model that BGP calls for.

The phrase "what the real world looks like" is a bit imprecise. Form 
a routing perspective, one might nee to know the local policy data 
for every AS, and the current up/down status for all links, to know 
"what the real world looks like"" in evaluating an Update. That's 
seems like a lot to ask. BGP just says that Updates are processed in 
a way that takes into account local policies and current link status. 
Thus if we can verify that an Update is valid in the normal BGP 
processing sense, we don't have to address the issue of explicitly 
publishing local policy info or the practical impossibility of 
distributing link status securely in real time via another mechanism.

>It's hard to think of metaphors for this, but I would say it's 
>similar to making certain the plastic card containing your credit 
>card numbers looks the same as the plastic card the credit card 
>company issued you. That's not a valuable piece of validity in the 
>credit card world--we're more worried about the authenticity of the 
>information the card contains, than the authenticity of the card 
>itself.

An interesting metaphor.  Note that if someone makes a copy of the 
data on the card and uses it to make another card (or to make a 
telephone, mail order or Internet purchase), and the person doing so 
is not the authorized card holder, we consider this to be fraud. It 
is not good enough to represent the data on the card accurately. So, 
I think that you don't want to use this analogy!

>Again, I don't care if it's the original update, only that the 
>information in the update represents the real world. When I'm trying 
>to decide if an update carries valid information or not, I don't 
>care where it came from, I care about whether the information it 
>carries reflects the real world. In other words, if someone hands me 
>a BGP update, I don't want to trust Jack more than I trust Jill, 
>just because Jack is Jack. I want to be able to evaluate Jack's and 
>Jill's information based on reality.

I disagree, and your metaphor above gives a good example of why.

>-- First, prove BGP cares that the path contained in an update is 
>the path the update actually took. It's well known that the update 
>path is manipulated for many legitimate reasons today.

I have assumed that we want to generate requirements based on what 
BGP says is correct operation. I believe that BGP specifies the 
circumstances under which a speaker is to emit an Update, either as a 
side effect of processing a inbound Update or due to detection of 
loss of connectivity. That suggests that our requirements should try 
to capture this notion.

If, as you suggest, we do not verify that an Update has traversed the 
path indicated by the path attribute (modulo aggregation) then BGP is 
susceptible to attacks that advertise bogus path.  What you seem to 
be arguing is that if a speaker advertises a path that is not 
currently being advertised by the preceding ASes list in the path, 
but one that could legitimately be advertised based on local policy 
configurations in those ASes, then that is OK.

I challenge you to show me where the BGP spec includes this notion!

BGP makes provision to use both static data and dynamic data as 
inputs to the routing algorithm. If dynamic data were not needed, 
then we would not need to bother with Updates; we could just all the 
topology and policy info into each speaker and be done.  But, we know 
that this sort of configuration is not sufficient for many ASes, and 
that the dynamic data about what paths are currently being advertised 
IS important.

>-- Second, find a requirement to actually back up your assertion 
>that this is important. The only point where what you're discussing 
>here matters is in non-repudiation, not in update validity. See 
>above on the concept of what's in the update verses the actual 
>update.

first, the term non-repudiation is not really applicable here. The 
security features we want are multicast receiver integrity and 
authentication. But, as for the why we need to pay attention to how 
we got an Update, I think my analysis above addresses that question.

>I don't see any reason to include language of this type--pushing 
>concepts into BGP that don't exist in the protocol itself, and 
>pushing the focus onto a subsidiary point, while ignoring the larger 
>point.

As expected, we disagree. I think what I have said is directly 
derived from the description of BGP processing. In contrast, what you 
are advocating is a wording that seems to be designed to accommodate 
soBGP's notion of validity based on statically configured policy data.

>>2. The local policy data used by a speaker is configured by 
>>managers for the AS to which the speaker belongs, as noted above. 
>>Some of this data represents purely local information for which the 
>>AS is authoritative, e.g., agreements to forward transit traffic 
>>based on contractual arrangements. For such data, only 
>>locally-applied security procedures can be employed to help ensure 
>>accuracy. However, other data may be gleaned from authoritative 
>>sources and thus an architecture for BGP security should establish 
>>mechanisms to facilitate secure distribution of this data.
>>
>>of the data, determine that the data has not been modified en 
>>route, and be able to determine whether the source is authoritative 
>>for the data in question. Since there is no requirement that this 
>>data be acquired directly from each source (BGP does not specify 
>>how the data is acquired and it is common for such data to be 
>>distributed via repositories operated by third parties), 
>>connectionless integrity and data origin authentication, are the 
>>appropriate security requirements. Note that since this data is 
>>fairly static, verification of its accuracy can be based on 
>>similarly static measures without significant loss of security 
>>functionality.
>
>I don't know that I understand these two paragraphs at all, really 
>(?). Are you saying that each AS should have a way to propogate 
>policy to all other AS' without embedding that information in BGP? 
>It seems to me that this should be down in the requirements 
>sections, if we're going to add this sort of requirement, rather 
>than in the intro?

The means by which we address this issue need not be in the intro. 
But I do think the intro needs to explicitly recognize the fact that 
BGP relies on both dynamic data and static data as inputs to the 
algorithm. Thus we have to pay attention to integrity, authenticity, 
and authorization for the static data, as well as the dynamic data.

I though you were suggesting that we pay attention to this issue 
earlier, when you emphasized the need for a "systems approach" to BGP 
security. I was trying to accommodate this concern you raised, in a 
fashion that is still grounded in the BGP spec, even though the means 
by which the data is made available to AS managers is outside the 
spec and does not involve the border gateway protocol per se.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 28 Dec 2004 16:17:46 -0500 (Eastern Standard Time)

> understand the question you are raising. I think the answer is that we do 
> care about how the Update got to D, at least to some extent.
>
> what traffic is allowed to traverse which links, in a local sense. BGP is 
> the way that ASes tell one another the subset of path info that they want 
> to advertise, and for what traffic (based on destination address prefix 
> matching rules) vs. the much larger set of paths (sequences of links) 
> that exist, or even paths that exist but are restricted to other sets of 
> NLRI.
>
> This says that even if we receive an Update that represents a path that 
> exists, that does not necessarily imply that the route represented by the 
> Update has been authorized by the ASes along the path. Moreover, there is 
> an issue of timeliness, i.e., do these ASes currently authorize 
> advertisement of this route?

You can't know this from the update, anyway, as is shown in 
draft-white-pathconsiderations, the latest version of which is here:

http://www.riw.us/temp/draft-white-pathconsiderations-05.txt

Basically, you're assuming that if I receive an update, I'm somehow 
"authorized" to use the path contained in the update to forward traffic. 
That plainly isn't true, for two reasons:

-- An update contains a block of addresses which may be advertised by 
someone other than the owner of the block of addresses, and outside the 
owner's control.

-- The traffic may not flow along the AS Path contained in the update, so 
the concept of being "authorized to use a path" is not applicable in the 
case of BGP.

Now, you'll say this doesn't imply traffic flow, but clearly the paragraph 
above _does_ imply traffic flow, and policy, rather than securing the 
routing information in the proper sense.

> I'm not saying that one cannot find other ways to verify that all of the 
> ASes along the path authorize propagation of the route in an Update. But, 
> I am saying that the simplest model is the one that the BGP spec defines. 
> if we try to develop another model that promises to yield the same 
> answer, we will have a much harder job, since we will bneed to 
> demonstrate that the results are equivalent in all cases.

BGP doesn't have the concept you're talking about. The problem should be 
split into two pieces, at least, and possibly three or four:

-- Does the path exist?
-- Was the update actually originated by/forwarded along this path
    (which only applies to some form of non-repudiation, and nothing else)?
-- Am I authorized to use this path (outside the set of questions
    answerable within BGP today)?
-- Am I authorized to advertise this route to my peer (covered by many
    various mechanisms within BGP today, and coverable using many
    mechanisms within various possible security systems)?

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.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 28 Dec 2004 16:36:11 -0500 (Eastern Standard Time)

> I have assumed that we want to generate requirements based on what BGP 
> says is correct operation. I believe that BGP specifies the circumstances 
> under which a speaker is to emit an Update, either as a side effect of 
> processing a inbound Update or due to detection of loss of connectivity. 
> That suggests that our requirements should try to capture this notion.
>
> susceptible to attacks that advertise bogus path.  What you seem to be 
> arguing is that if a speaker advertises a path that is not currently 
> being advertised by the preceding ASes list in the path, but one that 
> could legitimately be advertised based on local policy configurations in 
> those ASes, then that is OK.
>

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.

Yes, I am implying that if a speaker advertises a route that doesn't exist, 
for policy reasons, it is "okay." For instance, a rather mild example is as 
path prepend. This clearly creates a path that does not exist within the 
update, and it is "okay." Another for instance--placing a third party AS in 
the AS set when I advertise updates to a peer, to block those routes from 
being readvertised through BGP's loop detection mechanism. Again, there is 
a path that doesn't exist in the update, and it's used on a periodic basis 
in the real world.

Even the case of aggregation proves the point--the path in the aggregated 
route does not exist, for at least some of the reachable destinations 
within the aggregate. For instance, 10.1.0.0/16 may be advertised with a 
path of {1, 2}, but in reality, the path to 10.1.1.0/24 is {1, 2, 3}. Thus, 
10.1.1.0/24 is not reachable through the path {1, 2}, and yet BGP lives 
with this, somehow. So, yet another case in common use where the as path 
doesn't match the real as path used to reach the destinations within the 
update.

> As expected, we disagree. I think what I have said is directly derived 
> from the description of BGP processing. In contrast, what you are 
> advocating is a wording that seems to be designed to accommodate soBGP's 
> notion of validity based on statically configured policy data.

Can you show me the point in the BGP drafts that describe this as the only 
way a BGP update can be processed? When I examine the definition of the AS 
Path, I find this:

"AS_PATH is a well-known mandatory attribute that is composed of a sequence 
of AS path segments. Each AS path segment is represented by a triple <path 
segment type, path segment length, path segment value>."

I don't see anything in there about: "the AS Path MUST represent the 
autonomous systems through which this update has passed." Can you find the 
language to support your assertion?

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 28 Dec 2004 16:55:23 -0500 (Eastern Standard Time)

> notion of validity based on statically configured policy data.

And actually, I would point out something here:

-- You are implying in the paragraph above that you would prefer to see a 
set of requirements that will not accomidate anything except S-BGP.

-- The wording I've suggested will allow soBGP, S-BGP, IRV, and SPV to meet 
them, I think.

I don't think I'm trying to sway the process in any direction, I'm trying 
to get at the real requirements, and break them down into their component 
parts, so I can understand them, and help others understand them. I'm not 
working from "this is the best set of requirements for soBGP," I'm working 
from: "What is it we can really do and what are our materials at hand?"

It's not helpful to make your only requirement: "To secure BGP as BGP is 
described in the BGP drafts." That leaves out two rather large pieces of 
the puzzle--how BGP is implemented, and how BGP is actually used. I don't 
think we should leave those concepts out of the mix.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Dec 2004 16:52:07 -0500

At 4:17 PM -0500 12/28/04, Russ White wrote:
>>>through some process. Now, there are two questions we can ask 
>>>about this update:
>>>
>>>question about non-repudiation, the other about the validity of 
>>>the information contained in the update. I don't know that we 
>>>should assume answering the first question always answers the 
>>>second question, and even if we did, I don't think such an 
>>>assumption should be buried in the document.
>>
>>There are lots of inter-As links in the Internet, but each AS 
>>decides what traffic is allowed to traverse which links, in a local 
>>sense. BGP is the way that ASes tell one another the subset of path 
>>info that they want to advertise, and for what traffic (based on 
>>destination address prefix matching rules) vs. the much larger set 
>>of paths (sequences of links) that exist, or even paths that exist 
>>but are restricted to other sets of NLRI.
>>
>>path. Moreover, there is an issue of timeliness, i.e., do these 
>>ASes currently authorize advertisement of this route?
>

Thanks for the pointer.

>"authorized" to use the path contained in the update to forward 
>traffic. That plainly isn't true, for two reasons:

If AS 1 advertises a route to AS 2, I interpret that as an 
authorization for AS 2 to send traffic for the indicated prefix(es) 
to AS 1.  Do you disagree? If so, then what do you maintain is the 
reason that AS 1 advertises a route to AS 2?

>-- An update contains a block of addresses which may be advertised 
>by someone other than the owner of the block of addresses, and 
>outside the owner's control.

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?

Or do you mean to say that correct BGP behavior allows any AS to add 
arbitrary prefixes to an Update?

>-- The traffic may not flow along the AS Path contained in the 
>update, so the concept of being "authorized to use a path" is not 
>applicable in the case of BGP.

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

>Now, you'll say this doesn't imply traffic flow, but clearly the 
>paragraph above _does_ imply traffic flow, and policy, rather than 
>securing the routing information in the proper sense.

I have no idea what the sentence above means.

>>I'm not saying that one cannot find other ways to verify that all 
>>of the ASes along the path authorize propagation of the route in an 
>>Update. But, I am saying that the simplest model is the one that 
>>the BGP spec defines. if we try to develop another model that 
>>promises to yield the same answer, we will have a much harder job, 
>>since we will bneed to demonstrate that the results are equivalent 
>>in all cases.
>
>BGP doesn't have the concept you're talking about. The problem 
>should be split into two pieces, at least, and possibly three or 
>four:
>
>-- Does the path exist?

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.

>    (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.

>    answerable within BGP today)?

I don't know what you are trying to say here.

>    mechanisms within various possible security systems)?

yes, an important part of routing.

>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?

It has been suggested that maybe we should not just try to secure BGP 
as it exists, but rather consider what changes could be made to BGP 
to make it better, and then secure the result.  That might be a good 
suggestion, but it is not consistent with the WG charter, or with the 
description of the requirements document that we are working on now. 
That's why I note that the questions we need to ask must be framed in 
the context of the protocol we have and how it is defined to work.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 28 Dec 2004 18:18:07 -0500 (Eastern Standard Time)

> If AS 1 advertises a route to AS 2, I interpret that as an authorization 
> for AS 2 to send traffic for the indicated prefix(es) to AS 1.  Do you 
> disagree? If so, then what do you maintain is the reason that AS 1 
> advertises a route to AS 2?

See the second example, section 2.3, in the draft I pointed out above. This 
is clearly not true, because of the ambiguities in address ownership and 
aggregation.

> 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 you think about the answers to these questions, you'll see why you 
cannot make the assumption you're making above.

> 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.

> "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.

> 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. :-)

> 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.

>> problem, and takes away the designer's ability to address them in 
>> various ways.
>
> 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.

Again, I think the correct questions we should ask when writing the 
requirements are:

-- Can I prove a path exists?
-- 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).

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

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?

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Dec 2004 10:17:23 -0500

At 4:55 PM -0500 12/28/04, Russ White wrote:
>>derived from the description of BGP processing. In contrast, what 
>>you are advocating is a wording that seems to be designed to 
>>accommodate soBGP's notion of validity based on statically 
>>configured policy data.
>
>-- You are implying in the paragraph above that you would prefer to 
>see a set of requirements that will not accomidate anything except 
>S-BGP.

That's your interpretation of my comments, which leaves a lot to be 
desired in terms of accuracy.

>-- 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!

>I don't think I'm trying to sway the process in any direction, I'm 
>trying to get at the real requirements, and break them down into 
>their component parts, so I can understand them, and help others 
>understand them. I'm not working from "this is the best set of 
>requirements for soBGP," I'm working from: "What is it we can really 
>do and what are our materials at hand?"

 From my perspective, this is not evident in your choice of words in 
proposed text. You continually create terms that are thinly veiled 
references to the soBGP notion of a database that contains all 
"valid" routes or all paths that "exist", and say that this should be 
the criteria by which we judge whether an Update is valid. There are 
no notions of this sort in BGP, only in soBGP.

>It's not helpful to make your only requirement: "To secure BGP as 
>BGP is described in the BGP drafts." That leaves out two rather 
>large pieces of the puzzle--how BGP is implemented, and how BGP is 
>actually used. I don't think we should leave those concepts out of 
>the mix.
>

If BGP is implemented in a fashion that is not consistent with the 
RFCs, then the implementations are not conformant, and the IESG 
should not have approved BGP4 as a full standard.  So I'm sure you 
don't mean to imply that, do you Russ?

When you suggest that we have to accommodate how BGP is "actually" 
used, we may be heading down a slippery slope, where abuses of the 
protocol, that create security problems, are codified as features, 
making it impossible to adopt engineering solutions to counter 
attacks that take advantage of such features.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Dec 2004 09:47:26 -0500

At 4:36 PM -0500 12/28/04, Russ White wrote:
>>circumstances under which a speaker is to emit an Update, either as 
>>a side effect of processing a inbound Update or due to detection of 
>>loss of connectivity. That suggests that our requirements should 
>>try to capture this notion.
>>
>>If, as you suggest, we do not verify that an Update has traversed 
>>the path indicated by the path attribute (modulo aggregation) then 
>>BGP is susceptible to attacks that advertise bogus path.  What you 
>>seem to be arguing is that if a speaker advertises a path that is 
>>not currently being advertised by the preceding ASes list in the 
>>path, but one that could legitimately be advertised based on local 
>>policy configurations in those ASes, then that is OK.
>>
>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.

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.

>Yes, I am implying that if a speaker advertises a route that doesn't 
>exist, for policy reasons, it is "okay." For instance, a rather mild 
>example is as path prepend. This clearly creates a path that does 
>not exist within the update, and it is "okay." Another for 
>instance--placing a third party AS in the AS set when I advertise 
>updates to a peer, to block those routes from being readvertised 
>through BGP's loop detection mechanism. Again, there is a path that 
>doesn't exist in the update, and it's used on a periodic basis in 
>the real world.

When an AS adds itself into a path multiple times, that is not a 
violation of the simple rule I was trying to express, since the AS in 
question is one through which the Update did travel.  It does seem to 
violate your characterization of BGP looking to find "loop free" 
paths, as a literal interpretation of the multiple instances of the 
AS in the path makes it a loop!

I have more trouble with your second example. Just because people 
exploit this aspect of the BGP algorithm to achieve a goal, does not 
make it valid. after all, spammers also use the lack of security in 
BGP to steal unused address blocks for brief periods and that meets 
their "operational requirements" but I hope we don't plan to make 
this a requirement.

>Even the case of aggregation proves the point--the path in the 
>aggregated route does not exist, for at least some of the reachable 
>destinations within the aggregate. For instance, 10.1.0.0/16 may be 
>advertised with a path of {1, 2}, but in reality, the path to 
>10.1.1.0/24 is {1, 2, 3}. Thus, 10.1.1.0/24 is not reachable through 
>the path {1, 2}, and yet BGP lives with this, somehow. So, yet 
>another case in common use where the as path doesn't match the real 
>as path used to reach the destinations within the update.

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.

>>>pushing the focus onto a subsidiary point, while ignoring the 
>>>larger point.
>>
>Can you show me the point in the BGP drafts that describe this as 
>the only way a BGP update can be processed? When I examine the 
>definition of the AS Path, I find this:
>
>"AS_PATH is a well-known mandatory attribute that is composed of a 
>sequence of AS path segments. Each AS path segment is represented by 
>a triple <path segment type, path segment length, path segment 
>value>."
>
>autonomous systems through which this update has passed." Can you 
>find the language to support your assertion?

Look beyond the definition of the path attribute, to the definition 
of Update processing and route computation. That defines how Updates 
pass through ASes, and thus, transitively.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 29 Dec 2004 10:52:18 -0500 (Eastern Standard Time)

>> 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.
>
> 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.

> 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.

> 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.

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

---

From: Russ White <[email-masked]>
Date: Wed, 29 Dec 2004 10:58:56 -0500 (Eastern Standard Time)

>> -- The wording I've suggested will allow soBGP, S-BGP, IRV, and SPV to 
>> meet them, I think.
>

In other words, you believe that S-BGP doesn't prove the things I've 
suggested as requirements?

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.

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.

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.

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.

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

:-)

Russ