Subject: [RPSEC] some thoughts on requirements

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Feb 2005 13:19:27 -0500

Folks,

The discussion on BGP security requirements is again taking off 
without a detailed background and rationale discussion. The result is 
a set of proposed requirements that may not be comprehensive and 
which may be hard to motivate/justify.

In the security community, we prefer to start by articulating 
security relevant assumptions a protocol or system seems to embody in 
its operation in a benign environment. This provides rationale for 
security requirements that one then  ascribes to the protocol/system. 
Here are some thoughts on the sort of background and rationale I 
would propose for our security requirements document.

Steve
-------

Peer Communication

0.	BGP traffic travels over TCP between peers, so BGP speakers 
assume the TCP data delivery guarantees that accrue in a benign 
environment. This includes ordered, error-free delivery of 
application traffic from a peer identified by an IP address, plus 
integrity of the control aspects of TCP. From a security perspective, 
these guarantees need to be enforced in the context of possible 
active wiretapping.

Basic Application Concepts

1.	BGP is a protocol used to convey routing (reachability) 
information among autonomous systems. [this suggests a focus on e-BGP 
vs. i-BGP. I think this is appropriate because it appears that the 
most severe routing security failure modes arise when ASes receive 
and process bogus UPDATE info across AS boundaries. Routing security 
problems within an AS are the problem of that AS and its subscribers, 
and these may arise due to intra-AS routing problems independent of 
i-BGP use.]

2.	Inter-AS forwarding may not always be congruent with inter-AS 
routing, but the purpose of conveying BGP routing information from 
one AS to another is to influence inter-AS forwarding. [it's good to 
agree on intent in deciding what is and is not security relevant. The 
BGP spec says that a route advertised by a speaker is "used" by the 
speaker to forward the traffic specified by the advertisement. A 
corollary of this precept is that inserting a set of AS numbers in a 
route to cause the ASes in the set to ignore the route ought not be 
permitted. Also, because path length is a commonly used criteria in 
selecting from among routes for the same NLRI, we don't want a 
speaker to advertise a route that omits ASes, to make the route 
appear to be more preferable.]

Semantics of UPDATE Messages

3.	When AS A conveys a route to AS B via an UPDATE, AS A is 
soliciting traffic from AS B, consistent with the NLRI contained in 
the UPDATE. [if you do not want the traffic, why send the UPDATE to 
your peer?]

4.	When AS A conveys a route to AS B via an UPDATE, AS A is 
implicitly authorizing AS B to forward the route to other ASes, 
unless AS A has included the NO_EXPORT community as part of the 
UPDATE. [NO-EXPORT is a well-known community with a well-defined 
semantics. If AS A does not want AS B to forward the route, then AS A 
should include the NO-EXPORT community attribute.]

5.	An UPDATE message is not literally forwarded from  one AS to 
another. However "transitive" path attributes in an UPDATE message 
are intended to be forwarded to subsequent ASes (modulo the 
restriction noted in #4 above), IF the receiving AS elects to forward 
the route contained in the UPDATE. [parts of an UPDATE, e.g., 
withdrawn routes, are local, but other parts are intended to be 
forwarded to other ASes. The spec appears to be sloppy in its use of 
terminology, saying that the UPDATE message itself has traversed the 
path; a reasonable interpretation of the text focuses on the 
transitive path attributes.]

6.	The path contained in an UPDATE message represents the 
sequence of ASes that UPDATE messages associated with the NLRI 
traversed. [the BGP specs says this, but it is not clear how to 
interpret this in the case of AS sets resulting from path 
aggregation.]

a.	The first AS in the sequence should be the AS of the peer 
with which the BGP connection has been established. [the BGP spec 
describes UPDATE generation and calls for a speaker to prepend it's 
AS to the AS path when it generates an UPDATE.]
b.	An AS number may be appear multiple times in succession in an 
AS path. [the spec says this explicitly]
c.	An AS number must not appear more that once in an AS PATH, 
except as noted above. [this is stated I  the spec as part of the 
route loop prevention strategy.]

7.	The first AS in the AS path attribute of an UPDATE message 
represents the origin AS. The origin AS is the holder of the 
prefix(es) advertised in the NLRI in the UPDATE, or has been 
authorized by the prefix holders to originate the route in the UPDATE 
message. [BGP does not specify precise conditions under which routes 
may be originated, nor does it address the infrastructure associated 
with prefix allocation. However, it seems reasonable to assert that 
the origin AS is authorized to advertise the prefixes, else we are 
condoning bogus advertisements of origin ASes, and black-holing.]

8.	UPDATE messages, and the transitive attributes contained 
therein, carry no timestamps or sequencing numbers. Moreover, there 
is no notion of an advertisement "timing out." [this is derived from 
the BGP spec.] Thus, there is no way for an AS receiving an UPDATE to 
determine if the path attributes used to create the UPDATE are 
"fresh." This implies that an AS can retain attributes from an "old" 
UPDATE and use it an advertisement at any later point in time. 
Combined with the limitations on withdrawal processing noted below, 
this suggests that an AS can re-advertise a withdrawn route that was 
previously, legitimately advertised by the AS.

Route Withdrawal & BGP Limitations

9.	A route can be withdrawn only the by the peer who advertised 
it. [this is implied by the Adj-RIB-In part of the processing model.]

10.	An AS may withdraw a route because it learns a "better" route 
from a peer, or because a link to a peer fails, or because of a 
change to local policy. [this is specified in part by the spec.] Thus 
an AS receiving a route withdrawal in an UPDATE must accept it at 
face value, i.e., there is no way for a receiver to verify the 
criteria used by the sender in deciding to withdraw a route. [an AS 
can decide to withdraw a route for reasons for which there will be no 
externally visible evidence, because of the role played by the PIB in 
selection of a best route. Since an AS may advertise different routes 
to different peers, even external examination of advertisements for 
consistency does not represent a way to determine whether a 
withdrawal was "intentional" or the result of an attack or an error 
internal to an AS.]

11.	Because route withdrawal is a local aspect of an UPDATE, and 
because of the role of the PIB in determining best routes, there is 
no way to ensure that withdrawal of a route by an AS propagates 
through a peer to other ASes. To detect an erroneous failure of an AS 
to propagate route withdrawal would require an oracle capability by 
other ASes. (For example, these ASes would have to know when an AS 
more than one hop away withdrew a route, would have to know the 
topology of the Internet, and would have to know the PIB contents for 
intervening ASes in order to determine that a route withdrawal failed 
to propagate properly.) [the oracle capability does not seem to be 
one we should assume, for practical reasons. If we assume it, then it 
would solve many if not all of the security concerns that arise, and 
we should focus only creating that capability. Otherwise, we have to 
give up on being able to rely on propagation of withdrawals.]

Aggregation

12.	If a BGP speaker advertises a route based UPDATE messages 
(with the same next hop) containing more and less specific prefixes, 
then it  may choose to advertise an aggregated route containing only 
the less specific prefix. If this aggregated route does not contain 
all of the ASes from the constituent routes, the ATOMIC_AGGREGATE 
SHOULD be set. This represents an explicitly allowed deviation from 
the usual concept of forwarded traffic traversing only the ASes 
enumerated in the path. [this process is described in the BGP spec, 
but since the spec says that inclusion of ATOMIC is now 
informational, it seems to weaken the principle of forwarding being 
congruent to the advertised path in general (since we can't even know 
if a route was purportedly the result of aggregation. This probably 
warrants changes to the BGP text by IDR, to make the standard more 
internally consistent. From a security perspective this says that we 
cannot mandate simple matching of a path in an UPDATE to any graph if 
aggregation has been performed. Moreover, because of the loophole 
created by the fact that a speaker need not even declare that it has 
performed aggregation, this makes it hard to know when deviation from 
a graph is potentially valid. One can imagine ways to avoid these 
problems, e.g., by having speakers NOT delete ASes when performing 
aggregation in this fashion, but the current BGP text is awfully 
"flexible" here :.]

13.	If a BGP speaker sends an UPDATE message with a route that is 
the result of aggregating routes received from peers via UPDATE 
messages, the resulting route must preserve the AS SEQUENCE and SET 
ordering of the constituent routes. The aggregated route also must 
not omit any of the ASes or AS SETs from the routes used to construct 
it, and must not duplicate these route elements. (there are lots of 
other prohibitions on aggregation here, e.g., not aggregating routes 
with different MEDs. A more through discussion of aggregation is 
needed to cover this topic comprehensively and more clearly.) [the 
BGP spec provides rules for how to construct such aggregated routes, 
separate from the discussion of route aggregation in the context of 
overlapping routes. This part of the spec provides another 
justification for emitting an UPDATE message that contains path 
attributes that are not just the result of prepending one's own AS 
number to a route received via an UPDATE.]

Route Origination

14.	Originating a route for a prefix for which the speaker has no 
ability to forward traffic would conflict with the basic BGP 
principle noted earlier, i.e., routes represent how a speaker 
forwards traffic. So it is important to provide means to detect and 
reject routes that fail in this regard.

15.	 A BGP speaker may originate a route based on other sources 
of data, specifically routes received via IGP and via local 
configuration. [the BGP spec calls out the first example, but the 
second example seems obvious. However, the spec says nothing about 
criteria to be applied when originating a route from local 
configuration data.]

16.	A BGP should originate routes for a prefix only if the prefix 
has been allocated to its AS, or that its AS has been authorized to 
advertise the prefix by the prefix holder. [obviously if an AS has 
bee allocated a prefix, it is authorized to originate it. If the 
prefix holder becomes a subscriber of the AS, then the AS is 
authorized to advertise that prefix as well. None of this is 
explicitly stated in the BGP spec, but it seems derivable from the 
explicitly stated concept that routes represent how an AS forwards 
traffic. An aspect of this proposed requirement that is debatable is 
whether an AS should be allowed to originate a route that represents 
an implicit form of aggregation, e.g., the prefixes are NOT held by 
the AS or by subscribers, but rather represent the AS's view of the 
topology behind it

Communities

17.	???

18.

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

---

From: Stefan Mink <[email-masked]>
Date: Wed, 02 Feb 2005 09:41:04 +0100

Hi Stephen,

for me this looks like a good start...

Stephen Kent wrote:
> implicitly authorizing AS B to forward the route to other ASes, unless 
> AS A has included the NO_EXPORT community as part of the UPDATE. 
> [NO-EXPORT is a well-known community with a well-defined semantics. If 
> AS A does not want AS B to forward the route, then AS A should include 
> the NO-EXPORT community attribute.]

for me this is too broad: when I announce a route to a customer,
I do not give the authorization to forward it to any other
ASes, but only to customer ASes.

> 16.    A BGP should originate routes for a prefix only if the prefix has 
> been allocated to its AS, or that its AS has been authorized to 

is a prefix ever allocated to an AS? AFAIK it's allocated to a LIR
which may be operating an AS or not.

    tschuess
              Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Tony Tauber <[email-masked]>
Date: Wed, 2 Feb 2005 09:38:10 -0500

[ Writing not as WG co-chair, but as a longtime carrier BGP operator,
now edge BGP operator ]

> > semantics.  If AS A does not want AS B to forward the route, then
> > AS A should include the NO-EXPORT community attribute.]
>
> for me this is too broad: when I announce a route to a customer, I
> do not give the authorization to forward it to any other ASes, but
> only to customer ASes.

Good clarification which points to something not within the base BGP
spec but well cemented w/in operational practice.  Most ISPs have
defined community values for use by customers which can produce this
kind of effect.  This feature is part of the fairly rich policy
language of BGP that is so treasured by its users.

I've known of significant use also of tagging routes inbound from
another AS in some way to influence behavior.  If this approach is
used with prior consent, it changes the implicit expectations.
That is the receiving AS may be applying a policy on the sender's
behalf with the sender having the expectation that that policy will be
in force.

How about this alternate text:

++ > 4.   When AS A conveys a route to AS B via an UPDATE, AS A is
++ > implicitly authorizing AS B to forward the route to other ASes.
++ > Exceptions to this convention may be derived by tagging the
++ > UPDATE with either a well-known community value such as NO_EXPORT
++ > or another value which may have been locally agreed upon to
++ > limit or affect re-announcement in some way.  Alternately, this
++ > policy can be effected by the receiving AS either unilaterally or
++ > by prior agreement with AS A.

> > 16.   A BGP should originate routes for a prefix only if the
> > prefix has been allocated to its AS, or that its AS has been
> > authorized to
>

Another good point, as is becoming clear, there is inconsistent
congruence between the delegation structure and the BGP structure.
How this fact interacts with the problem at hand is a matter for our
attention and comment at the very least.

Tony

---

From: Stefan Mink <[email-masked]>
Date: Wed, 02 Feb 2005 16:42:57 +0100

Hi Tony,

> ++ > by prior agreement with AS A.

perfect!

    tschuess
              Stefan

---

From: Russ White <[email-masked]>
Date: Wed, 2 Feb 2005 10:47:02 -0500 (Eastern Standard Time)

> ++ > by prior agreement with AS A.

I don't quite understand: When you say an AS "implicitely authorizes the 
advertisement of the routing information," could you explain what you mean? 
Authorization carries with it the concept of being authorized to do 
something. What is it you're authorizing?

What you're discussing here is policy--it is either the advertiser's policy 
to allow transit through them, or to them through the peer they've 
advertised the route to, or it's not their policy. There's no concept of 
"authorization" here, and we should do our best to leave the concept of 
"authorization" out of this.

You can verify or validate an AS has authorization to originate a specific 
route, but BGP has no concept of "authorization to readvertise something 
I've received." The entire concept is in terms of policy, so let's stick to 
policy, which is the correct term.

:-)

Russ

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

---

From: Tony Tauber <[email-masked]>
Date: Wed, 2 Feb 2005 11:28:34 -0500

On Wed, 2 Feb 2005, Russ White wrote:

> > ++ > implicitly authorizing AS B to forward the route to other
> > ++ > ASes.  Exceptions to this convention may be derived by
> > ++ > tagging the UPDATE with either a well-known community value
> > ++ > such as NO_EXPORT or another value which may have been
> > ++ > locally agreed upon to limit or affect re-announcement in
> > ++ > some way.  Alternately, this policy can be effected by the
> > ++ > receiving AS either unilaterally or by prior agreement with
> > ++ > AS A.
>
> I don't quite understand: When you say an AS "implicitely authorizes
> the advertisement of the routing information," could you explain
> what you mean?  Authorization carries with it the concept of being
> authorized to do something. What is it you're authorizing?

Well, what it says is "authoriz[ing] AS B to forward the route to
other ASes."  That is, authorizing AS B to propagate the routing
information further.  I'm not married to the idea if it's not right,
but I thought I'd pose some wording.

> What you're discussing here is policy--it is either the advertiser's
> policy to allow transit through them, or to them through the peer
> they've advertised the route to, or it's not their policy.

OK, but the default policy (ie. the implicit policy) is to allow the
AS you send the route to to propagate it further, thereby drawing
traffic through them from beyond (transiting AS B).
Absent other configuration, I believe that's how it works.

> There's no concept of "authorization" here, and we should do our
> best to leave the concept of "authorization" out of this.

I don't know what extra flavor it gives, but OK.

> You can verify or validate an AS has authorization to originate a
> specific route, but BGP has no concept of "authorization to
> readvertise something I've received." The entire concept is in terms
> of policy, so let's stick to policy, which is the correct term.

So, absent some other expression of policy, the default behavior and
the methods of expressing the policy are currently as described?
What text would be better?

Tony

---

From: Russ White <[email-masked]>
Date: Wed, 2 Feb 2005 12:18:30 -0500 (Eastern Standard Time)

> Well, what it says is "authoriz[ing] AS B to forward the route to other 
> ASes."  That is, authorizing AS B to propagate the routing information 
> further.  I'm not married to the idea if it's not right, but I thought 
> I'd pose some wording.

Do you mean authorizing the advertisement of reachability information to a 
peer's peers?

> OK, but the default policy (ie. the implicit policy) is to allow the AS 
> you send the route to to propagate it further, thereby drawing traffic 
> through them from beyond (transiting AS B). Absent other configuration, I 
> believe that's how it works.

But now you're trying the advertising of routing information (reachability) 
to forwarding, which brings us back to the forwarding conundrum. If I can't 
prevent someone from forwarding traffic to me along a certain path, 
implying I can't "!authorize" them to forward traffic along that path, then 
what does the concept of "authorization" mean.

This is specifically why we shouldn't use the term "authorization" in this 
context. It opens too many ratholes and problems we just don't want to get 
in to (unless we want to go into requiring routers to modify their current 
routing/forwarding behaviour, which would be a larger issue than what I 
think we're scoped to handle here).

> I don't know what extra flavor it gives, but OK.

That you can prevent it from happening if you don't "authorize" it.

> So, absent some other expression of policy, the default behavior and the 
> methods of expressing the policy are currently as described? What text 
> would be better?

I'm sticking with the wording I posted to the list several days ago...

--

  o Routing information carried through BGP SHOULD include information
    which can be used to verify readvertisement or modification by each
    autonomous system through which the route has passed.

  o A BGP speaker MUST, on receiving a route from a peer, be able to
    verify the AS Path, beginning with the first AS listed in the AS
    Path, progressing through each AS listed in the AS Path, and ending
    in the autonomous system advertising the route to the receiving
    speaker, is a valid route within the internetwork.

(Where valid means the AS Path matches a set of pairwise peering
relationships that can be shown to exist in the internetwork, and the
policy of each AS listed in the path permits the transiting of traffic
through the AS).

  o A BGP speaker MUST, on receiving a route from a peer, be able to
    verify the originating AS has authorization to advertise the prefix
    contained in the route.

--

Note that none of this is in terms of traffic, or forwarding, or 
"authorization," at all. I originally implied the policy in the second one 
above, but you could call out policy separately, if you wanted to. We can 
discuss the "MUST" or "SHOULD" state of each one:

  o A BGP speaker [SHOULD/MUST], on receiving a route from a peer, be able
    to verify the originating AS' policy in regards to transiting traffic
    through the advertising speaker's AS or the local AS.

  o A BGP speaker [SHOULD/MUST], on receiving a route from a peer, be able
    to verify the advertising AS' policy in regards to transiting traffic
    through the local AS.

:-)

Russ

---

From: Tony Tauber <[email-masked]>
Date: Wed, 2 Feb 2005 13:27:35 -0500

On Wed, 2 Feb 2005, Russ White wrote:
> > information further.  I'm not married to the idea if it's not
> > right, but I thought I'd pose some wording.
>
> Do you mean authorizing the advertisement of reachability
> information to a peer's peers?

Yes.

> > OK, but the default policy (ie. the implicit policy) is to allow
> > the AS you send the route to to propagate it further, thereby
> > drawing traffic through them from beyond (transiting AS B). Absent
> > other configuration, I believe that's how it works.
>
> But now you're trying the advertising of routing information
> (reachability) to forwarding, which brings us back to the forwarding
> conundrum. If I can't prevent someone from forwarding traffic to me
> along a certain path, implying I can't "!authorize" them to forward
> traffic along that path, then what does the concept of
> "authorization" mean.
>
> This is specifically why we shouldn't use the term "authorization"
> in this context. It opens too many ratholes and problems we just
> don't want to get in to (unless we want to go into requiring routers
> to modify their current routing/forwarding behaviour, which would be
> a larger issue than what I think we're scoped to handle here).

OK, with forwarding/routing, but regarding the propagation of the
reachability info, the default behavior is that it can go further than
the neighbor AS, ie. it's implicit.

> That you can prevent it from happening if you don't "authorize" it.

Well, I believe (and others should chime in right here), that
strengthening the policy enforcement might be a goal of securing BGP
(or not, but others should make some indication.)

> > So, absent some other expression of policy, the default behavior
> > and the methods of expressing the policy are currently as
> > described? What text would be better?
>

Well, what I was commenting on was what Steve sent (and Stephan
commented upon) which was an attempt to expose the "motives" behind
the requirements.  (Would these motives be included in the
requirements doc as a precursor to the requirements section?)

I think trying to derive these has merit.  I recollect Steve
commenting at the last RPSEC meeting that the document didn't provide
enough in the way of "motivation" for the requirements and expect his
strawman text was an effort to get things rolling.

All that seems like an especially good place to get Operator input.

Tony

> "authorization," at all. I originally implied the policy in the
> second one above, but you could call out policy separately, if you
> wanted to. We can discuss the "MUST" or "SHOULD" state of each one:
>
>   o A BGP speaker [SHOULD/MUST], on receiving a route from a peer,
>     be able to verify the originating AS' policy in regards to
>     transiting traffic through the advertising speaker's AS or the
>     local AS.
>
>   o A BGP speaker [SHOULD/MUST], on receiving a route from a peer,
>     be able to verify the advertising AS' policy in regards to
>     transiting traffic through the local AS.
>

---

From: Russ White <[email-masked]>
Date: Wed, 2 Feb 2005 14:04:43 -0500 (Eastern Standard Time)

>> information to a peer's peers?

To what end? Authorizing the advertisement of routing information to your 
peer's peers isn't a requirement. When you explain _why_ you want this, 
you've hit the requirement. On the other side, stating that this is somehow 
"implicit" in BGP is simply untrue.

> the neighbor AS, ie. it's implicit.

That's the default policy, but it's not "authorization."

> strengthening the policy enforcement might be a goal of securing BGP (or 
> not, but others should make some indication.)

To change this, you're going to need to change more than BGP. You're going 
to have to change the basic requirements for routers, and I believe that 
when you get into that discussion, what you're going to find is that 
everyone wants you to change these requirements for everyone else, but not 
for them. I also happen to think that discussion would be outside the scope 
of the RPsec working group, since it impact a lot of other areas than even 
routing protocols.

> Well, what I was commenting on was what Steve sent (and Stephan commented 
> upon) which was an attempt to expose the "motives" behind the 
> requirements.  (Would these motives be included in the requirements doc 
> as a precursor to the requirements section?)

I don't agree with stating there's an "implicit authorization" anyplace in 
BGP. I've worked on BGP for years, and never heard of such an "implicit 
authorization," nor has anyone I know ever treated it that way. It is often 
described in terms of policy, but never authorization.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 14:06:45 -0500

At 9:41 AM +0100 2/2/05, Stefan Mink wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig20CCFD98243149EA39FB7E29"
>
>
>Hi Stephen,
>
>>semantics. If AS A does not want AS B to forward the route, then AS 
>>A should include the NO-EXPORT community attribute.]
>

I see that Tony made the same observation, but an examination of the 
BGP specs does not give any indication of this constraint as part of 
the protocol.

how does one define "customer ASes" in an objective fashion?

>which may be operating an AS or not.

Good point. prefixes are allocated to organizations, and 
organizations may operate ASes, or may be subscribers.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 14:28:50 -0500

>authorized to do something. What is it you're authorizing?

The text says that the authorization in question is permission to 
forward the route to other ASes.

>they've advertised the route to, or it's not their policy. There's 
>no concept of "authorization" here, and we should do our best to 
>leave the concept of "authorization" out of this.
>

We'vge disagreed about this before and no amount of discussion 
between us seems likely to change that.  I'll rely on the rest of the 
WG to decide whether the terminology is appropriate or not.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 14:28:58 -0500

Tony,

>++ > by prior agreement with AS A.

The last part sentence is a bit confusing to me, since the focus of 
the original #4 was to describe the intent of an advertisement from A 
to B. Unilateral actions by B re interpreting an advertisement don't 
help much from a security perspective. Can you elaborate?

>attention and comment at the very least.

I though this was a simple terminology fix. Is the text in my 
response not sufficient?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 14:28:41 -0500

Russ,

	<SNIP>
>traffic along that path, then what does the concept of 

If nobody believed that routes and forwarding were generally 
congruent, we would not bother advertising routes. Each AS exercises 
autonomy in managing its forwarding table, just as it does its 
Loc-RIB. But, it is advantageous to advertise routes to neighbors, 
and beyond, to influence the traffic that is forwarded to an AS, if 
only to avoid having to receive traffic and throw it away.

Moreover, the discussion on this list re use of bogus AS sets by ISPs 
to cause more distant ASes to reject advertised routes is a clear 
attempt to influence forwarding.

You can't have it both ways, i.e., if you insist that some forms of 
BGP behavior not condoned by the specs are mandated by operational 
necessities, then the motivations behind the behavior should be 
examined to develop security requirements.

	<SNIP>

>traffic along that path, then what does the concept of 

I hate to have to say this, but the above statement is a 
non-sequitur. Maybe you can reword it to yield the result you want 
and conform to prepositional logic, but as it stands, ...

Steve

---

From: [email-masked]
Date: Wed, 2 Feb 2005 20:12:10 +0000

> and beyond, to influence the traffic that is forwarded to an AS, if 
                ^--- try and  (or might be better stated, suggest to 
	a peer how 'they' (the immediate AS) want their peers to treat
	the prefix.  It is not clear to me that there is -any- way using
	the BGP protocol to allow the originating AS to enforce any
	expected behaviour by an MIM-AS.  so how is a receiving AS
	able to distinguish between the originating AS policy/desire
	and some MIM-AS who wants to inflict its own policies on the prefix.

-- bill

---

From: Tony Tauber <[email-masked]>
Date: Wed, 2 Feb 2005 15:18:23 -0500

On Wed, 2 Feb 2005, Stephen Kent wrote:

> >++ > ASes.  Exceptions to this convention may be derived by tagging
> >++ > the UPDATE with either a well-known community value such as
> >++ > NO_EXPORT or another value which may have been locally agreed
> >++ > upon to limit or affect re-announcement in some way.
> >++ > Alternately, this policy can be effected by the receiving AS
> >++ > either unilaterally or by prior agreement with AS A.
>
> the original #4 was to describe the intent of an advertisement from
> A to B. Unilateral actions by B re interpreting an advertisement
> don't help much from a security perspective. Can you elaborate?

The situation I had in mind (common in my experience) was for a
service provider to agree with a customer to (or other provider) to
apply some policy inbound which would affect the re-advertisement
(allowing or disallowing to some extent).
Alternately, AS B might decide not to announce another ISP's routes to
some subset (or all) of its customers.

I guess you're saying what AS B decided to do on it's own doesn't
change what AS A might have wanted.

> >>  is a prefix ever allocated to an AS? AFAIK it's allocated to a
> >>  LIR which may be operating an AS or not.
> >

Well, there has to be a provision for an entity w/o an AS to
authorize, if that's what's desired.  Also, as Stephan pointed out,
currently, no mapping between address allocation and AS, even though
they are done by the same numbering authorities.  For instance, a
previous employer had many ASNs and much address space but there was
no mapping of which went where, and, as they came from acquisitions,
there was no strong correlation, either.

The numbering authorities mostly seem to prevent collisions and it
could be argued that BGP only requires that no collisions occur w/o
inherent attention to who is authorized as long as the traffic can
be delivered to the right place.
Since traffic delivery can occur outside the scope of BGP, it seems to
make sense to try and connect the AS to the prefix more solidly than
is done today.

Tony

---

From: Tony Tauber <[email-masked]>
Date: Wed, 2 Feb 2005 15:30:06 -0500

On Wed, 2 Feb 2005, Russ White wrote:

> To what end? Authorizing the advertisement of routing information to
> your peer's peers isn't a requirement. When you explain _why_ you
> want this, you've hit the requirement. On the other side, stating
> that this is somehow "implicit" in BGP is simply untrue.

I want it so that traffic from beyond them might reach me.
In trying to figure whether it's implicit or not, I find myself
thinking that there's no way to make it _explicit_. Thus I reason
after the fact that it must be implicit.  Generally, don't routing
protocols seek to propagate information as far as possible short of
causing loops and so forth?

> > reachability info, the default behavior is that it can go further
> > than the neighbor AS, ie. it's implicit.
>

As above, I don't know what the difference is in this case, though
perhaps you could explain it.

> > strengthening the policy enforcement might be a goal of securing
> > BGP (or not, but others should make some indication.)
>
> To change this, you're going to need to change more than BGP. You're
> going to have to change the basic requirements for routers, and I
> believe that when you get into that discussion, what you're going to
> find is that everyone wants you to change these requirements for
> everyone else, but not for them. I also happen to think that
> discussion would be outside the scope of the RPsec working group,
> since it impact a lot of other areas than even routing protocols.

A big assertion (you're going to need to change more than BGP) that
I'm not sure I buy.  I'd like to hear more discussion.

> > commented upon) which was an attempt to expose the "motives"
> > behind the requirements.  (Would these motives be included in the
> I don't agree with stating there's an "implicit authorization"
> anyplace in BGP. I've worked on BGP for years, and never heard of
> such an "implicit authorization," nor has anyone I know ever treated
> it that way. It is often described in terms of policy, but never
> authorization.

I don't know what the difference is.  How about "permission"?
Is the concern that it sounds too contractual?
If you allow it, explicitly, does that not mean that you've authorized
it? ie. said "That's OK for you to do."

Tony

---

From: Russ White <[email-masked]>
Date: Wed, 2 Feb 2005 15:56:29 -0500 (Eastern Standard Time)

> I want it so that traffic from beyond them might reach me. In trying to 
> figure whether it's implicit or not, I find myself thinking that there's 
> no way to make it _explicit_. Thus I reason after the fact that it must 
> be implicit.  Generally, don't routing protocols seek to propagate 
> information as far as possible short of causing loops and so forth?
>

The biggest difference between policy and authorization is that 
authorization implies I can "not authorize" something, which means I can 
prevent it from happening. Policy means I would like for this to happen, 
within with reality of my peer's policies. Policies interact with each 
other, authorization implies I have sole control over a specific action 
others can or will take.

> A big assertion (you're going to need to change more than BGP) that I'm 
> not sure I buy.  I'd like to hear more discussion.

If you want to be able to _force_ someone else to take specific forwarding 
actions based on the information provided through a routing protocol, 
you're reaching much farther than the routing protocol itself, and into 
very broad, hard to define, and hard to get agreement on areas.

> I don't know what the difference is.  How about "permission"? Is the 
> concern that it sounds too contractual? If you allow it, explicitly, does 
> that not mean that you've authorized it? ie. said "That's OK for you to 
> do."

The problem is, if I say: "You are authorized to do this," it implies I can 
also say: "You aren't authorized to do this," that I can somehow prevent 
you from doing this. In reality, you can't prevent someone from forwarding 
traffic to you along a path through routing. You can do it with packet 
filters, but not, strictly, in routing. If you wanted to say you should be 
able to prevent someone from forwarding traffic along a path through 
routing alone, then you end up controlling the data plane, the interaction 
between the data and control planes, as well as a host of other things. 
We just don't want to go there, IMHO.

You can try to word it as: "The receipt of routing information implies 
permission to route traffic towards the advertising peer, but lack of 
received (specific?) routing information doesn't imply lack of 
authorization," then you might get at the gist of the problem. IMHO, the 
concept of "authorization," in this environment, just doesn't make any 
sense.

For instance, a community is a "group of routes to which a common policy 
applies," rather than a: "group of routes to which a common authorization 
applies." The entire BGP language, peering structure, and additions to BGP 
are built on policy, not authorization, at the peering point.

The concept of authorization already exists at the origination point. 
Extending authorization to the peering point, injecting "authorization" at 
the peering point is a much bigger mess than we want to get in to.

:-)

Russ

---

From: Tony Tauber <[email-masked]>
Date: Wed, 2 Feb 2005 16:35:32 -0500

On Wed, 2 Feb 2005, Russ White wrote:
> authorization implies I can "not authorize" something, which means I
> can prevent it from happening. Policy means I would like for this to
> happen, within with reality of my peer's policies. Policies interact
> with each other, authorization implies I have sole control over a
> specific action others can or will take.

OK, I see what you mean.  Taking off also from what Bill posted, I'd
state that in my experience, the absolute self-determination of an AS
is one of the guiding principles of BGP.  I don't know if it's
explicitly stated anywhere, but that's been my observation.  Anyone
else care to give their two cents?

<snip>

[Your other points seem to be re-statements of this bit above.]

> The concept of authorization already exists at the origination point.

It does?  I'm not sure I get that in light of the other things you
said.

Tony

> Extending authorization to the peering point, injecting
> "authorization" at the peering point is a much bigger mess than we
> want to get in to.

---

From: Russ White <[email-masked]>
Date: Wed, 2 Feb 2005 16:44:06 -0500 (Eastern Standard Time)

> state that in my experience, the absolute self-determination of an AS is 
> one of the guiding principles of BGP.  I don't know if it's explicitly 
> stated anywhere, but that's been my observation.  Anyone else care to 
> give their two cents?

I should actually say that policies interact with each other and with 
contracts. :-)

This "absolute determination of an AS" is one of the problems we're going 
to face throughout.... Which is why I say a lot of people would like to 
force everyone else to do "x," but they wouldn't want someone else to force 
them to do "x." Kind-of like governmental organizations.... <hehe>

> It does?  I'm not sure I get that in light of the other things you said.

Well, not in BGP. It does exists within the address allocation structure, 
BGP really doesn't have too much to say about this piece, but I don't think 
we can, or want to, ditch the concept of authorization at the origination 
point.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 17:07:39 -0500

>	and some MIM-AS who wants to inflict its own policies on the prefix.

Bill,

As we are developing a requirements document at this stage, it seems 
appropriate to explore what is the intent of an AS in propagating an 
advertisement, without yet asking how one can enforce that intent.

Because ASes are "autonomous" it's fair to say that AS A can't rely 
on other ASes to propagate any advertisement A sends, since A does 
not in general know the local policies of these other ASes, who may 
choose to not propagate an advertisement, even if we assume that the 
other ASes are operating "correctly."
But, I hope we can discover a shared perception of what constitutes 
correct behavior in terms of route origination and propagation. If 
there is no shared perception, that would suggest that ASes advertise 
routes with no notion of the effect of the advertisements, which 
seems hard to believe.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 17:00:54 -0500

>change what AS A might have wanted.

yes, that is what I am saying.

>there was no strong correlation, either.

yes, there has to be a provision for tracking the delegation of 
prefixes, and we need a scheme that parallels what folks do when they 
delegate, acquire prefixes via mergers or bankruptcy, etc. there 
should be no need for the RIRs to be involved in delegation that 
takes place after they have done initial assignments, except when a 
prefix is returned to them for reallocation.

>make sense to try and connect the AS to the prefix more solidly than

traffic delivery does occur independent of BGP, it it's intra-AS or a 
result of static route configuration. But, the big security problems 
for BGP do not seem to be the ones that arise in these contexts. 
rather, it is inter-AS routing as a result of advertisement 
propagation where the big security issues arise.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 17:20:56 -0500

Russ,

>specific action others can or will take.

"Authorization" is commonly viewed as a synonym for permission, as 
any thesaurus will confirm.

Generally folks understand that withholding permission does not 
equate to enforcing a prohibition of an action granted by a 
complimentary permission.

Any parent will attest to the truth of this interpretation :-) , as 
will many police officers, etc.

Steve

---

From: Blaine Christian <[email-masked]>
Date: Wed, 02 Feb 2005 17:58:41 -0500

> prefix is returned to them for reallocation.

Just breezing through the thread and found this one...  You are absolutely
correct.  After initial delegation the prefix usage is the responsibility of
the operator who purchased the space.  An additional point would be that the
registries, also, enforce adequate usage of the space before allocating more
to prevent gorging by operators.

---

From: Blaine Christian <[email-masked]>
Date: Wed, 02 Feb 2005 18:16:35 -0500

> advertisement, without yet asking how one can enforce that intent.

Well said...

> routes with no notion of the effect of the advertisements, which

Let me try phrasing it this way...  There is a consensual view of reality on
the Internet WRT BGP.  That view is that a certain netblock is reachable as
advertised by a EBGP neighbor AS.  The only thing, currently, we can be
absolutely sure of is that our neighbor advertised a prefix and that it
"looks" like it traversed a set of AS's.  It is common perception that your
prefix traversed that set of AS's and that, if you were to have a view of
the route table in each AS, you would see that prefix.  In most cases that
view would be correct.  However, the AS numbers and prefixes are bound
together loosely.  Perhaps, if we could take the term AS out of the realm of
BGP then it might apply quite neatly to our situation.

It is clear that a set of networks under common administration could be
considered an autonomous system without necessarily having a single AS.  A
common example might be my old network which used many AS numbers and
distributed prefixes between them.  I could say that the network itself
(including all AS's) was an autonomous system.

Should we try to decrease our focus on AS path in general and talk about an
autonomous system as a network (or collection of networks) under common
administration?  I suspect everyone can agree on the establishment of a
"path" from origination point to the local device as a valid component of a
secured prefix exchange infrastructure (or can we?).  After all, in any
system, if we don't know how the prefix came to us how can we be comfortable
with it?

---

From: [email-masked]
Date: Wed, 2 Feb 2005 23:21:05 +0000

> to prevent gorging by operators.

	er... rir's track delegations - when a prefix changes
	administrative and technical handles, the rir needs to
	know.  remember, address space is not property that can be
	purchased.  address space is delegated for responsible use
	and must be re-affirmed to the rir on a regular basis.
	legacy delegtions are a distinctly different matter.
	so in general, i strenuously disagree with both of you.

	i would encourage folks to make themselves aware of current
	address delegations policies ... www.arin.net is a good 
	starting point.

---

From: Blaine Christian <[email-masked]>
Date: Wed, 02 Feb 2005 18:32:16 -0500

> so in general, i strenuously disagree with both of you.

Not sure why you disagree with me <grin>.  I agree with you for the most
part.  However, I would say that address space is "leased" through
membership fees at ARIN.

I also agree that initial delegations are tracked through ARIN.  But, If you
read the ARIN policy it states that delegated blocks of a certain size must
have a delegation within ARIN.  It does not state that all blocks allocated
to ISP customers must be delegated.

The fact that the ARIN policy states something does not mean that every
operator adheres to that policy (although I do).

What typically happens is that if you do not follow the ARIN policies and
they find out you end up getting cut off from further delegations until your
behavior changes.

Also, ARIN may track, to a small degree by AS number.  In no way shape or
form to they dictate which of my AS's I have to use it with (which means an
entity that has several AS's or business units transfers things about with
impunity).

---

From: [email-masked]
Date: Wed, 2 Feb 2005 23:34:25 +0000

> advertisement, without yet asking how one can enforce that intent.

	looking carefully here is useful.
 
> other ASes are operating "correctly."

	core bgp (as i remember it) allows me to take information/prefixes
	that I know (learned from static entries, IGP processes, or
	from other external neighbors) and pass on, to my neighbors,
	my willingness to accept packets for those prefixes.  extentions
	to bgp have attempted to temper information i receive (AS striping/
	packing) and information i send on (AS striping/packing, etc.)

	once my neighbor receives my willingness message, her local 
	policies may completely over-ride my wishes/intent.
	and last i checked, anyone beyond my neighbor has no visability
	to my desired behviour...

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 18:34:08 -0500

Bill,

I know that ARIN tracks further delegation by ISPs, but it uses the 
tracking as a means to ensure that a request from an ISP for more 
address blocks is justified. As a result, the feedback re delegation 
is not necessarily very fast, which would cause problems for our use 
of such delegation.  Also, I was know sure if all the RIRs imposed 
similar requirements, or if their experience in the timeliness of 
such reporting is comparable to that of ARIN.

So, in my defense, what is needed for routing security is a means of 
tracking address block delegation, transfers, etc. in a timely 
fashion which is likely to be more demanding than what the RIRs 
require.

Steve

---

From: [email-masked]
Date: Wed, 2 Feb 2005 23:43:30 +0000

> to ISP customers must be delegated.

	no... but they must be accounted for on a regular basis..

> operator adheres to that policy (although I do).

	true.

> they find out you end up getting cut off from further delegations until your

	from a more charitable view, ARIN insists on documentation
	before delegating more responsibility.  

> entity that has several AS's or business units transfers things about with

	yes - arin looks for responsible use.  not connectivity to 
	some portion of the "Internet"

---

From: [email-masked]
Date: Wed, 2 Feb 2005 23:45:44 +0000

> fashion which is likely to be more demanding than what the RIRs 

	indeed.  and RIR whois data is not even close. :)

---

From: Stefan Mink <[email-masked]>
Date: Thu, 03 Feb 2005 08:37:55 +0100

Stephen Kent wrote:
> I see that Tony made the same observation, but an examination of the BGP 
> specs does not give any indication of this constraint as part of the 
> protocol.

thats right; it's not in the specs because it only concerns
the usage of BGP, not the (software) implementation.

> how does one define "customer ASes" in an objective fashion?

you hit the most difficult aspect :]
Who is a customer and for which prefixes is an agreement
between two providers. I even think coupling this to the
word customer is wrong because it implies money. Although
it used to be the case that peering implied "settlement-free"
and transit implied "cost-based", this is not the case anymore.
Peerings can cost money and transit can be free, I've seen
all of them. The usage of customers and peers just makes this
easier to explain because most people can work better with
these terms.

In reality its about announcement scopes: Gets the receiver of
a route authorized to flood the route without limitation (this
matches a transit provider receiving a route) or is there a
limitation.

It's hard to explain but for me - although Russ may be right
that it's hard to implement today - it's one of the key aspects
of routing security:

   Verification of origin authorization is meant to prevent
   that an attacker creates a route and by this attracts traffic
   and e.g. blackholes it.
   What does it help if you can verify that somebody was
   authorized to announce a route but any attacker can
   attract traffic to it by means of unauthorized readvertisements
   which has similar results as unauthorized origination:
   The attacker is capable of attracting (parts of) the
   traffic and can attack it.

Origin Verification is necessary and good, but it's not the
complete story.

    tschuess
              Stefan Mink

---

From: Stefan Mink <[email-masked]>
Date: Thu, 03 Feb 2005 08:49:59 +0100

Russ White wrote:
> traffic along that path, then what does the concept of "authorization" 
> mean.

I'm in favor of dropping this argument "forwarding may not do the
same as routing". Either we assume that forwarding and routing are
tied and we go on trying to secure the routing layer or we accept
that routing and forwarding are different worlds and then every
minute we spend here is lost because securing routing doesn't
secure forwarding anyway. And securing the forwarding behavior is
what it's all about, isn't it?

If we don't get to a decision, how we handle this point, this
will impact the decision forever (it already does for
months/years if I remember this well...)

    tschuess
              Stefan

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 Feb 2005 09:40:47 -0500

Tony,

> causing loops and so forth?

BGP will only accept information into the adj-rib-in for
a given peer or place a route into the adj-rib-out if it passes
a policy check.  (See the decision process.)

The default policy on routers shouldn't be confused with the default
policy of BGP.

As more than one operator has said, "BGP is all about policy". :-)

The typical exercise of policy is obviously going to depend on what
your business model and needs are:

Edge ASes more often than not want their reachability to go as far
as it can so they can receive traffic from as much of the Internet
as they can.  However, we know from data from organizations like
CAIDA that there are parts of the Net that are unreachable because
the routes aren't getting through to the appropriate places.

Transit ASes that don't consider themselves part of the "core",
more colloquially tier-2/3, provide transit services to the edge ASes
but tend to also try to freely get traffic amongst their various
connections as much as possible.

Tier-1/"core" ASes exchange traffic almost solely based on contractual
agreements and in some cases may limit traffic distribution 
on a customer<->core1<->core2<->customer basis.

In general, as you approach tier-1, you increase the amount of policy
applied for purposes of limiting route distribution.  However, each
tier may also use varying amounts of policy (and changes to path attributes)
in an attempt to influence route selection so as to encourage certain
traffic patterns.

(I probably should have avoided the tier argument since no one can really
define a "tier" even though it is somewhat implied based on the actual
meshiness of the AS-graph.  Such is the stuff that flames on NANOG are made.)

My point is really that there isn't any implicit or explicit policy in
the protocol, simply how it is used by various people.

For the purpose of this discussion, we have one globally accepted policy
knob, the NO_EXPORT (and it's kin) community that can attempt to limit
the distribution of routes beyond the adjacent AS.  This mechanism isn't
a "hard" one as it can be ignored.  There exists no common mechanism to
limit route redistribution beyond the adjacent AS although the practice
of packing an AS you don't own into the AS_PATH gives you this in some
form.

So, to support Russ, you may be authorized to originate some reachability,
but current BGP mechanisms do not allow you to explicitly authorize
a given AS to propagate your reachability nor do they permit you to
explicitly deny authorization to propagate (or receive) your reachability.

Strictly IMO, while it is a computationally feasible problem to put
these limitations into the protocol, it is operationally a nightmare.
For giggles, try to represent your explicit permit/deny policy in
something reasonably abstract like RPSL and see what happens. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Feb 2005 14:44:16 -0500

Stefan,

>>I see that Tony made the same observation, but an examination of 
>>the BGP specs does not give any indication of this constraint as 
>>part of the protocol.
>

We need an objective way for one to characterize the set of ASes to 
which an advertisement is expected to be propagated. The NO_EXPORT 
community gives an easy answer when that attribute is present. if 
this attribute is not present, is there a standard way to use other 
community attributes to convey the notion that a speaker wants a 
neighbor to limit distribution of a route? if so, then we need to 
discuss this, if not, then it may be hard to define what constitutes 
secure operation for BGP, due to a lack of sufficient 
characterization of such operation.

>Origin Verification is necessary and good, but it's not the

agreed: securing route origination is just part of the solution.

we need to define what is and is not an "authorized" advertisement, 
so that any advertisements that are not authorized can be rejected 
and thus avoid the problem you cite.  But, if we can't characterize 
what is and it not authorized, other than by saying "whatever ISPs 
agree to" then we don't have a good basis for putting into place 
mechanisms to allow ASes to detect and reject bogus advertisements.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Feb 2005 16:39:24 -0500

Bill,

>	packing) and information i send on (AS striping/packing, etc.)

the current spec recognizes the validity of adding your own AS 
multiple times, contiguously. it does not condone stripping of ASes, 
except to the extent aggregation calls for this, as defined in a 
fairly detailed way. However, the spec says essentially nothing about 
what constitutes legitimate route origination, which leaves some room 
for interpretation. until we agree upon a comprehensive description 
of what constitutes legitimate origination, we have a gap, but I 
don't think that gap allows arbitrary AS stripping, for the reason I 
cite below.

>	to my desired behviour...

the neighbor can choose to not pass on your advertisement. but, 
various chunks of text in BGP say that if you advertise a route, and 
you are not the origin AS, then  the route is supposed to reflect the 
path that UPDATEs traversed to yield the route. so, this does not 
condone arbitrary addition/deletion of ASes in a path you receive 
from neighbors.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Feb 2005 17:01:28 -0500

Jeff,

As you noted, there is not universal agreement on who is a tier N 
ISP, so none of the discussion that depends on such labels will allow 
us to derive security requirements that will have universal 
interpretation. (Still, it is helpful to have discussed the factors 
that motivate different behavior for different ASes.)

>explicitly deny authorization to propagate (or receive) your reachability.

Since I think we all agree that NO_EXPORT is a well understood way to 
express one form of an AS's intent re propagation of a route, I don't 
understand the later part of your conclusion above, i.e., expression 
of no authorization to propagate is explicit.

We may argue about what the default behavior is supposed to be when 
NO_EXPORT is not present, but that is a debate about implicit, not 
explicit, authorization.

Also, we should remember that there are various ways people deal with 
behavior that does not conform to explicit or implicit authorization.

	- sometimes we employ mechanisms designed to prevent behavior 
that is not authorized. for example, we may require a key for a lock 
on a door to prevent unauthorized access.

	- sometime we rely on the threat of detection and punishment 
to deter unauthorized behavior. law enforcement is often based on 
this model of dealing with unauthorized behavior.

	- sometimes we rely on remedial measures to punish 
unauthorized behavior. we may impose (future) preventative measures 
on an offender (incarceration of an offender or termination of a 
contract).

So, when we discuss enforcement, it is important to remember that 
there are many forms enforcement may take.

>something reasonably abstract like RPSL and see what happens. :-)

it is fair to ask whether people can manage a proposed set of 
controls. if the expression of the controls becomes too complex, 
people will make mistakes that yield vulnerabilities, or that degrade 
service. that concern is why we came to the conclusion that 
incremental deployment of BGP security should be done via contiguous 
deployment, vs. trying to link secured "islands" through unsecured 
ASes.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Feb 2005 14:48:43 -0500

Blaine,

>(including all AS's) was an autonomous system.

right. we need to accommodate the situation where there is a common 
administrative entity even though multiple AS numbers are used.

>system, if we don't know how the prefix came to us how can we be comfortable

I think we can't ignore AS numbers in a path, because route selection 
is influenced by path length. so, we have to be able to detect if a 
path has been artificially shortened to attract traffic. BGP 
explicitly allows paths to be padded in a well defined way, to convey 
the notion of a backup path, so path length seems to be important.

Steve

---

From: Stefan Mink <[email-masked]>
Date: Fri, 04 Feb 2005 00:25:31 +0100

Stephen Kent wrote:

> we need to define what is and is not an "authorized" advertisement, so 
> that any advertisements that are not authorized can be rejected and 
> thus avoid the problem you cite.  But, if we can't characterize what 
> is and it not authorized, other than by saying "whatever ISPs agree 
> to" then we don't have a good basis for putting into place mechanisms 
> to allow ASes to detect and reject bogus advertisements.

we would need the same as for origin verification: a database where
the policy between two connected ISPs is stored, which is signed
by both, so you can verify its authentic.
RPSL contains some elements, but  it does not go far enough:
it does not contain the reannouncement scope of a route, just
who gets which routes.

Tschüß
    Stefan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Feb 2005 18:41:11 -0500

>it does not contain the reannouncement scope of a route, just

verifying origin ASes can be done reliably based on the simple, tree 
structured allocation structure that is used for handing out and 
transferring prefixes. the folks who have to "sign off" are 
authoritative for the data i question.

I don't know if it is sufficient to have pairs of peers sign off on 
what their intent is re pairwise authorization to propagate routes. 
collusion between two peers, combined with a liberal interpretation 
of what constitutes legitimate route origination, might allow 
propagation of a lot of bogus routes. only if we impose stringent 
constraints on who can originate routes based on "implicit 
aggregation" might this be technically sound.

also, I've been told that some (many?) ISPs consider local policy 
data to be private and might be reluctant to share it. Or do you 
think that this more limited aspect of local policy is sufficiently 
benign to not be a concern?

Steve

---

From: Tony Tauber <[email-masked]>
Date: Thu, 3 Feb 2005 22:53:23 -0500

On Thu, 3 Feb 2005, Stephen Kent wrote:

> >Let me try phrasing it this way...  There is a consensual view of
> >reality on the Internet WRT BGP.  That view is that a certain
> >netblock is reachable as advertised by a EBGP neighbor AS.  The
> >only thing, currently, we can be absolutely sure of is that our
> >neighbor advertised a prefix and that it "looks" like it traversed
> >a set of AS's.  It is common perception that your prefix traversed
> >that set of AS's and that, if you were to have a view of the route
> >table in each AS, you would see that prefix.  In most cases that
> >view would be correct.

I'd like to some views from more operators about this bit.
Do people rely on the contents and order of the AS path for
troubleshooting (eg. calling up AS X and asking what they see in their
BGP tables?)

> >It is clear that a set of networks under common administration
> >could be considered an autonomous system without necessarily having
> >a single AS.  A common example might be my old network which used
> >many AS numbers and distributed prefixes between them.  I could say
> >that the network itself (including all AS's) was an autonomous
> >system.
>

I don't know how much we need to accomodate this situation, though we
should try to take it into account.
In my experience, (I don't know how UUnet did/does it), these ASs may
be under unified administration, but they basically have standard BGP
policy and configurations.  IIRC, I know of some now-defunct networks
that had some special policy hacks in place and I seem to recall IGP
even being allowed to leak across the boundaries.  I'd consider these
to be hacks done at the perpetrator's folly.

> I think we can't ignore AS numbers in a path, because route
> selection is influenced by path length. so, we have to be able to
> detect if a path has been artificially shortened to attract traffic.
> BGP explicitly allows paths to be padded in a well defined way, to
> convey the notion of a backup path, so path length seems to be
> important.

As above, operators need to weigh in here:

Speaking as an operator, my experience has been that not only do
ASs make decisions based on AS_PATH length, they make policy decisions
based on the _contents_ thereof and even sometimes the _order_ of
those contents.

Operators, if you're out there, please register your thoughts.

Thanks,

Tony

---

From: Tony Tauber <[email-masked]>
Date: Thu, 3 Feb 2005 23:58:45 -0500

On Thu, 3 Feb 2005, Tony Tauber wrote:

> In my experience, (I don't know how UUnet did/does it), these ASs
> may be under unified administration, but they basically have
> standard BGP policy and configurations.  IIRC, I know of some
> now-defunct networks that had some special policy hacks in place and
> I seem to recall IGP even being allowed to leak across the
> boundaries.  I'd consider these to be hacks done at the
> perpetrator's folly.

I should clarify that I had first-hand knowledge of these now-defunct
networks and it wasn't the hacks that did them in, it was the
business.  8-)

Though these hacks weren't my idea, I understand why they were done.
Sometimes there's no other way than to hack.

Tony

---

From: Stefan Mink <[email-masked]>
Date: Fri, 04 Feb 2005 08:52:01 +0100

Hi Steve,

Stephen Kent wrote:
> also, I've been told that some (many?) ISPs consider local policy data 
> to be private and might be reluctant to share it. Or do you think that 
> this more limited aspect of local policy is sufficiently benign to not 
> be a concern?

yes, thats indeed an concern and I'm looking at mechanisms to
anonymize policy data but yet make it verifyable (e.g. via
Brand certificates). On the other hand I have also learned
over time that policy is only loosely correlated to money
flows and the latter is, what providers don't want to share.
E.g. lots of big providers "peer" (i.e. exchange only customer
routes), but not settlement-free. So here, theres no commercial
difference between peering and transit. The only difference
is the readvertisement scope which per se can be verified to
a certain extend by looking at the routing table...

    tschuess
              Stefan

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Feb 2005 09:40:59 +2244

> troubleshooting (eg. calling up AS X and asking what they see in their

Not solely based on AS_PATH, but I had previously used this information
while troubleshooting routing issues as a "tier-3" network operator. :-)

The looking glasses provide a lot of the data along with your own
view of BGP to troubleshoot routing problems.  The wise network operator
will also do a lot of reliance on bidirectional traceroutes and correlation
of the "problem" place using data from the RIRs (which is hopefully
up to date) to trace the problem.  If one is lucky, the two pieces of
information correspond enough to call up the AS in question and ask
for assistance.

I've even used the contents of the AGGREGATOR field for purposes of
trying to contact an AS about a problem.  I found in that case that
the IP portion of the field was actually more reliable than the AS
portion.

Note that all of this was before 1999. :-)

> should try to take it into account.

I think the problem is tractable but will be wildly dependant on
the particular solution.

> based on the _contents_ thereof and even sometimes the _order_ of

Order can be critical.  To offer one of the examples I gave at a previous
IETF bgpsecreq meeting, the ISP I used to work for would often make policy
decisions that were roughly "Avoid this carrier-1's routes through
this connection if it is adjacent to this AS because the use of
that pipe is more costly.  Prefer these routes based on this pair of
adjacent ASes because the route goes to a critical website and is more
stable."

The lack of expressiveness in the regular expression languages for
matching AS Paths in deployed BGPs is mostly tempered by the fact
that AS_SETs are very uncommon.  If you're to the point of trying to
use an aggregate for policy purposes for shaping traffic, you're
probably doomed in the first place.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Feb 2005 09:44:06 +2245

Steve,

> benign to not be a concern?

I find it likely that most of our proposed mechanisms will have positive
benefits with regards to enforcing internal security policies.

Consider the case where ISPs A and B are operating on a bilateral 
peering arrangement; they accept each others internal routes and also
direct customer routes.  So long as the security information that makes
this valid between the two networks is entirely internal, external
parties accidentally receiving the routes are likely to drop them
since they can't be properly authenticated.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Feb 2005 09:57:36 +2245

> of no authorization to propagate is explicit.

To be clear then, you can't express your intent to "authorize or not
authorize" distribution of your routes beyond a directly adjacent
peer.  In the chain of ASes A,B,C,D A can't say to C "don't send this to D".

Some people would consider this a great feature to have.  I wont
argue that this feature is present.  I also will agree that NO_EXPORT
(and its kin) allow one to express authorization to readvertise the route
you send to a peer.  

The point I'm largely trying to make is that when network operators
are thinking about authorization to re-advertise, they may be thinking
beyond the directly adjacent peer.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Feb 2005 14:18:11 -0500

>peer.  In the chain of ASes A,B,C,D A can't say to C "don't send this to D".

yes. BGP does not provide a mechanism to express the notion of 
authorization re route propagation, beyond one's immediate neighbors.

>(and its kin) allow one to express authorization to readvertise the route

That's all I have said re this community.

>beyond the directly adjacent peer.

I don't dispute that it might be a nice capability for BGP to be able 
to express this, but I am not aware of a standard way to express 
that.  If there is one, then we need to describe it and work on 
securing BGP relative to that capability. Or, we can say that this is 
something we would like to see in a BGP extension, and we can plan on 
how to secure the capability when it is developed.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Feb 2005 14:13:31 -0500

Jeff,

I agree with your observation, but my question was addressing a 
different issue.  My question was whether the oft-cited concern over 
disclosure of local policies by ISPs would preclude sharing the data 
he suggested might need to be shared to securely represent some 
localized route propagation authorization info.

I may have misunderstood Stefan's suggestion. If one is merely 
sharing the data with neighbors, not putting it in repositories for 
more general sharing, then my question doesn't apply.

steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Feb 2005 14:25:29 -0500

Tony,

>to be hacks done at the perpetrator's folly.

All I was suggesting is that if an ISP operates multiple ASes, then 
it seems OK for the ISP to express routes that become "imprecise" 
within the set of ASes the ISP controls. This does make life more 
complex, but I think it is manageable, if folks says that it is an 
important feature.

Steve

---

From: Florian Weimer <[email-masked]>
Date: Sat, 05 Feb 2005 18:47:03 +0100

> authoritative for the data i question.

Will this work in practice?

Wouldn't it be reasonable to assume that all the cruft that ends up in
RADB today would receive a certificate in the new era?  In other
words, is it likely that we'll have route registries with strong
authentication and authorization (!) checks?  What happens to PI and
early registration space?

Of course, it's possible to postulate a tree model and work from that,
ending up with something that cryptographically prevents address space
theft (with a few assumptions).  However, I fear that the net as a
whole would be better off with some mechanisms which puts more
emphasis on detection and response (by trusted third parties or the
legitimate address space owner).

---

From: Stefan Mink <[email-masked]>
Date: Mon, 07 Feb 2005 12:32:49 +0100

> troubleshooting (eg. calling up AS X and asking what they see in their

it's one of ways you could go. Usually you deal with your direct
neighbors, but if thats not sufficient, you may have to look deeper
into the announcement path.

> based on the _contents_ thereof and even sometimes the _order_ of

I can confirm that. The order may not be that important, but
the existance of an AS is. We use that to do "BGP TE", e.g.
route all routes "behind ASX" over one specific provider,
since that one has a faster path whereas the aspath length
is identical for several providers...

    tschuess
              Stefan Mink

---

From: Stefan Mink <[email-masked]>
Date: Mon, 07 Feb 2005 12:38:43 +0100

Florian Weimer wrote:
> authentication and authorization (!) checks? 

so far registries don't care about securing inter provider
policies, because it's no registry business. All registry
aspects can be secured via RPSS and AFAIK (only) RIPE is
doing so...

In my opinion the registries would be one of the best
places to but authorization information because they
should be neutral.

    tschuess
              Stefan

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Feb 2005 22:56:36 -0500

>early registration space?

This is a fair question, but the problems are a bit different from 
what I think you are suggesting. First, security for this process is 
not the same as security for submission of data to IRRs. Second, the 
PKI is easy to check for consistency, so it should be possible to 
detect many forms of problems.  But, I agree that the legacy address 
space has to be cleaned up, something I believe ARIN is already 
working on.

>legitimate address space owner).

A remedial approach to these problems is a legitimate strategy to 
consider, but preventative measures are certainly preferable, if 
feasible. There are instances today of bogus origination 
advertisements used to hide spam. Presumably one could detect this 
after the fact, but that would not prevent the spam transmission from 
happening.

Also, unless we have a reference database for prefix allocations, 
it's hard to perform the detection well, or quickly.

Steve

---

From: Stefan Mink <[email-masked]>
Date: Tue, 08 Feb 2005 08:29:00 +0100

Stephen Kent wrote:
> feasible. There are instances today of bogus origination advertisements 
> used to hide spam. Presumably one could detect this after the fact, but 
> that would not prevent the spam transmission from happening.

I fully agree. A routing security architecture that first permits
everything and then checks for attacks is like checking for 
integrity/authenticity after you ordered products on an online-shop.
It's just too late...

I think it might be useful in the beginning to have some transition
phases where checks are being done in parallel to usage, but the final
model should check immediately and only propagate verified routing
information...

    tschuess
              Stefan Mink

---

From: Tony Tauber <[email-masked]>
Date: Tue, 8 Feb 2005 17:42:56 -0500

On Mon, 7 Feb 2005, Stephen Kent wrote:

> >Wouldn't it be reasonable to assume that all the cruft that ends up
> >in RADB today would receive a certificate in the new era?  In other
> >authentication and authorization (!) checks?  What happens to PI
> >and early registration space?
>

Just a point of clarification; there are two different types of
registries that people seem to have in mind for this function:

- The RADB (mentioned by Florian, above) is part of the IRR (Internet
  Routing Registry) the mission of which is to handle routing policy
  information.  Let's call these type of things "Routing Registries".

- The ARIN (mentioned by Steve, above) is an "RIR" (Regional Internet
  Registry).  Others in this category are RIPE, APNIC, AFRINIC, and LACNIC.
  Their authority is delegated by ICANN and IANA (might be wrong on
  some small details and don't want to get into a political discussion).
  They in turn delegate authority to LIRs (Local Internet Registries)
  and end-user organizations.  Let's call these "Numbering Registries".

My goal isn't to come to some decision or even significantly discuss
which (if either) type of entity becomes part of some future of BGP,
but just to clarify thinking points.  Feel free to correct any of what
follows (or what has preceded).

Some features of each are:

- Routing Registries are designed to hold routing information.
  If I'm not mistaken, they have a flat and variably interconnected
  topology, ie. they share and import information among themselves in
  some way [that's not clear to me.]

- Numbering Registries are designed to track IP address (and other)
  number utilization and assignment, including to prevent collisions
  in same.  They have a [fairly] defined and hierarchichal topology.

People may want to think, eventually, of what information might be
needed in a secure BGP solution.  Let's try not, however, to be
limited in our thinking based on what exists today.  Let's be
pragmatic but not overly pessimistic.

Again, feel free to clarify, correct, comment, [dis]agree, etc.

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Feb 2005 18:23:38 +2245

>   some way [that's not clear to me.]

It's a bit worse than that.

Each database can hold overlapping information with differing ownership.
RPS-Auth and RPS-Dist were intended to clarify ownership of information
and deal with distributing the information amongst the several registries.

Effectively, anyone can have their own local registry of the entire
Internet.  You can also have your information registered and take
other people's object as feeds via the various mirroring mechanisms.
However, these mirrors tend to mirror an entire database.

Things largely "work", but I suspect that certain operational practices
will need to be clarified for this to work where we expect it to
in the security infrastructure.

>   in same.  They have a [fairly] defined and hierarchichal topology.

They're also generally at the level of initial assignment to an actual
user of the address space.

Items of convenience:
o Providers like RIPE and APNIC use objects that also have significance
  as routing policy objects.
o In some cases, the RIR and the IRR are the same.  RIPE is an example of
  this.

-- 
Jeff Haas 
NextHop Technologies

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 9 Feb 2005 14:06:31 +0100

I think it worth adding a mention of AS number (alongside prefix) since without
it, you cannot generate a BGP Update message:-)  And a key part of BGP security
is authorising the relationship between originating AS number and prefix  ie I
expect any security protocol to need access to an external database that
contains information about organisational entities and their allocations of AS
number and prefix.

One issue is I haven't seen raised is whether or not BGP security should cater
for private (as opposed to public) AS numbers.  My take is not, that it is the
'public' BGP we should be securing and where private AS numbers are involved,
then that is an issue internal to the organisation(s).

A consequence of this is that if you have a public AS number, then you should be
an LIR under the current setup so that the organisational entity and the
allocation of prefix and AS number thereto is all in the 'Numbering Registry'.

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 Feb 2005 10:21:16 +2245

Tom,

> then that is an issue internal to the organisation(s).

IMO, so long as our mechanism can account for authorization to a local
registry, we should be able to use most of the same mechanisms.  I think
we've already agreed that our security mechanisms have to be able to
deal with removing private AS numbers.

(If not, we have further work to do.)

A convenient side-effect is that if you don't remove the private AS
numbers, you'll have an origin AS authentication failure and the routes
will probably get dropped.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Feb 2005 14:04:41 -0500

Tony,

>Again, feel free to clarify, correct, comment, [dis]agree, etc.

As you noted, my comment focused on RIRs (and LIRs, etc.) since they 
are responsible for allocation of prefixes and of AS numbers, the 
data items of primary, initial concern here. They form the tree 
structured, authoritative system for allocation of these data items 
and that is what I think one needs to secure first, to create a basis 
for tracking which ASes are authorized to originate which prefixes.

Steve

---

From: Stefan Mink <[email-masked]>
Date: Thu, 10 Feb 2005 09:26:31 +0100

Hi Stephen,

Stephen Kent wrote:
> As you noted, my comment focused on RIRs (and LIRs, etc.) since they are 
> responsible for allocation of prefixes and of AS numbers, the data items 
> of primary, initial concern here. They form the tree structured, 
> authoritative system for allocation of these data items and that is what 
> I think one needs to secure first, to create a basis for tracking which 
> ASes are authorized to originate which prefixes.

if all RIRs were using RPSS, the registry system would be quite
secure IMHO. It's not certificate based, but only based on the
integrity of the RIR databases, but if you don't trust them, why
would you trust any certificates (created based on the same data)? :)

    tschuess
              Stefan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 12:34:24 -0500

At 9:26 AM +0100 2/10/05, Stefan Mink wrote:
>Hi Stephen,
>
>Stephen Kent wrote:
>>As you noted, my comment focused on RIRs (and LIRs, etc.) since 
>>they are responsible for allocation of prefixes and of AS numbers, 
>>the data items of primary, initial concern here. They form the tree 
>>and that is what I think one needs to secure first, to create a 
>>basis for tracking which ASes are authorized to originate which 
>>prefixes.
>

I am not familiar with RPSS, so I cannot comment on the relative 
security of it vs. use of certs. However, as a rule of thumb, one 
achieves a greater level of security by storing signed data in a 
repository, than by trying to make the repository itself secure 
against insertion of bogus data or tampering with stored, valid data. 
Also, if one requires a repository to be distributed, there are 
substantial advantages to the use of certs and signed data, as a 
means of secure distribution of the data among multiple sites.

Thus there seem to be substantial advantages to using certs and 
additional signed data (to represent which ASes the prefix holder has 
authorized to advertise its address blocks) in this context.

Steve

---

From: Stefan Mink <[email-masked]>
Date: Thu, 10 Feb 2005 22:38:34 +0100

Stephen Kent wrote:

> security of it vs. use of certs. However, as a rule of thumb, 

this line is a little bit inconsistent ;)

> one achieves a greater level of security by storing signed data in a 

you only get a greater level of security because an attacker can not change
data on the database system without everybody noticing it. Otherwise I 
don't see
an advantage vs. fetching the data via TLS.

So this addresses system security, but not routing security.

> substantial advantages to the use of certs and signed data, as a means 
> of secure distribution of the data among multiple sites.
>

the advantage of certificates vs. fetched data out of a secure database 
is that you can forward
it to somebody else and he check its authenticity. Nevertheless this is 
already an optimization
of a solved problem. If every RIR would use RPSS and the databases would 
include legacy
space, we would have a mechanism to check for unauthorized originations. 
Otherwise
certificates couldn't solve the problem...

On the other hand the verification of readvertisements is not adressed 
by any security
architecture and is not possible today. So we should first try to find 
means to change
that instead of trying to make something better, because "verification 
of origination
authorization is just the beginning of routing security" ;-)

   tschuess
             Stefan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 16:53:46 -0500

>this line is a little bit inconsistent ;)

not much :-)

>
>>one achieves a greater level of security by storing signed data in 
>>a repository, than by trying to make the repository itself secure 
>data on the database system without everybody noticing it. Otherwise 
>I don't see

the differences are more significant. if one fetches the data via a 
TLS-protected connection, you are only authenticating the entity who 
connected, but the repository is responsible for enforcing access 
controls on who make what changes, and there are many ways this can 
go awry. If one stores signed data, and each user verifies the data 
signatures and the hierarchic delegation, then the users are 
guaranteed to detect tampering. Thus one need not rely as much on 
good security administration by the repository operators.

>So this addresses system security, but not routing security.

yes. this is a system security issue in support of routing security. 
it is an issue of how to secure the infrastructure that represents 
prefix allocation and origin AS authorization.

>>additional signed data (to represent which ASes the prefix holder 
>>has authorized to advertise its address blocks) in this context.
>
>
>the advantage of certificates vs. fetched data out of a secure 
>database is that you can forward
>it to somebody else and he check its authenticity. Nevertheless this 
>is already an optimization
>of a solved problem. If every RIR would use RPSS and the databases 
>would include legacy
>space, we would have a mechanism to check for unauthorized 
>originations. Otherwise

Let me ask a question about an analogous (though not perfectly 
analogous) system, DNS. We have developed DNSSEC, relying on 
signatures to secure DNS records, because that technology allows us 
to reduce reliance on secure management of each DNS server, and it 
allows us to distribute DNS data securely, via caching. DNS is 
analogous in that it too is a hierarchic system with clear lines of 
authorization, that makes it conceptually easy for users to retrieve 
the records, signatures, and matching keys to verify record 
authenticity. Do you see this as an optimization too?

>On the other hand the verification of readvertisements is not 
>adressed by any security
>architecture and is not possible today. So we should first try to 
>find means to change
>that instead of trying to make something better, because 
>"verification of origination

verification of advertisements is what I would like to see. I thought 
this thread of the discussion was addressing the question of how one 
could could provide a secure infrastructure to represent prefix 
allocation/delegation and subsequent authorization of an As to 
advertise itself as the origin for a prefix.

Steve

---

From: Stefan Mink <[email-masked]>
Date: Thu, 10 Feb 2005 23:50:39 +0100

Stephen Kent wrote:

> signatures to secure DNS records, because that technology allows us to 
> reduce reliance on secure management of each DNS server, and it allows 
> us to distribute DNS data securely, via caching. DNS is analogous in 
> that it too is a hierarchic system with clear lines of authorization, 
> that makes it conceptually easy for users to retrieve the records, 
> signatures, and matching keys to verify record authenticity. Do you 
> see this as an optimization too?

You are right with that one! The reason why I didn't see a difference is 
that the
whois-system of RIPE for routing data is not distributed but AFAIK in the
ARIN region it is (SWIP/RWHOIS). If you have a central authoritative 
system,
certificates don't give you a big advantage over data fetched via TLS. In a
distributed system, this gets more complex and certificates make more sense.

   tschuess
             Stefan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 11 Feb 2005 09:35:32 -0500

At 11:50 PM +0100 2/10/05, Stefan Mink wrote:
>>authorization, that makes it conceptually easy for users to 
>>retrieve the records, signatures, and matching keys to verify 
>>record authenticity. Do you see this as an optimization too?
>
>
>You are right with that one! The reason why I didn't see a 
>difference is that the
>ARIN region it is (SWIP/RWHOIS). If you have a central authoritative system,

I think that we will need to be able to distribute the data about 
prefix holders and origin AS authorization, to ensure a reasonable 
level of availability, hence my suggestion that certs and signed data 
are a preferred approach.

Steve

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 12 Feb 2005 15:53:54 +0100

<inline>
Tom Petch

----- Original Message -----
From: "Stefan Mink" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 10, 2005 10:38 PM
Subject: Re: [RPSEC] some thoughts on requirements

<snip>
> include legacy space,

There is a project, ERX (Early Registration transfer), which has been alluded to
before, to transfer central registry information from ARIN, who inherited it
from InterNIC, to RIRs. The project page (for RIPE, one of the recipients) is
http://www.ripe.net/db/erx/erx-ip/

      while the project outline is at

http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-db-erx/

(My experience is that these links work sometimes:-).

This project does go into resolving disputes about allocations ie it goes beyond
the administrative work of putting the right data in the right RIR.
(Personally, though, I do fear that  at the end of it there will still be a hard
core of items for which resolution will prove too difficult, that those who have
been doing it their way for decades will prove hard to bring into the 21st
century).

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 12 Feb 2005 15:54:50 +0100

I do see this as a discussion on implementation (or design) details rather than
requirements ie great to have - later.

ie the requirement is (something like) to have access to an external database
which securely associates AS number(s), prefix - and IMHO an organisational
entity ie it is not enough to tie AS number and prefix together, we need to tie
them into a something or someone.

Where the data comes from, how it is stored, even whether or not it currently
exists, seems to come later; assuming we reach agreement on requirements:-)

Tom Petch

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Feb 2005 10:54:51 -0500

>requirements ie great to have - later.

good point.

>them into a something or someone.

we need to articulate the motivations for each binding. for example, 
to address bogus advertisements of prefix origination, one needs 
three kinds of bindings.
	- One set represents the allocation of prefixes from 
IANA->RIR->NIR/LIR->ISP to track these allocations to organizations.
	- one set binds AS numbers to organizations. this one and the 
previous bindings might be done together, as suggested in RFC 3779.
	- one set represents authorization by a prefix holder of an 
AS to advertise the prefix as being originated by the AS (hence the 
need for the previous set of AS-to-organization) bindings

>exists, seems to come later; assuming we reach agreement on requirements:-)

the question of where the data comes from is important, to the extent 
that we have authoritative sources for this data. if one chooses to 
not take this into account, the result is more general, but it is 
also much more vulnerable to failures in "trust models."

Steve

---

From: Blaine Christian <[email-masked]>
Date: Mon, 14 Feb 2005 11:31:51 -0500

> also much more vulnerable to failures in "trust models."

All, I have been toying with language to the effect that a SHOULD (or maybe
even a MUST) is that the means of identifying authorization should be
confined to the individual routers.  In other words, as in today's model,
the routers should only require local knowledge of their current peers in
order to become a functioning part of the network.  The attempt is to avoid
issues with requiring the purchase of yet more external servers and to avoid
implementation/bringup issues.

Anyone have thoughts on that?

---

From: Russ White <[email-masked]>
Date: Mon, 14 Feb 2005 11:48:14 -0500 (Eastern Standard Time)

>> that we have authoritative sources for this data. if one chooses to not 
>> take this into account, the result is more general, but it is also much 
>> more vulnerable to failures in "trust models."
>
> All, I have been toying with language to the effect that a SHOULD (or 
> maybe even a MUST) is that the means of identifying authorization should 
> be confined to the individual routers.  In other words, as in today's 
> model, the routers should only require local knowledge of their current 
> peers in order to become a functioning part of the network.  The attempt 
> is to avoid issues with requiring the purchase of yet more external 
> servers and to avoid implementation/bringup issues.

I think you would then limit yourself to solutions that require replacing 
all the routers before you could use the security system.... And before you 
could call and entire AS "secure," every router in the AS would need to be 
replaced. I would say this is contrary to the MUSTs in the area of 
incremental deployment.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Feb 2005 12:20:53 -0500

Blaine,

I'm not quite sure how to interpret your comments above.

One interpretation is that the routers ought not need to access any 
external repositories for the data needed to verify authorization to 
originate a prefix. That seems reasonable to me, since each AS 
operator could acquire the data from repositories, process it as 
needed, and then push the results to the routers in the AS.

Is that what you had in mind? If so, then it's somewhat orthogonal to 
my comments, which address the security relevant infrastructure 
sources of the data, but not the means of internal distribution 
within an AS. One could argue that there is an overlap here, in that 
one could choose to avoid the question of whether each AS operator 
gets the data from an authoritative infrastructure, or via pairwise 
"trust" models.  But, as I noted above, if one avoids that decision, 
the results are very different in terms of the ultimate security of 
the system. So, I don't suggest ignoring this part of the question.

Steve

---

From: Blaine Christian <[email-masked]>
Date: Mon, 14 Feb 2005 12:40:03 -0500

> the system. So, I don't suggest ignoring this part of the question.

The problem that I have is that if the routers need to visit an external
repository to become part of the network then, in times of crisis, the
external repositories can become rather large single points of failures.
Initial router configuration is different than a reboot due to kernel
failure etc...

Forgetting that we might preclude certain solutions (Russ I saw your email
as well).  What SHOULD the right answer be?  I am an advocate of the network
being able to discover itself without the need to refer to external systems
(that may rely on that network to come up).

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Feb 2005 13:19:09 -0500

>Initial router configuration is different than a reboot due to kernel

Note that I suggested a model where the AS operator would push the 
authorization data to the routers, not that the routers would fetch 
it. It's it fair to day that one needs to configure a fair amount of 
data into a e-BGP router? if so, is it fair to say that when you 
bring it up you want to have a net management workstation download 
most of the data, including this sort of data?  The data in these 
repositories need not be especially quickly updated. That's what 
makes the data in them suitable for distribution via a repository. 
So, in this case, we're discussing who owns what AS numbers, who has 
been allocation which prefixes, and who has been authorized to 
originate which prefixes.  The first two bindings change fairly 
slowly, don't they? The last one represents agreements between prefix 
holders and AS operators, and also should be fairly static. This 
suggests  that a router need not have up to the minute data for this, 
right?

>(that may rely on that network to come up).

The network can discover its neighbors but e-BGP routers need to be 
loaded with policy data. This authorization data is used, like policy 
data, to help make decisions re accepting routes. So, on that light, 
it would seem reasonable to require an ability to inject the origin 
authorization data into an e-BGP router before it can operate.

Steve

---

From: Blaine Christian <[email-masked]>
Date: Tue, 15 Feb 2005 06:55:20 -0500

> data into a e-BGP router?

For each individual peer it runs somewhere around 5-10 lines.  There are, of
course, notable exceptions exist where thousand line prefix lists are
required.

>if so, is it fair to say that when you
> most of the data, including this sort of data?

When we first program the router it is usually done with scripts etc...
After that, it accretes.  We save the configurations regularly so if we have
to rebuild the router we can do so with a reasonable chance of getting it
right <grin>.

>The data in these 
> slowly, don't they?

I would agree that the EBGP peer to "prefix list" binding changes slowly, in
most cases.

>The last one represents agreements between prefix

This may be where we want to discuss more.  Let's say I have 1000 routers go
down due to a bug.  I have had this happen and, in one case, I had an
engineer do it for me.  My concern is that the scale of the system required
to recover configurations in the thousands of lines for those routers is not
really tenable (more economic than technical).  I can tell you what will
happen in todays environment.  Someone will make it an economic trade off
and that system will be large enough to bring up about 20 routers "quickly"
but when it has 1k routers all establishing sessions to download bits it
will be brought to it's knees.

Alternatively, if each router has the internal resources to bring itself up
just by talking to it's neighbors we do not have a bandwidth/cpu issue to
deal with in one location.

I would say this model is more like a grid computing/distributed computing
model where adjacent nodes manage their relationships and the "result" of
the computation between all the nodes is the "Internet"

> authorization data into an e-BGP router before it can operate.

Currently, the routers are "pre-loaded" with policy data.  If they go away
for a time they can come back without having to talk to anyone but their
neighbors.  I gather that a few folks are interested in making this a system
that requires external connectivity before BGP routing can begin.  I can
tell you that I routinely pull all bits that require anything more external
than establishing communications with neighbors from router/switch
configurations.  A key example would be FQDNs.  I have had vendors that seem
to rely on external DNS in order for their systems to discover internal
processes.  This just adds more moving parts to the system and creates
ongoing issues.  I would hate to see the same type of thing happen to BGP.

Now, I still believe the concept of authorization can work in a distributed
system.   However, it really should work in a manner that does not require
external sources to recover from outages or maintenance.

Regards,

Blaine

---

From: Russ White <[email-masked]>
Date: Tue, 15 Feb 2005 08:04:18 -0500 (Eastern Standard Time)

> Currently, the routers are "pre-loaded" with policy data.  If they go 
> away for a time they can come back without having to talk to anyone but 
> their neighbors.  I gather that a few folks are interested in making this 
> a system that requires external connectivity before BGP routing can 
> begin.  I can tell you that I routinely pull all bits that require 
> anything more external than establishing communications with neighbors 
> from router/switch configurations.  A key example would be FQDNs.  I have 
> had vendors that seem to rely on external DNS in order for their systems 
> to discover internal processes.  This just adds more moving parts to the 
> system and creates ongoing issues.  I would hate to see the same type of 
> thing happen to BGP.

What you're talking about here, though, is two different definitions of 
"external." One is external to your routing domain (outside the BGP AS), 
the other is outside the box itself. I agree that any proposed system must 
be able to reside entirely within an AS, once you have your 
certificates/etc. I don't agree that we should require it to be completely 
installed on each single box, with no outside support ever allowed for that 
box.

:-)

Russ

---

From: Blaine Christian <[email-masked]>
Date: Tue, 15 Feb 2005 08:54:22 -0500

> installed on each single box, with no outside support ever allowed for that

I understand the thought.  And I know why you would want to allow for it.  I
just think it can put us into a world of hurt if we make every router in a
1k node network go back to a single system to discover their brain.  It just
seems like it can be done better, safer, and operationally more likely to
succeed.

Is there any way we can word it such that is strongly NOT recommended to
create the need for external systems?  While leaving a miniscule amount of
hemp with which to hang folks if they really need to hang themselves?

---

From: Russ White <[email-masked]>
Date: Tue, 15 Feb 2005 09:02:28 -0500 (Eastern Standard Time)

> I understand the thought.  And I know why you would want to allow for it. 
> I just think it can put us into a world of hurt if we make every router 
> in a 1k node network go back to a single system to discover their brain. 
> It just seems like it can be done better, safer, and operationally more 
> likely to succeed.

Then you would need to plan, and distribute the workload. You don't log to 
the routers themselves, do you? :-)

> create the need for external systems?  While leaving a miniscule amount 
> of hemp with which to hang folks if they really need to hang themselves?

I would say you should strongly suggest not relying on devices outside the 
local routing domain, and that it would be nice for a security system not 
to require boxes outside the router. To a large degree, it's going to 
depend on implementation more than specification, in the real world. 
Economic tradeoffs are going to end up being more important than the 1k 
router down situation....

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2005 10:37:49 -0500

Blaine,

Thanks for the thoughtful comments on router config data sources, 
persistence, etc.

While I think about your comments here are a couple of observations:

	- I thought the focus of this discussion was purely on 
authorization re prefix origination. Are we on  the same page here? 
Just wanted to check since your message alluded to authorization data 
at the end, without qualification.

	- getting prefix authorization data from a neighbor inside an 
AS should be a viable approach, from a security standpoint. For 
example, an AS operator could download prefix authorization data from 
one or more repositories, verify the data, and processes it into a 
convenient form for the routers in the AS. Then, it could sign the 
data and push it to the routers. Each router could verify the 
signature on the package received from the NOC. This would be an 
infrequent (e.g., daily) operation, using a long term public key from 
the NOC, so it would not be computationally burdensome nor would it 
be hard to put this public key in place.  This would allow one router 
to acquire the prefix authorization  data from a neighbor and still 
be able to verify that it came from the AS operator, by checking the 
signature.  (The timeliness of the data cannot be established so 
easily if the router looses all state, but the residual vulnerability 
seems tolerable given that the source for the data is another router 
within the same AS, and that the NOC can verify the version of the 
data at a later time, through management protocols.)

Steve

---

From: Tony Tauber <[email-masked]>
Date: Tue, 15 Feb 2005 13:01:23 -0500

On Tue, 15 Feb 2005, Russ White wrote:

> >> What you're talking about here, though, is two different
> >> definitions of "external." One is external to your routing domain
> >> (outside the BGP AS), the other is outside the box itself. I
> >> agree that any proposed system must be able to reside entirely
> >> within an AS, once you have your certificates/etc. I don't agree
> >> that we should require it to be completely installed on each
> >> single box, with no outside support ever allowed for that box.
> >
> > I understand the thought.  And I know why you would want to allow
> > for it.  I just think it can put us into a world of hurt if we
> > make every router in a 1k node network go back to a single system
> > to discover their brain.  It just seems like it can be done
> > better, safer, and operationally more likely to succeed.

I don't think anyone's suggesting the router can't become useful until
it talks to some external system.  As Steve suggested, there's much
about routers which is statically configured and stored so they can
come up and become useful.  Some information changes slowly and you
could take the last checkpoint you stored on-board and start to try
and check it once you've gotten up and running.

> Then you would need to plan, and distribute the workload. You don't
> log to the routers themselves, do you? :-)
>
> > Is there any way we can word it such that is strongly NOT
> > recommended to create the need for external systems?  While
> > leaving a miniscule amount of hemp with which to hang folks if
> > they really need to hang themselves?
>
> I would say you should strongly suggest not relying on devices
> outside the local routing domain, and that it would be nice for a
> security system not to require boxes outside the router. To a large
> degree, it's going to depend on implementation more than
> specification, in the real world.  Economic tradeoffs are going to
> end up being more important than the 1k router down situation....

Agree that it might be an implementation detail.  I'll try to think up
text that describes the desire, though.

Tony