Subject: Re: [RPSEC] Considerations in Path Security for BGP

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Nov 2003 13:02:14 -0500

Russ,

One good goal for a memo like this is to help set realistic 
assumptions for what sort of security we might be able to achieve for 
BGP, without making dramatic changes to the underlying protocol. The 
Abstract section of your memo seems to suggest that as the primary 
goal for the I-D, but I was not entirely sure, as I read through the 
I-D. This is something that we have tried to do in the papers we have 
published on S-BGP. It is useful as it helps set realistic 
expectations and avoids confusion. Assuming that this is the primary 
goal for your I-D, here are some comments.

Section 1:

You assert that the best one can do is to verify "that the advertiser 
has at least one known path to the destination advertised." In S-BGP, 
we can verify that a router that that advertised a path is affiliated 
with the (2nd) AS indicated in the path, that each AS long the path 
was authorized by the preceding AS in the path to advertise the 
prefix in the UPDATE, and that the origin AS is authorized to 
advertise that prefix.  This seems like a lot stronger than what you 
describe here.

We agree that one cannot ensure that traffic will actually follow the 
advertised path, but this is true for ANY routing protocol.

You argue that the path cannot be verified to be consistent with 
policies of all the ASes along the route. This is true, but I'm not 
sure we should care too much about this. In general, the policies of 
an AS are locally imposed, and not disclosed to others. So, it may 
not be possible for anyone external to an AS to determine whether the 
AS is even following its own policies. Moreover, it is silly to 
assume that one AS can impose its policies on another AS, not under 
its administrative control. So, the bottom line is that an AS policy 
re routing is purely a local (intra-domain) matter and  in an effort 
to secure intra-domain routing it is not of much relevance.

This also relates to a comment at the end of Section 2: "Second, ASes 
can remove routes from the routing system in accordance with their 
own policy; such an action can, in some cases, prevent another AS 
from enforcing its own policy." Every As should understand that its 
ability to enforce its local policy is limited by the info it 
receives from other ASes. This seems like a more general observation, 
and it suggests security requirements, i.e., that the received info 
be verifiable in terms of its integrity and authenticity. Also, we 
can verify whether the assertions encoded in the data are verifiable 
from an authorization perspective, based on available data, but that 
data generally would not include the policy of the ASes along the 
path.

Finally, the I-D brings up here and later the topic of data that is 
discarded as an advertisement progresses through the Internet. This 
is true, but it is not an intrinsic limitation of BGP. For example, 
in S-BGP, we carry some data that is discarded (e.g., due to 
aggregation) to facilitate signature verification at later ASes. This 
does not modify the semantics of BGP, but rather represents a sort of 
housekeeping activity by S-BGP, to facilitate authorization checks. I 
don't consider that to be out of bounds re security measures we can 
employ with BGP, and thus I don't agree with all of the observations 
about the implications of discarded data relative to security 
capabilities for BGP.

Section 2:

The phrase "these techniques do not ensure various aspects of the 
information carried within routing protocols" is pretty vague ought 
to be replaced, when discussing the limitations of point-to-point 
integrity mechanisms such as the MD5 checksum.

You also state that "This document does not discuss the authorization 
to advertise a given destination, or prefix." I agree that the I-D 
does not address this but I am puzzled as to why this discussion is 
omitted. We feel that authorization is central to discussions of the 
security of BGP.

The I-D specifies three questions that are cast as the essential 
criteria re route validity. The first one is interesting, but maybe 
not essential, the second seems like a red herring. The third one, 
which is the authorization issue that this I-D largely ignores, seems 
most important.

The first question is interesting in that if the path does not exist, 
then clearly there is a problem with the advertisement. But, even if 
the path does exist, we don't know that traffic will follow that 
path, as you noted earlier. Also, in general it is very difficult to 
know if a specified path exists, given the realistic limitations on 
dissemination of information about AS connectivity. So I question 
whether this is a useful question to be asking.

The second questions strikes me as inappropriate. Only if I were 
aware of the policies of every AS along a path would I be able to 
determine if each AS had properly applied its local policy to the 
advertisement I have received. But, as noted earlier, this 
information is NOT generally available, so it seems very unlikely 
that an AS can know the answer to this question. Moreover, why do I 
care whether each AS has followed its own policy? What I really care 
about is whether the advertisement is authentic and authorized, 
because if the advertisement is not authentic or it is it 
unauthorized, then it is bad and should be ignored, to avoid 
misrouting. Based on our S-BGP work, which addresses the third 
question, I have to disagree with your assertion that authorization 
to advertise cannot be established.

Finally, at the end of section 2 you list three things that protocols 
like BGP were not intended to do. I agree with the assertions in this 
list, but how did you choose to name only these items? There are lots 
of things BGP does not do and so one needs to explain why one would 
choose any subset to enumerate here.

Section 2.1 seems to be an example to show why the first of the three 
assertions is true. OK, but, as noted above, you first need to 
justify why this needs to be demonstrated. Is the notion that this is 
a widely held, but inaccurate belief? 

Section 3 begins with a discussion of how info may be legitimately 
removed from an advertisement as it passes from one AS to another. 
The intro ends with an assertion that the removal of info in this 
fashion limits what an AS can verify re an advertisement. This is 
true, but it ignores the possibility that a security extension to a 
protocol like BGP could choose to carry some of the discarded 
information, when it is necessary to support path authorization. 
That's what we do in S-BGP. So, I have to disagree with the stated 
conclusion about the inherent limitations of security measures in 
this regard. So long as we don't change how the protocol operates, 
e.g., the effects of aggregation are preserved, I think its fair to 
carry the "discarded" info in support of security features.

The example that compromises section 3.1 ends with phrases like 
"safer" and "more secure." These terms are not defined any where in 
the I-D and seem irrelevant to the discussion. I'd delete the last 
sentence.

The example that comprises section 3.2 seems to be missing some 
details. There are no examples of any advertisements from D to B re 
the 10.1.2.0 space.  Absent such advertisements, B would not be able 
to create an authentic advertisement to 10.1.2.0/24 or /23, at least 
in S-BGP.

The last sentence of this section is very long, and confusing. It 
says: "Thus, lack of information cannot, in a routing system, be 
construed to mean lack of authorization to transit a given path, or 
provide reachability to a given destination, unless all possible 
routing information towards a given destination can be removed, and 
all possible points of origin for that information are under the 
administrative control of the owner of the route."

The "owner" of an address prefix does have control over the adjacent 
ASes that advertise it. At best the owner chooses which adjacent ASes 
he authorizes to advertise the prefix, but that is the extent of his 
control. After that, these Ases can choose to advertise the prefix, 
or not.  So, given that capability, does the final clause of the 
sentence become false and thus the premise of the sentence is false 
too? I can't tell.

Section 4, the summary, begins with a statement that seems to be a 
big jump from much of the rest of the analysis in the I-D. It says: 
"While it is tempting to set policy, or to infer policy, from the 
existence or non-existence of information within a routing system, it 
isn't possible to do so, since routing systems remove information on 
a regular basis. Further, it appears logical that policy could be set 
based on the path advertised in a path vector protocol, however, 
since routing information is regularly removed from the routing 
system, it isn't possible to do so."

I don't recall much discussion of setting or inferring policy in this 
I-D. I assume operators of an AS set local policy based on various 
inputs, including business arrangements with subscribers and peers, 
traffic engineering decisions, etc. None of this is primarily or 
exclusively a function of advertisements they receive from other 
ASes, and so the comments here seem out of place. Also, it is not 
clear why one should try to infer the policy of an AS from 
advertisements, so the second aspect of this assertion is also 
puzzling. Overall I don't know what to make of this sentence.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 5 Nov 2003 14:29:45 -0500 (Eastern Standard Time)

> One good goal for a memo like this is to help set realistic assumptions
> for what sort of security we might be able to achieve for BGP, without
> making dramatic changes to the underlying protocol. The Abstract section
> of your memo seems to suggest that as the primary goal for the I-D, but I
> was not entirely sure, as I read through the I-D. This is something that
> we have tried to do in the papers we have published on S-BGP. It is
> useful as it helps set realistic expectations and avoids confusion.
> Assuming that this is the primary goal for your I-D, here are some
> comments.
>
> Section 1:
>
> You assert that the best one can do is to verify "that the advertiser has
> at least one known path to the destination advertised." In S-BGP, we can
> verify that a router that that advertised a path is affiliated with the
> (2nd) AS indicated in the path, that each AS long the path was authorized
> by the preceding AS in the path to advertise the prefix in the UPDATE,
> and that the origin AS is authorized to advertise that prefix.  This
> seems like a lot stronger than what you describe here.

Actually, you can't. You are assuming that signed
advertisement==authorization, but you've not clarified _whose_
authorization. This is precisely the problem with policies in a distributed
system, in genera, somce you alude to later in your email. For instance, if
I have this small internetwork:

     AS5
      |
  +--AS3--+
AS1       AS4
  +--AS2--+

Suppose AS1 is advertising 10.1.1.0/24 to both AS3 and AS2. They intend
that AS5's traffic should pass through AS3, but that AS4's traffic should
only pass through AS2. How can they enforce this policy? Suppose they can,
in some way, force AS3 to only advertise the route to AS5, and not to AS4.
This appears to solve the problem.

Only that they also have to force AS3 to not advertise any possible
_supernet_ of the same route to AS4, or their policy simply won't be
enforced. You can't count on longest match enforcing policy when you can't
gaurentee that routes won't be filtered out of the table.

So, again, who's policy? AS1's policy, or AS3's policy? The way BGP
currently works, AS3's policy takes precedence over the originator's
policy. And, because of this, you _cannot_ garauntee what you assert above,
that you can prove authorization through advertisment. In this case, for
instance, AS1 has, in no way, authorized AS3 to transit traffic from AS4 to
AS1. But, because of the way BGP works, there is absolutely no way to
prevent AS3 from doing so. You can place packet filters on the border, but
that just drops your traffic.

> advertised path, but this is true for ANY routing protocol.

Agreed. This is another reason why attempting to "secure the path" doesn't
make any sense in a routing protocol.

> You argue that the path cannot be verified to be consistent with policies
> of all the ASes along the route. This is true, but I'm not sure we should
> care too much about this. In general, the policies of an AS are locally
> imposed, and not disclosed to others. So, it may not be possible for
> anyone external to an AS to determine whether the AS is even following
> its own policies. Moreover, it is silly to assume that one AS can impose
> its policies on another AS, not under its administrative control. So, the
> bottom line is that an AS policy re routing is purely a local
> (intra-domain) matter and in an effort to secure intra-domain routing it
> is not of much relevance.

But, in fact, AS' _do_ impose their policies on other AS'. They do so
today, through Local Preference, for instance, and even communities. Again,
the fundamental question is: Whose policies?

> discarded as an advertisement progresses through the Internet. This is
> true, but it is not an intrinsic limitation of BGP. For example, in
> S-BGP, we carry some data that is discarded (e.g., due to aggregation) to
> facilitate signature verification at later ASes. This does not modify the
> semantics of BGP, but rather represents a sort of housekeeping activity
> by S-BGP, to facilitate authorization checks. I don't consider that to be
> out of bounds re security measures we can employ with BGP, and thus I
> don't agree with all of the observations about the implications of
> discarded data relative to security capabilities for BGP.

The point of the section is that you can't secure removed data. In the
example above, you cannot secure AS1's policies, since AS1's routes have
been removed from the system by AS3's policy, for instance. The only thing
you could do is to provide a "do not route this direction" symantic, rather
than the "route this direction" that BGP currently provides, but I'm not
certain, as a routing person, that you want to do this.

> information carried within routing protocols" is pretty vague ought to be
> replaced, when discussing the limitations of point-to-point integrity
> mechanisms such as the MD5 checksum.

MD5 verifies the information carried between peering; it is, fundementally,
a peering mechanism. If you think of a routing protocol as a database (in
rough terms), then MD5 verifies the communications between the servers.
This prevents someone along the way from injecting bad data, etc, but it
does not prevent one of the legetimate servers from injecting bad data.

> You also state that "This document does not discuss the authorization to
> advertise a given destination, or prefix." I agree that the I-D does not
> address this but I am puzzled as to why this discussion is omitted. We
> feel that authorization is central to discussions of the security of BGP.

Because the point of the document is that you cannot, in any way, try to
enforce policy within a path, with the current semantics of BGP.
Authorization of origination are clearly handled by soBGP and S-BGP. The
problem we're trying to address is this: What, exactly, can you actually
secure? One thing we know you can't secure is the AS Path.

> The I-D specifies three questions that are cast as the essential criteria
> re route validity. The first one is interesting, but maybe not essential,
> the second seems like a red herring. The third one, which is the
> authorization issue that this I-D largely ignores, seems most important.

The first is the most important, in terms of a routing protocols security
system. The second is not a red herring, it is actually what most security
systems appear to be attempting to prove (authorization to advertise
something you've learned from a third party). The third, again, is not a
concern, since it is important, and it can be proven, in many ways.

> The second questions strikes me as inappropriate. Only if I were aware of
> the policies of every AS along a path would I be able to determine if
> each AS had properly applied its local policy to the advertisement I have
> received.

Exactly. And the point of many security systems currently proposed to
validate exactly those policies. They cannot be validated.

> list, but how did you choose to name only these items? There are lots of
> things BGP does not do and so one needs to explain why one would choose
> any subset to enumerate here.

Simply to point them out. There are, as you say, a lot of things BGP wasn't
designed to do, such as converge in a couple of milliseconds. But these
aren't really important to the discussion at hand. :-)

> assertions is true. OK, but, as noted above, you first need to justify
> why this needs to be demonstrated. Is the notion that this is a widely
> held, but inaccurate belief?

Based on at least some of the currently proposed security systems, it is an
assumption which is widely held.

> removed from an advertisement as it passes from one AS to another.  The
> intro ends with an assertion that the removal of info in this fashion
> limits what an AS can verify re an advertisement. This is true, but it
> ignores the possibility that a security extension to a protocol like BGP
> could choose to carry some of the discarded information, when it is
> necessary to support path authorization.

This is precisely the concept of "do not route this direction," or rather,
a "negative update." BGP has no such beast today.

> conclusion about the inherent limitations of security measures in this
> regard. So long as we don't change how the protocol operates, e.g., the
> effects of aggregation are preserved, I think its fair to carry the
> "discarded" info in support of security features.

Actually, you only carry this information in the case of aggregation, not
re-origination. So, the information is still dropped from the system.
Second, even if you do carry the information in the aggregate, you don't
know which specific prefixes that information applied to. This is akin to
forcing AS3, in the example above, not to advertise a supernet of
10.1.1.0/24 to AS4.

> The example that compromises section 3.1 ends with phrases like "safer"
> and "more secure." These terms are not defined any where in the I-D and
> seem irrelevant to the discussion. I'd delete the last sentence.

I'll take a look.

> The example that comprises section 3.2 seems to be missing some details.
> There are no examples of any advertisements from D to B re the 10.1.2.0
> space.  Absent such advertisements, B would not be able to create an
> authentic advertisement to 10.1.2.0/24 or /23, at least in S-BGP.

I suppose it's an assumption in the draft which needs to be clarified. D
is, in fact, advertising the shorter prefix to B and C, and the longer
prefix just to C.

> The last sentence of this section is very long, and confusing. It says:
> "Thus, lack of information cannot, in a routing system, be construed to
> mean lack of authorization to transit a given path, or provide
> reachability to a given destination, unless all possible routing
> information towards a given destination can be removed, and all possible
> points of origin for that information are under the administrative
> control of the owner of the route."
>
> The "owner" of an address prefix does have control over the adjacent ASes
> that advertise it. At best the owner chooses which adjacent ASes he
> authorizes to advertise the prefix, but that is the extent of his
> control. After that, these Ases can choose to advertise the prefix, or
> not.  So, given that capability, does the final clause of the sentence
> become false and thus the premise of the sentence is false too? I can't
> tell.

Exactly. So, you would agree that you cannot prove authorization to
advertise in a routing system such as BGP?

:-)

Russ

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

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Nov 2003 15:14:08 -0500

Russ,

>I have this small internetwork:

we seem to be speaking different languages. From my perspective, 
authorization in BGP relates to the right to advertise a prefix, and 
is granted by an AS when is sends an UPDATE to a neighbor containing 
the prefix.

>only pass through AS2. How can they enforce this policy?

they can't and they ought not expect to be able to enforce that 
policy! As I noted in my comments, there is no presumed ability of 
ASa to control to whom  ABb advertises a route once ASa has 
authorized ASb to advertise it. There is no  transitive control over 
advertisement, something we both agree upon, I think.

>that just drops your traffic.

As I see it we agree on the limitations inherent in this sort of 
routing, and we are just having trouble agreeing on the right terms.

>make any sense in a routing protocol.

we disagree, strongly! while it is true that we cannot ensure that 
traffic we hand off to another As will traverse the advertised path, 
in most cases we have no choice, i.e., it's the best (or only) game 
in town based on the externally available knowledge. thus is it 
reasonable to ensure that at least the info we use to make the 
decision is accurate in so far as the externally available info 
permits.

>the fundamental question is: Whose policies?

Your examples show the opposite. Each AS can decide what to advertise 
to its neighbors, but it cannot force another AS to carry traffic via 
these advertisements. It can only hope to influence their decisions, 
and that influence is limited.

>certain, as a routing person, that you want to do this.

again, we seem to be talking at cross purposes.  I get the feeling 
that you are trying to establishing a strawman re what an AS might 
try to do and why it cannot be successful. I never see an ability for 
one AS to control what other AS does, so I see no surprises in your 
examples. If you feel that there are folks who are confused about 
this issue, then it is appropriate to state it clearly, once, and 
explain why they are confused. But there is no need to generate a lot 
of text belaboring the point.

>does not prevent one of the legetimate servers from injecting bad data.

yes, I agree. I was pointing out that the words you chose were vague 
and did not convey clearly what the MD5 mechanism does.  in 
conventional communication security terms, this mechanism provides 
point-to-point integrity at the transport layer, and data origin 
authentication, assuming that the keys used are  pairwise unique. 
that is a concise, technically accurate characterization of the 
mechanism.

>secure? One thing we know you can't secure is the AS Path.

I don't know what that phrase "secure the AS path" is supposed to 
mean. One can allow an AS to verify whether the advertised path is 
authorized, and I have explained why I think that is exactly what an 
AS should try to verify, i.e., it is the underlying semantic of BGP. 
However, you are correct that this security capability will not allow 
one As to project its policy onto other ASes, or ensure that 
subscriber traffic will, in fact, follow the path.

>concern, since it is important, and it can be proven, in many ways.

Well, I guess we just don't read the words the same way.

>validate exactly those policies. They cannot be validated.

what systems are you talking about? Certainly not S-BGP, and 
presumably not soBGP, so to what, precisely do you refer here?

>aren't really important to the discussion at hand. :-)

one needs to justify the choices of what to argue BGP does not do, 
else the choices seem arbitrary. why not note that BGP fails to make 
underwear brighter?

>assumption which is widely held.

Again, you might to be more specific, and say what systems you have 
in mind, to justify the discussion. We know it's no S-BGP and 
presumably no soBGP ...

>a "negative update." BGP has no such beast today.

as noted above, several times, you can't force another AS to do or 
not do something re route propagation. What you can do, e.g., with a 
system like S-BGP, is to allow other ASes to determine whether or not 
the advertisements they receive are authorized by all of the ASes 
along the path, where authorized is the very simple statement I have 
made several times already.

>forcing AS3, in the example above, not to advertise a supernet of

I have to admit that I don't now what re-origination is, so I'll get 
back to you on that topic.  But, with regard to the second half of 
your comment, we all agree that once cannot force another AS to NOT 
advertise or to NOT advertise something, so I don't see the point.

>advertise in a routing system such as BGP?

What I agree is that you need to work on your exposition, to make a 
sentence like the one quoted above comprehensible.  then we can 
figure out what may be wrong (or right) with it.

:-)

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 5 Nov 2003 15:31:37 -0500 (Eastern Standard Time)

> >authorization. This is precisely the problem with policies in a
> >distributed system, in genera, somce you alude to later in your email.
> >For instance, if I have this small internetwork:
>
> authorization in BGP relates to the right to advertise a prefix, and is
> granted by an AS when is sends an UPDATE to a neighbor containing the
> prefix.
>
> >      AS5
> >       |
> >   +--AS3--+
> >AS1       AS4
> >   +--AS2--+
> >
> they can't and they ought not expect to be able to enforce that policy!
> As I noted in my comments, there is no presumed ability of ASa to control
> to whom ABb advertises a route once ASa has authorized ASb to advertise
> it. There is no transitive control over advertisement, something we both
> agree upon, I think.

Yes, but if you enlarge this to the next step, you'll understand the point
of the draft itself.

-- AS1 cannot force AS2 to advertise something it has authorized AS2 to
   advertise.
-- AS1 cannot force AS3 not to advertise something which overlaps that
   which it has _not_ authorized AS3 to advertise.

In other words, AS1 can refuse to authorize AS3 the ability to advertise
10.1.1.0/24. But, it could so happen that AS3 has the authorization to
advertise 10.1.0.0/16 through some other source, reorigination, perhaps, or
learning it from any other peer. In this case, AS3 will advertise
10.1.0.0/16, which, in fact, overlaps and encompasses 10.1.1.0/24, which
AS1 expressly does _not_ want AS3 to advertise.

Thus, AS1 has no say in whether or not AS3 will advertise 10.1.1.0/24, in
fact. You could argue that AS1 can create a "hole" in the 10.1.0.0/16
address space AS3 is advertising (legitimately) by advertising the longer
prefix through another path, but that advertisement may be removed at any
point, so that argument doesn't work, either.

You can prove a valid path exists, but to prove "authorization," you're
going to have to define it more closely than it's currently defined.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Nov 2003 16:03:35 -0500

advertise.
>    which it has _not_ authorized AS3 to advertise.

we seem to be coming back to a wording problem. I don't hear anyone 
other than you saying that any AS can force any other AS to advertise 
or not advertise anything. certainly S-BGP does not use these terms. 
Rather, we talk in terms of what an AS can verify re the 
advertisements it receives.

>AS1 expressly does _not_ want AS3 to advertise.

In your example, if AS3 is authorized by some other source to 
advertise 10.1.1.0/24, then that's OK. For example, if a subscriber 
is multi-homed to AS1 and AS3, then the subscriber should be able to 
authorized both of them to advertise the prefix. There is no conflict 
there.

>going to have to define it more closely than it's currently defined.

S-BGP needs to be more precise about how an AS receiving an 
advertisement determines the authorization of another AS to advertise 
a prefix of a specific length. My initial model didn't take into 
account the significance of longer prefixes in route selection, and 
so our model was too simplistic. Randy Bush and Steve Bellovin 
pointed out the problem when we did a demo of S-BGP last fall. I 
believe we have a fix for this, but I don't recall if the latest 
S-BGP I-D describes the algorithm for determining authorization 
relative to prefix length.

I am open to constructive suggestions on how to improve the 
definition so that it is as good a characterization of the BGP 
semantics as possible, and hopefully, still concise and 
understandable. We all need to agree on these terms to make progress 
in discussing the issues, as well as in discussing the merits of 
proposed solutions.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 5 Nov 2003 16:33:28 -0500 (Eastern Standard Time)

> we seem to be coming back to a wording problem. I don't hear anyone other
> than you saying that any AS can force any other AS to advertise or not
> advertise anything. certainly S-BGP does not use these terms.  Rather, we
> talk in terms of what an AS can verify re the advertisements it receives.

Could you please define what you mean by "authorization?" In my mind,
when I say that I authorize you to advertise my prefixes to your peers,
then I'm saying that I authorize you to transit traffic from those peers to
me. If I refuse to authorize you to advertise my prefixes to your peers,
then my intent is that you will not be able to advertise my address space,
and thus your peers will not know how to reach my address space through
you.

Is this correct?

If so, then what I'm saying is that you cannot enforce this sort of
authorization in BGP, because you can't force another AS not to advertise a
shorter prefix containing the prefix you're originating. It's not the same
prefix through another path, it's a completely different prefix.

AS1 is saying to AS3: "Do _not_ advertise 10.1.1.0/24."
AS3 is complying with that policy, as far as it can.
AS3 is, however, advertising 10.1.0.0/16, which happens to _contain_
10.1.1.0/24.

Thus, there is no way for AS3 not to advertise the address space AS1 is
telling it not to advertise. AS1's lack of authorization to AS3 (which is
an expression of policy) is null and void.

If you would state that authorization means the ability to prove that a
path exists, and expresses nothing about the policies along that path (for
instance, AS1's policy is that it won't receive traffic through AS3, but
that policy has been overridden, and is thus null and void), then I would
agree that you can "authorize" a path. But, then, authorizing a path only
means proving the path exists, not that it is "valid" in some policy
related way.

You can validate the origination, and you can prove a path exists, but
"authorization to advertise a prefix received from a peer" simply cannot be
proven in BGP. "Authorization" is an expression of policy, and falls within
the bounds of not being able validate policies within BGP, simply because
of the structure of the routing system.

That's the point of the draft.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Nov 2003 17:15:51 -0500

<SNIP>
>and thus your peers will not know how to reach my address space through

yes, this is essentially correct. I tend to use terms that are more 
directly linked to the mechanics of the advertisement, rather than 
the implications of the advertisement, but either approach is 
reasonable.

>prefix through another path, it's a completely different prefix.

OK, we finally have a clear statement of what I assume is the 
residual issue, i.e., advertisements of a longer prefix by an AS, 
relative to the prefix that the AS received in an advertisement. is 
that right?

>AS1 is saying to AS3: "Do _not_ advertise 10.1.1.0/24."

I don't agree with this characterization. AS1 can advertise to AS3 
and use the community attribute NO_EXPORT to expressly indicate that 
AS3 is NOT authorized to propagate that advertisement, but you did 
not mention use of that attribute in your example. (BTW, S-BGP can 
cover this attribute with the signature applied to UPDATE data, and 
thus support the enforcement of this control.) But, that's not really 
the crux of the problem.

>AS3 is, however, advertising 10.1.0.0/16, which happens to _contain_

I don't completely agree with the words you are using here. AS3 is 
legitimately advertising the address space it has been allocated. 
Yes, that address space subsumes the AS1 address space, because AS3 
delegated that space to AS1. The need is for other ASes to be able to 
determine that the AS1 delegation has occurred. The problem is the 
inability of BGP to ensure propagation of the AS1 advertisement.

The tricky part is that if ASa sees the AS3 advertisement and not the 
AS1 advertisement, and if ASa has no other source of information to 
alert it to the AS1 delegation, then ASa has no way of knowing that 
AS1 has not authorized AS3 to advertise the longer prefix that AS1 
now controls. As I mentioned earlier, one ought not talk in terms of 
an AS projecting its policy onto other ASes, because that is not a 
concept generally offered by BGP (except in the limited case of the 
community attribute) and because it is generally unenforceable.

Your example is, I fear, not a good one, for the point you are trying 
to make. Let me suggest a refinement of your original example.

First, AS5 has only one path in your example, which makes it a poor 
choice to run BGP. Also, since that path is through AS3, it is 
obvious that AS5 is at the mercy of AS3, i.e., AS5 will never learn 
anything about the rest of the Internet except what AS3 tells it. In 
a situation of this sort, since AS5 really has only path to the rest 
of the Internet, it's pretty clear that we can't do much to help it 
in many practical respects.

But, we could revise your example and still use it to examine the 
issue you are trying to explore. Just add a path from AS5 to a new AS 
(AS6), and from AS6 to AS4, resulting in the following diagram:

      AS5--AS6-+
       |       |
   +--AS3--+   |
AS1       AS4-+
   +--AS2--+

Now, I'll set the stage, filling in some details that were not made 
explicit in your initial description of the example, and add some of 
my own details that I think make this a better example:

AS1 is a subscriber originating 10.1.1.0/24, a sub-allocation from AS3
AS3 is an ISP, originating 10.1.0.0/16
AS2 is an ISP to which AS1 is also attached
assume AS4, 5 and 6 are ISPs, wlog

What is AS1 trying to do? You were not completely clear on the goal 
of AS1. If AS1 has totally unrealistic expectations then it is 
hopeless. Let's say that AS1's goal is to not have any traffic 
destined to its /24 address block transit AS3.

So AS1 ought to advertise to AS3 using the community attribute 
NO_EXPORT, which is an explicit of saying that the advertisement is 
meant only for local consumption. I assume that AS1 does want traffic 
from AS3 subscribers to flow over this link. Otherwise, if AS1 wants 
NO traffic to ever enter it via AS3, why have the link to AS3? if the 
link is for backup, then we need to talk about the validity period 
for an authorization, but let's not address that for now.

Now AS1 can advertise 10.1.1.0/24 to AS2 in hopes that traffic from 
the rest of the Internet will flow to this prefix via AS2, the only 
other connection that AS1 has to the rest of the Internet. This will 
work IF the rest of the Internet sees the advertisement from AS1. But 
there is no guarantee that this will happen, e.g., if AS2's local 
policy causes it to not propagate the AS1 advertisement, then AS1's 
goal is thwarted. But, if AS2 didn't propagate the AS1 advertisement 
there would be a serious misunderstanding between these two peers, so 
let's assume that AS2 does not suppress the AS1 advertisement, i.e., 
AS2 does propagate the AS1 advertisement to AS4.

AS3 is legitimately advertising its prefix, 10.1.0.0/16 to AS4 and 
AS5. AS4, having received both the /16 and /24 advertisements would 
choose the /24 for the AS1 traffic, as intended, if AS4 is operating 
properly. So far so good. Note that AS4 might well send the AS1 
advertisement it received from AS2, to AS3. If AS3 passes this 
advertisement on to AS5, then AS5 might send AS1 traffic to AS3, 
legitimately. So, AS1 really should understand that it cannot prevent 
some traffic destined to it's /24 from traversing AS3, because AS3 
might legitimately be on a path to AS1 from some other ASes! This 
again raises the question of what AS1 thinks it will accomplish by 
not explicitly authorizing AS3 to advertise the /24.

But, to focus on what I think was the point of your example, let's 
assume that  AS4 does not pass on the AS1 advertisement to AS3, due 
to some local policy rule in AS4.  Also, the folks at AS6, for some 
local policy reason, fail to propagate the AS1 advertisement they 
receive from AS4. That means that AS5 will see only the AS3 
advertisement for 10.1.0.0/16, and not the 10.1.1.0/24 advertisement 
originated by AS1.

Now AS5 will send traffic for AS1 to AS3, even though that was 
exactly what AS1 did not want to happen, and even though AS1 did its 
best to prevent this traffic flow by NOT authorizing AS3 to advertise 
the longer prefix. This, I believe was your point.

Let's try to make a more general statement of the problem. When there 
are two prefixes P and P', with P' a subset of P, then if an AS does 
not see advertisements for P' (e.g., because of local policies in 
ASes that lie on paths between the origin for P' and these other 
ASes), but does see an advertisement for P, it will accept the 
advertisement for P, all else being equal.  ASes that do not see an 
advertisement for P' will naturally route traffic for P' via paths 
for P, because P subsumes P'.

In this case, I would say that the advertisement for P is authorized, 
but the lack of pervasive knowledge of the existence of a distinct 
advertisement for P' means that the subsuming advertisement is 
misleading for those folks who fail to learn about the path for P'.

Now this problem arises because of the inability of AS1 to ensure 
that its longer prefix will be seen by all other ASes. Yes, I agree 
that this is a limitation intrinsic in BGP. A fair question to ask is 
what can be done to ameliorate this problem. One can also ask how 
serious is the problem? After all, AS1 encountered the problem 
because it had a prefix that was allocated by AS3, and then it 
decided that it didn't want to have AS3 be a transit AS for its 
traffic. Althought it might be a painful exercise, AS1 could renumber 
using a newly assigned prefix, e.g., acquired from an RIR, and avoid 
the problem.

More significantly, as noted above, there is generally no way for ANY 
AS to ensure that traffic for a prefix originated by it will NOT 
traverse another AS, at least from some sources. This is true even if 
the prefix originated by the AS in question is directly allocated by 
an RIR. it would seem that the best we can do is to limit the number 
of ASes that can create advertisements for the prefix in question, to 
minimize the opportunities for misrouting.

In S-BGP, we provide some mechanisms that are relevant to this 
problem. First we allow attributes other than the path attribute to 
be included in the signed data. So, for example, the community 
attribute can be protected and, as noted above, that would prevent 
AS3 from using an advertisement by AS1 to AS3 from being further 
propagated.  (If AS3 forwarded the advertisement with the NO-EXPORT 
flag, other ASes would reject it, and if AS3 stripped the attribute, 
other ASes would detect the tampering.)

S-BGP uses repositories to distribute certs, AAs, and CRLs. The AA 
and cert databases would indicate that AS1 is the owner of the longer 
prefix (10.1.1.0/24), and would contain an AA issued under that cert 
to AS1, because AS1 would post that information. So any AS that 
participated in S-BGP would learn of the existence of the /24 prefix 
and would know that AS1, not AS3, was the origin for this prefix.

If AS1 did not authorize AS3 to advertise the /24, then AS3's 
advertisement of the /16 would not cause other ASes to send the /24 
traffic to AS3, since they would know that the /16 was not an 
authorization for the /24 that it subsumes. That does not ensure that 
other ASes will ever learn of ANY route to AS1 for its /24 prefix, 
because we cannot guarantee that routes are propagated everywhere. 
Thus ASes might be left knowing that the advertisement they have for 
the /16 is NOT authorized for the /24 traffic, but they still might 
not know what to do with that /24 traffic. But at least we have a 
means of preventing AS3 from advertising the AS1 address space if AS1 
does not want AS3 to do so. Also, S-BGP says that an AS may not use 
its authorization to advertise a prefix P to advertise a prefix P' of 
greater length, subsumed by P.

Sorry for the length of this message, but it seemed necessary to 
fully describe the example and to explore in detail the issues you 
raised about what it means to be authorized to advertise a path, and 
what are the realistic expectations that an AS can have re the 
implications of authorized advertisements.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 6 Nov 2003 19:33:17 -0500 (Eastern Standard Time)

> > Rather, we talk in terms of what an AS can verify re the advertisements
> > it receives.
> >
> >then I'm saying that I authorize you to transit traffic from those peers
> >to me. If I refuse to authorize you to advertise my prefixes to your
> >peers, then my intent is that you will not be able to advertise my
> >address space, and thus your peers will not know how to reach my address
> >space through you.
> >
> >Is this correct?
>
> directly linked to the mechanics of the advertisement, rather than the
> implications of the advertisement, but either approach is reasonable.
>
> >authorization in BGP, because you can't force another AS not to
> >advertise a shorter prefix containing the prefix you're originating.
> >It's not the same prefix through another path, it's a completely
> >different prefix.
>
> OK, we finally have a clear statement of what I assume is the residual
> issue, i.e., advertisements of a longer prefix by an AS, relative to the
> prefix that the AS received in an advertisement. is that right?

No, a shorter prefix, not a longer one.

> I don't agree with this characterization. AS1 can advertise to AS3 and
> use the community attribute NO_EXPORT to expressly indicate that AS3 is
> NOT authorized to propagate that advertisement, but you did not mention
> use of that attribute in your example. (BTW, S-BGP can cover this
> attribute with the signature applied to UPDATE data, and thus support the
> enforcement of this control.) But, that's not really the crux of the
> problem.

I'm not arguing S-BGP here, or any other specific mechanism. I'm discussing
what is possible within the routing system, not what is possible to encode
in the advertisements. It doesn't matter how you encode, at AS1, that AS3
should not advertise AS1's address space. AS1 cannot enforce this policy,
because AS3 can, through other means, simply advertise a shorter prefix, an
aggregate, or a reorigination.

It's not the same thing at all. Since AS1's address space happens to be
contained within the address space AS3 is advertising, there is no way to
actually encode this policy--"don't use this path"--in any meaningful way
within BGP, or any other routing system, actually.

> legitimately advertising the address space it has been allocated.  Yes,
> that address space subsumes the AS1 address space, because AS3 delegated
> that space to AS1. The need is for other ASes to be able to determine
> that the AS1 delegation has occurred. The problem is the inability of BGP
> to ensure propagation of the AS1 advertisement.

Or perhaps AS3 is picking up the aggregate from someplace else, it doesn't
matter how or why AS3 ias actually advertising the aggregate. 10.1.0.0/16
contains 10.1.1.0/24, in IP terms. If you're "authorized" to advertise a
route to 10.1.0.0/16, then you're stating you're "authorized" to route
every possible subnet of the /16, including one that you've been
specifically told, through any means you might choose, _not_ to route for.

There's no way, in BGP, or any other routing protocol, to provide a
"negative update."

> The tricky part is that if ASa sees the AS3 advertisement and not the AS1
> advertisement, and if ASa has no other source of information to alert it
> to the AS1 delegation, then ASa has no way of knowing that AS1 has not
> authorized AS3 to advertise the longer prefix that AS1 now controls. As I
> mentioned earlier, one ought not talk in terms of an AS projecting its
> policy onto other ASes, because that is not a concept generally offered
> by BGP (except in the limited case of the community attribute) and
> because it is generally unenforceable.

In reality, the last AS that handles the prefix _always_ projects it's
policy on every AS before it in the AS Path. This is true because the last
AS in the path can simply filter it. Again, it comes down to: "whose
policy?"

> Your example is, I fear, not a good one, for the point you are trying to
> make. Let me suggest a refinement of your original example.
>

> ....

> But, to focus on what I think was the point of your example, let's assume
> that AS4 does not pass on the AS1 advertisement to AS3, due to some local
> policy rule in AS4.  Also, the folks at AS6, for some local policy
> reason, fail to propagate the AS1 advertisement they receive from AS4.
> That means that AS5 will see only the AS3 advertisement for 10.1.0.0/16,
> and not the 10.1.1.0/24 advertisement originated by AS1.
>
> Now AS5 will send traffic for AS1 to AS3, even though that was exactly
> what AS1 did not want to happen, and even though AS1 did its best to
> prevent this traffic flow by NOT authorizing AS3 to advertise the longer
> prefix. This, I believe was your point.
>
> Let's try to make a more general statement of the problem. When there are
> two prefixes P and P', with P' a subset of P, then if an AS does not see
> advertisements for P' (e.g., because of local policies in ASes that lie
> on paths between the origin for P' and these other ASes), but does see an
> advertisement for P, it will accept the advertisement for P, all else
> being equal.  ASes that do not see an advertisement for P' will naturally
> route traffic for P' via paths for P, because P subsumes P'.
>
> In this case, I would say that the advertisement for P is authorized, but
> the lack of pervasive knowledge of the existence of a distinct
> advertisement for P' means that the subsuming advertisement is misleading
> for those folks who fail to learn about the path for P'.

Thus, the path in the "authorized" advertisement can say nothing about the
policies of the AS' along the path, including their willingness to accept
traffic along the path. Which means that a path cannot be "authorized" in
the way it's defined in the beginning of this email. It can only be proven
to exist, or not to exist.

> Now this problem arises because of the inability of AS1 to ensure that
> its longer prefix will be seen by all other ASes. Yes, I agree that this
> is a limitation intrinsic in BGP. A fair question to ask is what can be
> done to ameliorate this problem. One can also ask how serious is the
> problem? After all, AS1 encountered the problem because it had a prefix
> that was allocated by AS3, and then it decided that it didn't want to
> have AS3 be a transit AS for its traffic. Althought it might be a painful
> exercise, AS1 could renumber using a newly assigned prefix, e.g.,
> acquired from an RIR, and avoid the problem.
>
> More significantly, as noted above, there is generally no way for ANY AS
> to ensure that traffic for a prefix originated by it will NOT traverse
> another AS, at least from some sources. This is true even if the prefix
> originated by the AS in question is directly allocated by an RIR. it
> would seem that the best we can do is to limit the number of ASes that
> can create advertisements for the prefix in question, to minimize the
> opportunities for misrouting.

Exactly. Then you cannot "secure" a path in the sense that an advertiser is
_gauranteed_ to be "authorized" to transit traffic for the address blocks
in the advertisement.

The rest of this concerns S-BGP, which I'm not trying to discuss here, so
I've snipped it out. If the above is true, it doesn't matter how many
signatures, databases, and other security measures you wrap around BGP, the
information isn't in BGP to secure. So, there's no way, with the current
routing system, to "gaurantee" that an "authorized" advertisement also
implies "authorization to transit," or imply any sort of other policy from
that advertisement.

You could always attempt to _add_ this information, but aggregration,
reorigination, and other systems of this type are the key to scalable
routing. You either have a choice of elimintating aggregation and
filtering, or simply not attempting to claim "authorization" within a
routing system in this way.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Nov 2003 14:52:31 -0500

>No, a shorter prefix, not a longer one.

OK, from your perspective its the advertisement of the shorter prefix 
that is the problem, and from my perspective it is the 
non-advertisement of the longer one that's the problem. Half-full vs 
half-empty?

>aggregate, or a reorigination.

we agree on the inability of ANY AS to impose its policy on another 
AS. I've said that several times, so I am at a loss to understand why 
you keep raising this as an issue. It makes no sense to speak in 
terms of ASx enforcing its policy outside the context of ASx! It is 
not a limitation of this example of of path authorization, it is 
intrinsic in the nature of BGP.

>within BGP, or any other routing system, actually.

Ido not understand why you keep saying that AS1 is trying to prevent 
traffic for its /24 from traversing AS3. We know AS1 cannot cause 
this to happen; I gave an example showing why such traffic might 
legitimately traverse AS3 even if every other AS is aware of the 
advertisement from AS1. Your statement re the inability to express 
"don't use this path" is certainly true here, but its not relevant to 
the discussion.

>There's no way, in BGP, or any other routing protocol, to provide a

Russ, you keep creating phrases, e.g., "negative update" to support 
some notion, but you are not communicating this notion effectively.

>	>SNIP>

Nonsense. An AS choose what info to pass to its peers. But, it cannot 
control what info these peers receive via connections to other ASes, 
in general. And it certainly cannot control HOW the other ASes use 
the info that is provided. So it just seems silly to think than an AS 
projects its policy on its peers. After all, AS stands for AUTONOMOUS 
system. That should be a hint :-)

>	<BIG SNIP>

You seem to be redefining the term "authorized" so as to use it as a 
strawman. Please stop doing that; it's not constructive.

>_gauranteed_ to be "authorized" to transit traffic for the address blocks

You've moved from "authorized path" to "secure a path," another term 
you have defined to serve your purposes. The pile of strawmen you are 
trying to create is way too high at this point :-)

>routing system in this way.

Aggregation is not a problem; one can preserve the authorization info 
from the advertisements that an AS receives and that transitively 
authorize it to send an aggregated advertisement. That is consistent 
with the authorization model we have developed.

I looked for the term "reorigination" and didn't find it in any BGP 
spec. I've been told that this term refers to a practice in which an 
AS asserts itself as an origin for a prefix, when in fact if is not. 
Where I come from this is called "lying" :-)  Nonetheless, we already 
make use of a mechanism that allows the owner of a prefix to 
authorize an AS to advertise itself as an origin AS. The normal use 
of this is to authorize an AS to which one is attached to advertise 
in this fashion, but if reorigination really is a requirement I 
suspect it can be supported as well, using this mechanism; it would 
just be an example of delegation of authorization to advertise in a 
different context.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 7 Nov 2003 15:53:20 -0500 (Eastern Standard Time)

> I do not understand why you keep saying that AS1 is trying to prevent

--

--

So, if this is still a correct definition of authorization:

-- AS Paths cannot contain authorization in any sense
-- Receipt of an update cannot prove authorization
-- Lack of an update cannot prove lack of authorization

You can prove an AS Path is valid, in the sense that it exists, but you
cannot, in any sense, claim any sort of "authorization" to do anything
expressed through the receipt or lack of receipt of an advertisement.

> control what info these peers receive via connections to other ASes, in
> general. And it certainly cannot control HOW the other ASes use the info
> that is provided. So it just seems silly to think than an AS projects its
> policy on its peers. After all, AS stands for AUTONOMOUS system. That
> should be a hint :-)

Okay, so you're saying that when I set my MED, I'm not expressing a policy,
and when you set your Local Pref, you're not overriding my policy? You may
choose to advertise a /25 to me, and I choose to block it inbound at my
border. How, exactly, is that not imposing my policy on you?

> >Thus, the path in the "authorized" advertisement can say nothing about
> >the policies of the AS' along the path, including their willingness to
> >accept traffic along the path. Which means that a path cannot be
> >"authorized" in the way it's defined in the beginning of this email. It
> >can only be proven to exist, or not to exist.
>

No, I'm using it as it's defined above--the definition you agreed is
correct.

> authorize it to send an aggregated advertisement. That is consistent with
> the authorization model we have developed.

So, what do you mean by "authorization" in the above sentence, in reference
to an AS Path or an update? You state you are authorizing a peer to
readvertise an update, but what, exactly, do you intend to imply with this
authorization? According to the definition above, the authorization to
transit traffic through the path.

> I looked for the term "reorigination" and didn't find it in any BGP spec.
> I've been told that this term refers to a practice in which an AS asserts
> itself as an origin for a prefix, when in fact if is not.  Where I come
> from this is called "lying" :-)

Then ISP's must commonly lie. :-) Re-origination means: I own 10.1.0.0/16,
and I hand off to you 10.1.1.0/24. At my border, I simply block your
advertisement of 10.1.1.0/24, and instead, originate 10.1.0.0/16. Thus, I'm
"re-originating" your address space, within a larger address space. The
difference, in Cisco IOS terms, is this:

router bgp xxx
 aggregate-address 10.1.0.0 255.255.0.0 summary-only

and

ip route 10.1.0.0 255.255.0.0 null
!
router bgp xxx
 network 10.1.0.0 mask 255.255.0.0

Others may call it something else, but it's a fairly common practice, and
it wipes out all the prior AS Path information. It's also perfectly legal,
etc.

:-)

Russ

---

From: Nick Feamster <[email-masked]>
Date: Fri, 7 Nov 2003 19:04:55 -0500

Hi Steve,

> advertised path, but this is true for ANY routing protocol.

I think the larger point is that BGP can have inconsistencies (say,
introduced by IGP and iBGP, inconsistencies within an AS, etc.) that
cause an AS to "say one thing and do another", depending on which router
in that AS you're considering.

> AS is even following its own policies. 

> Moreover, it is silly to 

The point is not that one AS cannot impose policies on another.  The
point is that an AS cannot ensure that its own policies are satisfied,
because other ASes may do things that counteract that AS's policies
(e.g., the aggregation example we present).

> about the implications of discarded data relative to security 

Discarded data can throw away policy information.  If you agree that a
"valid route" involves conformance to policy, then what we say is true.

> omitted.  We feel that authorization is central to discussions of the 

Yes, authorization is a necessary *but not sufficient* condition to
ensure that the routing protocol advertises valid paths.  There are
other aspects that must be considered, and that's what we're talking
about in this draft.

> which is the authorization issue that this I-D largely ignores, seems 

The second question is important (and appropriate) because a route
should not be used (i.e., considered valid) if using it would violate
the wishes of some AS along that path.  

> whether this is a useful question to be asking.

Our inability to answer this question with today's protocols does not
make it a useless question.

> What I really care 
> misrouting. 

Yes, we care about authorization, but policy conformance is also
important, for the reasons mentioned above.  To reiterate, authorization
is necessary, but not sufficient.

> a widely held, but inaccurate belief? 

You seem to be saying that making sure that everyone who advertises a
path is authorized to do so is all we have to do to get valid paths, but
the example in 2.1 demonstrates why, in BGP, simply performing
authorization checks is not enough.  

Cheers,
Nick

---

From: Stephen Kent <[email-masked]>
Date: Sun, 9 Nov 2003 17:21:33 -0500

>in that AS you're considering.

i don't see any disagreement here.  Surely we all know that a routing 
system provides inputs for traffic forwarding, but those inputs do no 
really guarantee that forwarding tasks place as advertised. For 
example, an ISP may place its own AS # in a path multiple times in an 
effort to influence other AS to not use this route unless its the 
only one around. However, if traffic does flow to the As for the 
prefix associated with the route, nobody expects the ISP to cause the 
traffic to loop through it! Thus there are lots of ways traffic 
forwarding may differ from route advertisements. A major goal for 
secure routing is to allow an AS to detect bogus (not authorized) 
routes, so that the AS can at least avoid making forwarding decisions 
based on bad data.

>(e.g., the aggregation example we present).

I see no difference between what I said and what you said, in any 
practical sense.

>"valid route" involves conformance to policy, then what we say is true.

BGP discards data when aggregation is performed, but a security 
system need not discard that data. That's what we chose to do in 
S-BGP; we carry data that BGP discards (and that we need for 
authorization checking) in our optional attribute. Who says you can't 
do this? The fact that BGP discarded the data does not imply that a 
security enhancement to BGP must do so as well.

>other aspects that must be considered, and that's what we're talking

I didn't see a clear articulation of what those other aspects were. 
Moreover, the theme of the I-D seemed to be that "authorization" was 
irrelevant, or at best a secondary concern. Of course we disagree 
about what authorization  means in this context, so it's not 
surprising that we should disagree about its significance.

>the wishes of some AS along that path.

This seems like wishful thinking, at best. This is precisely the 
notion that any AS can impose its "wishes" on other ASes, which is 
what you and I disagreed about above.

>make it a useless question.

We ought to be consistent about what is fair game. Above you seem, to 
argue that if BGP discards data, then no security mechanism should be 
able to preserve that data and use it to determine authorization. yet 
here you argue that one ought not be bound by extant, real world 
constraints when considering security issues. I think you cannot have 
it both ways!

>is necessary, but not sufficient.

To reiterate, policy is local and not enforceable on other ASes.

>authorization checks is not enough.

I no longer recall what numbers were assigned to which examples in 
your I-D, and I do not have a copy with me as I write this note. 
Still

But, what is a "valid" path anyway? did you define this term in the 
I-D? I'm not being facetious, just noting that we've been devoting a 
lot of energy discussing what an authorized path is and what it 
implies, so we ought to do the same for any other term that plays a 
major role in a proposal.

Steve

---

From: Nick Feamster <[email-masked]>
Date: Mon, 10 Nov 2003 10:53:33 -0500

> routes, so that the AS can at least avoid making forwarding decisions 

Sounds as though we agree.  btw, it's not just loops; bogus iBGP
configurations can also cause packets to be forwarded through other ASes
that are not on the advertised AS path.

> I see no difference between what I said and what you said, in any 

I think they are different.  

It's one thing for an AS to be able to know that all paths that it
advertises will conform to its policies, even as it advertises them to
others.  For example, specifying that it want to use one upstream as a
backup is a totally reasonable thing to do.  

It's something else for that AS to be able to impose arbitrary policies
on other ASes that have nothing to do with its own policies.

> security enhancement to BGP must do so as well.

I forwarding is still LPM, right?  So aggregation would still mess
things up with respect to conforming to the policy that the origin AS
wanted (i.e., punching a hole to specify traffic should be sent a
certain way).

Maybe I'm misunderstanding what S-BGP does or missed the discussion of
this in the ID.

> surprising that we should disagree about its significance.

OK, perhaps the draft should be refined in this respect.  I don't see it
as irrelevant at all.  I do think it's one piece of a larger puzzle.

That is, even if you have S-BGP/soBGP/whatever,  you still have to consider
various other things...which is what we're trying to say.

> what you and I disagreed about above.

One example: one AS wants to specify that a certain path is backup.

What's so unreasonable about asking other ASes to enforce that policy?

Now, I agree, you probably have to draw the line somewhere---can't just
impose arbitrary policies.  However, if one AS wants a particular path
used as backup, I think it's reasonable to try to make sure that
happens.

> constraints when considering security issues. I think you cannot have 

In both cases, these are things that cannot be done with today's
protocols (assuming we're talking about policy conformance; I'll avoid
using the word "authorization" ;).  I don't see any inconsistency here.
The point is that these are things we should be able to do today, but
can't.

> To reiterate, policy is local and not enforceable on other ASes.

Agreed, but it doesn't (and, in some cases, shouldn't) have to be that way.
That is, in some sense, one of the main points of the draft.

> I-D? 

Quoting from the draft:

"The validity of a path advertised by a given router actually consists
 of at least three parts:
      Does a path from the advertising router to the destination
      advertised actually exist?  
      
      Does the path advertised fall within the policies of the receiver?  
	    
     Is the advertising router authorized to advertise a path to the 
     destination?"

> I'm not being facetious, just noting that we've been devoting a 

Cheers,
-Nick

---

From: Stephen Kent <[email-masked]>
Date: Sun, 9 Nov 2003 17:27:29 -0500

>>  "don't use this path" is certainly true here, but its not relevant to

I agreed with your characterization in general terms, but noted that 
I prefer to talk in terms of the mechanisms vs. the implications. 
Hence, for example, it may be intent of AS1 in your example that AS3 
not transit traffic destined for AS1, but we know that AS1 cannot 
enforce this intent. If one talks in terms of the implications of an 
advertisement, then one has to be careful to restrict ones 
expectations of the implications.

Looking at your bullets above, we very much disagree about 1 & 2; the 
wording of 3 is sufficiently indirect that I won't comment on it one 
way of another. I cannot see any basis for these assertions, at least 
not 1 & 2 above. How do you interpret the semantics of BGP if you 
believe that AS paths do not imply authorization to advertise?

>border. How, exactly, is that not imposing my policy on you?

Please Russ, don't try to put words in my mouth; I'm really much 
better at it than you :-)

Of course an AS can express aspects of policy in its interactions 
with other ASes. What I said was that it cannot enforce its policy 
outside its own domain. Your example above re the advertisement of a 
/25, makes my argument, i.e., one AS's attempt to impose its policy 
on a neighbor is rejected  by the neighbor.

>No, I'm using it as it's defined above--the definition you agreed is

I agree that the words were about right, but you have started with 
those words and extrapolated in a fashion with which I don't agree.

>transit traffic through the path.

You keep emphasizing the part of the definition about which I 
expressed reservations, and which I have rejected in a number of 
messages. The word  "implication" is probably the wrong one to use 
here. What I think you are referring to are the "intentions" of the 
advertiser, and we have seen that the intentions are not enforceable 
and if one has unrealistic expectations,  the intentions are not 
likely to realized.

>it wipes out all the prior AS Path information. It's also perfectly legal,

In your sparse example, the owner of the /24 authorized the 
advertisement of its prefix by the owner of the subsuming /16, i.e., 
you indicated that the former sent an advertisement to the latter, 
who blocked it. If one makes provision for the advertisement of the 
/16 to convey the authorization provided by the owner of the /24, 
then reorigination can be managed securely. Yes, I know that BGP 
itself does not convey the data needed to verify the authorization, 
but we have ways to convey that data securely. So, this example is 
consistent with what I said in my previous message on this topic, 
i.e., if there is underlying authorization, then reorigination is not 
a problem and we just need to choose a means of conveying the 
underlying authorization.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 10 Nov 2003 16:11:48 -0500 (EST)

> I agreed with your characterization in general terms, but noted that I
> prefer to talk in terms of the mechanisms vs. the implications.  Hence,
> for example, it may be intent of AS1 in your example that AS3 not transit
> traffic destined for AS1, but we know that AS1 cannot enforce this
> intent. If one talks in terms of the implications of an advertisement,
> then one has to be careful to restrict ones expectations of the
> implications.

Well, it's the implications of the advertisement or lack of advertisement
that I care about, from a routing perspective.

> wording of 3 is sufficiently indirect that I won't comment on it one way
> of another. I cannot see any basis for these assertions, at least not 1 &
> 2 above. How do you interpret the semantics of BGP if you believe that AS
> paths do not imply authorization to advertise?

The symantics of BGP are built around reachabile destinations, and not
"authorization." The only reason for the AS Path is to prove the path is
not a loop. There's no concept of "authorization through advertisement" in
BGP, that I know of.

There is only point in the BGP routing system where "authorization to
advertise" has any meaning, and that's at the originator.

> on a neighbor is rejected  by the neighbor.

Or the other way around--one AS' policy of advertising a /25 is overridden
by another AS' policy of not accepting them. But you didn't address the
MED/Local Preference issue, either.

> You keep emphasizing the part of the definition about which I expressed
> reservations, and which I have rejected in a number of messages. The word
> "implication" is probably the wrong one to use here. What I think you are
> referring to are the "intentions" of the advertiser, and we have seen
> that the intentions are not enforceable and if one has unrealistic
> expectations, the intentions are not likely to realized.

No, I'm referring to the policy of the advertiser. From the best I can see,
you're claiming that if I advertise a prefix in a way that prevents my peer
from readvertising it, I'm expressing a policy that that peer should not
transit traffic destinated to addresses within that prefix to me. I'm
stating that this sort of policy, in this way, is impossible to enforce or
even encode within BGP.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 11 Nov 2003 11:52:34 -0500 (EST)

> > prefer to talk in terms of the mechanisms vs. the implications.
> > advertisement, then one has to be careful to restrict ones expectations
> > of the implications.

BTW, it might help to "reverse the characterization," then, and put it in
terms of advertisements, maybe? So, let's say that some AS, AS1, advertises
10.1.1.0/24 to AS2 in way that it cannot advertise 10.1.1.0/24 to AS3.
However, AS2 also has, from some other source (it doesn't matter where),
an update for 10.1.0.0/16 that it can advertise to AS3.

Since 10.1.0.0/16 contains 10.1.1.0/24, there's no way that AS1 can prevent
AS2 from advertising 10.1.1.0/24 to AS3--as a part of 10.1.0.0/16.

I hope this makes more sense--I'll try and work this type of
characterization into a new revision of the draft, as well as the other
suggestions you made earlier.

:-)

Russ