Subject: [RPSEC] BGP Security Requirements Document

From: Tony Tauber <[email-masked]>
Date: Mon, 1 Nov 2004 12:15:12 -0800 (PST)

If you'll recall, some months ago a Design Team was kicked-off
to tackle the problem of documenting BGP security requirements:

http://www1.ietf.org/mail-archive/web/rpsec/current/msg00808.html

That group has produced a document:

http://www1.ietf.org/internet-drafts/draft-christian-bgpsecrec-01.txt

which needs to be read and reviewed by the meeting next week (IETF61).

Remember, this document is only the output of the Design Team and
doesn't represent the last word on this topic nor does it
automatically become a Working Group document.

Please read and comment to the RPSEC list.

Thanks,

Tony

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Nov 2004 16:05:06 -0500

Here are my comments on the document. I stripped out the title, 
pagination blank lines, headers, footers, and boilerplate to make it 
easier to read with embedded comments.

Steve
-------

Abstract

    The security of BGP is critical to the continued health and well
    being of internetworking.  While securing a link between two BGP
    peers is a relatively easy technical matter, the manner in which to
    do so is not standard.  Additionally, a secure link does not provide
    security or authentication of the routes updates themselves.

The phrase "security or authentication" makes "security" sound like a service
parallel to authentication, e.g., like confidentiality, integrity, 
etc. Not sure exactly what you meant to convey via this choice of 
words.

    In this
    document, we describe a set of requirements for securing BGP is
    described, both in the areas of peering relationships and prefix
    authentication.

As above, the wording here is ambiguous, or it suggests a less than 
comprehensive view of what security for BGP means.

1.  Introduction

    Securing peering relationships and the generation/reception of
    prefixes is important to ensuring the validity of route updates.

Be more precise about what you mean by "securing peering 
relationships." For example, do you  mean that each peer verifies the 
identity of the other, or the authorization of the peer to represent 
a specified AS, or both? Call out requirements for packet-level 
security services too, e.g., connection-oriented integrity.

    The guarantee of packet delivery is not part of the BGP protocol
    security model.  Just because a packet is addressed to a specific
    peer does not mean it will be received, even with a "secure" route.

These two sentences are very confusing, with the reference to 
"guarantee of packet delivery" coming out of nowhere. Are you talking 
about forwarding of subscriber traffic, or BGP traffic?

    For example: an attacker could have compromised an intermediate
    router and installed a static route for target address A.B.C.D
    pointing to an inappropriate direction or an attacker might splice
    into a circuit between two secure routers and install a device that
    diverts A.B.C.D traffic without requiring the compromise of control
    plane devices.

This example suggests that the previous mention of a guarantee was a 
reference to forwarding. So, I suggest you just make a clear 
statement about the differences between routing and forwarding here, 
to clarify the scope of this requirement document, rather than 
relying on an example to convey this notion.

2.  Definition of Verifiable

    For the purposes of this document the word verifiable indicates the
    ability to determine through algorithmic means whether a unit of
    information is correct.

"A unit of information?" seems rather abstract at this point on the 
document, and there is no reference to what inputs the algorithm 
might use to verify correctness, so this is not a great definition. 
How about addressing what correctness means for BGP as a starting 
point? That might be a suitable starting point for a document of this 
sort, if one also decides that correctness and security for BGP are 
closely related.

3.  Incremental Deployments Requirements

    The following attributes of BGP SHOULD be preserved with a security
    mechanism in place:
    o  Convergence Speed: BGP's convergence speed, with a security system
       in operation, SHOULD be equivalent to or faster than BGP running
       without the security system in operation.  This includes the
       preservation of optimizations currently used to produce acceptable
       convergence speeds on current hardware, including update packing,
       peer groups, and others.

This is a rather dubious requirement, since we rarely, if ever, add 
security to ANY base system and make the system FASTER than it was 
previously!

    o  Current timers, including hold timers, keepalive timers, and the
       peering process, SHOULD NOT be impacted by the security system.

Why is this a requirement? Are these timers variables that cannot be 
changed. Or do we fear that if they are changed then BGP will blow 
up?  It's not enough to state requirements in a document like this; 
one needs to motivate them.

    o  BGP SHOULD support both secured and unsecured routes with the
       security system in place.

You have not defined what a secure route is, so this is a hard 
sentence to interpret.

    o  The security system MUST support a range of possible outputs for
       local determination of the trust level for a specific route.  Any
       given route should be trustable to a locally configured degree,
       based on the completeness of security information for the update
       and other factors.

Experience in the security area shows that people are very, very bad 
at managing notions of trust. In the PKI arena, for example, anything 
other than very simple models of "trust" are subject to frequent 
mismanagement, and resulting vulnerabilities. So, why do you feel 
this is an essential feature for BGP security? Don't we have lots of 
experience that suggests that the current operational model which 
exhibits just this sort of property, creates significant 
vulnerabilities?

    o  The security system SHOULD allow the operator to determine whether
       the speed of convergence is more important than security
       operations, or security operations are more important than the
       speed of convergence.  This facilitates the incremental deployment
       of security on systems not designed to support increased
       processing requirements imposed by the security system.

Is speed of convergence a purely local matter? If not, then making 
this a local parameter seems a bit odd, as described here.

    Network recovery times for secured routing as well as unsecured
    routing SHOULD work with similar speed and SHOULD perform with
    equivalent, or greater, rapidity than legacy routing methods.
    Unsecured routing of secured prefixes MUST be supported so that a mix
    of secured and unsecured routing paths will provide security for the
    prefixes that have security features applied, but will not penalize
    or preempt "normal" prefixes.

As above, the leck of definition of secured vs. unsecured routes 
makes this hard to interpret. Also, the suggestion that use of 
security will SPEED UP the basic routing function is almost absurd.

4.  Trust Models

this section is off to a bad start, since it does not describe the 
relevance of trust models to the problem, instead it dives into 
examples. Also, at this stage we have NO definition of what security 
is for BGP, yet we seem to be starting to discuss properties of 
solutions.

4.1  Trust Model Examples

    One example of a trust model is a distributed trust system.
    Inter-domain routing as implemented today is based on the concept of
    distributed trust.  There is no central authority; each AS is free to
    choose whom to trust and whom to avoid placing trust in.  This model
    is expressed through the filtering of routing information received
    from BGP peers.  Financial contracts and business arrangements play a
    large role in how an AS chooses to filter their peers.

BGP embodies a distributed decision making model for routing, but 
that is NOT a distributed trust model. The filtering described here 
represents a locally managed mechanism for enforcing business 
arrangements. But what really happens in the system today, from a 
trust management perspective, is transitive trust. The transitivity 
arise because updates nominally represent data that has been passed 
from one AS to another (modulo aggregation). So, it is not clear that 
BGP is appropriately described as being based on a distributed trust 
model, it least not from the BGP RFC. This discussion seems to 
confuse enforcement mechanisms and trust models.

    A second trust model is a hierarchical system much like how root
    certificates for SSL/TLS are distributed today.  In this model, a
    central authority controls all information.  For example, all address
    allocations are authenticated and signed by ICANN, then by a regional
    registry, then a large ISP, a small ISP, etc.  ICANN serves as the
    root of the address allocation system.  This type of trust is usually
    referred to as a strict hierarchical trust model or a chain of trust.

The discussion here is inaccurate in several respects. The SSL/TLS 
has no intrinsic trust model. Browsers making use of these protocols 
embody a model of the sort described immediately above, but this sort 
of model is not defined anywhere in SSL/TLS. Also, this text here 
suggests that there are only two types of trust models, but from a 
PKI perspective, this is not true. Finally, it is important to 
distinguish between a PKI used to convey authentication data, vs. one 
used to convey authorization data. The browser PKI model addresses 
the former (and not very well, in many respects), not the latter. The 
later seems more relevant for BGP.

4.2  Trust Model Recommendation

    While there are a number of trust models available, a distributed
    trust mechanism lends itself well to the current model used
    throughout the various networks and internetworks making up the
    public Internet and other large scale internetworks.

Since the definition of distributed trust above is not quite 
accurate, I question this assertion. Nonetheless, this paragraph 
seems to say that since the current, insecure system is based on 
transitive trust and distributed enforcement, that one should adopt 
that model as the basis for what we hope will be a more secure 
system. Certainly this is not a good argument to make.

    In the public Internet today, larger service providers trust each
    other to appropriately deploy edge based filtering mechanisms to
    protect the Internet as a whole and to protect sensitive inter-
    provider peering sessions.  These peering relationships, with their
    interprovider legal contracts and partnerships, are comparable to the
    relationships established within the PGP web of trust.

This paragraph seems to assert that the current system works well re 
transitive trust, but this is simply not true, i.e., the transitive 
trust aspect of the current model is what allows errors by one ISP, 
or a successful attack against one ISP, to adversely affect others 
ISPs that "trusted" it. Also, the allusion to contracts seems out of 
place in a technical requirements document. It's a bit like saying 
that we have laws that criminalize bank robbery, so we don't need 
good vaults. The analogy here to PGP is an obvious one, but not 
necessarily a good one. PGP was developed to authenticate e-mail 
senders and recipients. In that context there was an assumption of 
human value judgment in evaluation of certificate paths. Also, there 
was no suitable, authoritative basis for identifying e-mail users. In 
the BGP context, the relevant information is not who is whom, but 
rather whether a router is authorized to represent and AS, whether an 
AS is authorized to advertise a prefix, etc. Authorization is NOT the 
same as authentication and so the PKI analogy to PGP is generally 
inappropriate.

    The establishment of a distributed trust mechanism allows operators
    to make their own decisions about the level with which they trust
    their peers and their customers.  Operators may choose to honor, or
    create, a strict hierarchy of trust up to the level of numbering
    authority within the distributed model if so desired.

I'm not sure what this last sentence means. I'm guessing it's an 
attempt to express the notion that ISPs should be able to select 
trust anchors at various points in a PKI, which might be a hierarchic 
PKI. If so, then this needs a lot of work to express that notion 
clearly.

    A distributed trust model that allows for varying levels of trust
    based on operator input and a trust hierarchy MUST be supported.  The
    distributed trust model SHOULD allow for a strict hierarchy to root
    authorities if desired.

The discussion above does NOT substantiate this conclusion.

5.  Path Attributes and NLRI Authentication

    BGP distributes routing information across the Internet (between BGP
    speakers) using the BGP UPDATE messages.  The UPDATE message contains
    withdrawn routes, path attributes and one or more NLRIs.  For the
    remainder of this section, we will focus on Path Attributes and the
    NLRI.

    The AS_PATH for specific prefixes must be protected in any proposed
    security system in three ways:
    o  Authorization of Originating AS: For all prefixes announced in
       BGP, the originating AS MUST be verifiable through the trust model
       as the authorized announcer of the prefix.  The verification
       mechanism must account for existing BGP mechanisms such as
       summarization.

What I think you want to say here is that it must be possible to 
verify that the originating AS is authorized to advertise the prefix, 
either because the prefix was allocated to that AS or because the 
"owner" of the prefix authorized the AS to originate the prefix.  The 
definition of "verifiable" presented in section 2 does not align well 
with its use here, i.e., try substituting the definition for the word 
"verifiable" and see what happens.

    o  The AS_PATH list MUST correspond to a verifiable list of
       autonomous systems based on the peering topology of the network.

This is a subset of what the semantics of BGP imply. To make this a 
requirement, instead of the more stringent requirement that each AS 
along the path advertised a prefix to the next hop, is to abandon a 
security capability rather early in the process! This looks like 
blatant gerrymandering of a requirements document to accommodate a 
solution, i.e., soBGP.

    o  Announcing AS Check: For all BGP peers, a BGP Implementation MUST
       ensure that the first element of the AS_PATH list corresponds to
       the locally configured AS of that peer.

This seems to suggest that it is enough to verify that the UPDATE 
arrived via an interface consistent with the asserted AS number of 
the last hop. That sort of check does not ensure that the UPDATE was 
directed to the recipient, i.e., it admits mis-delivery of UPDATEs.

    Since BGP is a stateful routing protocol, the timeliness and
    freshness of reachability updates are critical for consistent routing
    state within the BGP routing system.  To this end, there MUST be a
    mechanism to ensure that changes to reachability that result in an
    explicit or implicit withdrawal of reachability (RFC1771) are
    propagated within the secured BGP routing system in a timely manner.

    Two types of verification MAY be offered for the NLRI and the
    AS_PATH:
    o  Contents of the UPDATE message SHOULD be authenticated in
       real-time as the UPDATE message is processed.

What does authentication mean here? Is that the message arrived from 
a specific router that is configured as a peer, and has not been 
tampered with, or is there more that is required?

    o  The route information base MAY be authenticated periodically or in
       an event driven manner by scanning the data and verifying the
       originating AS and the verifiability of the AS-PATH list.

This remedial approach may be OK, but there is no rationale provided 
to justify it. For example, how much damage can result from 
"periodic" scanning as opposed to realtime scanning?

    All BGP implementations that implement security MUST utilize at least
    one of the above methods for validating routing information.  Real
    time verification is preferred in order to prevent transitive
    failures based on periodic or event driven scan intervals.

Again, no analysis is presented to justify why the periodic or event 
driven approach is "good enough."

    The originating AS of a prefix may occasionally need to be changed
    either due to a re-assignment or a network transition.  Any BGP
    security mechanism MUST support the change of an originating AS for a
    prefix within normal convergence times of the internetwork.

What is a "network transition?" Also, the document needs to justify 
the time interval mandated for responding to the change of AS 
advertising a prefix. Such changes are not instantaneous, in that 
they require the sort of contractual arrangements the document 
discussed earlier, or allocation of new prefixes via an RIR or 
through an ISP, processes that require manual intervention that is 
certainly longer than convergence time.

5.1  Address Allocation

    As part of the regular operation of the Internet, addresses that are
    allocated to an organization may be advertised by a different
    organization.  Common reasons for this practice include multi-homing
    and route reduction for the purposes of resource conservation.  There
    are two modes of delegation:
    o  Mode 1 Delegation: In this mode, a BGP speaker and listener have
       chosen to restrict the amount of received prefixes for the
       listener.  The listener has chosen to honor route announcements
       sent in a summary fashion by the speaker.

The Mode 1 text above does not discuss how the addresses were 
ALLOCATED, but rather describes a mechanism that an ISP may use to 
help protect itself against bad advertisements.

    o  Mode 2 Delegation: In this mode, the address space that is being
       delegated is part of a larger allocation that is owned by an
       autonomous system.  The owner then delegates the smaller block to
       another AS for purposes of advertisement.  This mode is commonly
       observed in multi-homing.

    These two modes lead to a single common requirement: Any BGP Security
    solution MUST support delegation of an address block of any size
    regardless of its relationship to other address blocks to another
    entity via verifiable means.

This is a very odd, piecemeal characterization of a requirement re 
support for address allocation. It needs to be better expressed.

6.  NLRI and Path Attribute Tracking

    Non-repudiation of a routing update, the ability for a receiver to
    know exactly who originated and forwarded a routing update, is a
    desirable trait.  This document doesn't make any claims about the
    technical ability to actually deploy non-reputable security in
    various networks, including the public Internet, but we do believe
    non-repudiation to be an important goal.

The term non-repudiation is mis-used above. What I think you are 
trying to say is that it would be desirable for an AS to be able to 
verify that a received UPDATE accurately represents the propagation 
of advertisements for the NLRI in question, along the path asserted 
by the UPDATE (modulo aggregation). I would argue that this is 
exactly what BGP assumes when its operates on an UPDATE, and so would 
argue that this represents a basic security requirement, one that can 
be traced to the underlying protocol. Instead, the text here 
denigrates it, suggesting that is would be nice but that it does not 
seem feasible to deploy. This is a value judgment with no 
substantiation.

    Any security system SHOULD provide some method to allow the receiver
    of an UPDATE to verify that the originator actually originated the
    UPDATE, and the AS's listed in the AS_PATH actually forwarded it.

This seems to be a more precise statement of what the previous 
paragraph described, so it seems to be in conflict with that 
paragraph, since here this is a SHOULD, and above it's characterized 
as a "goal."

    The data generated by logging may be very large depending on the
    number of peers, the number of prefixes received, the authentication
    model used and routing policies.

Logging what? There has been no mention of logging anything, so this 
statement has no context!

    Path and NLRI attributes MUST be logged using a standard format.  The
    format must be scalable with the amount of data logged and the
    frequency of log generation.  The frequency of log generation should
    be controllable by the operator.  The logging mechanisms for the
    tracked information MUST be standardized across all platforms.
    Logging ability both on and off line is considered highly desirable.

It looks like some chunk of text is missing, as there was no mention 
of logging previously, no indication of where any action would be 
logged, and no discussion of what logging would accomplish re 
security. Again, no rationale is provided for this.

7.  Transport Protection

    Transport protection is an aspect of BGP routing protocol security
    and provides the potential for a linked transport/prefix
    authentication mechanism.  This section discusses transport security
    requirements for BGP and covers peering and authentication of
    peering.

Need to explain what "linked transport/prefix authentication mechanism is.

    Any proposed security mechanism MUST include provisions for
    authenticating both iBGP and eBGP peering sessions.  Examples of
    session security mechanisms include TCP-MD5 and IPSec, though
    possible security alternatives are not limited to those two.

IPsec is misspelled above. No justification for why iBGP requires 
this security feature, especially since the rest of this text never 
even mentions iBGP vs. eBGP. Again, missing rationale for this 
requirement.

    Transport protection systems SHOULD function as a component of the
    BGP routing protocol security mechanism.  This includes the use of
    the same key generation/management systems as the rest of the
    security system.

Since there has been little of no discussion of any key 
generation/management above, this seems out of place. Also, it seems 
likely to conflict with the mention of use of the TCP/MD-5 mechanism, 
since that facility, as currently implemented, makes use of manual 
key management.

---

From: Russ White <[email-masked]>
Date: Fri, 12 Nov 2004 10:04:23 -0500 (Eastern Standard Time)

> These two sentences are very confusing, with the reference to "guarantee 
> of packet delivery" coming out of nowhere. Are you talking about 
> forwarding of subscriber traffic, or BGP traffic?

I think I would reword this to:

The ability to gaurantee data (rather than control) traffic is passed 
through a specific path is not is outside the scope of this document.

> How about addressing what correctness means for BGP as a starting point? 
> That might be a suitable starting point for a document of this sort, if 
> one also decides that correctness and security for BGP are closely 
> related.

The problem is larger than what is a "correct unit of data" within the BGP 
protocol. The BGP protocol acts as part of a larger routing system, and our 
focus should really be on securing routing as a system, rather than on 
securing some set of specific "semantics of BGP," which will vary depending 
on what your view of BGP is, and how you see the routing system as a whole.

> security to ANY base system and make the system FASTER than it was 

If you think of security as primarily cryptography, this is true. However, 
there are other elements of a security system which might, actually, speed 
up the operation of a system, overall. The goal being expressed here is 
that designers of any such security system should focus on the overall 
speed of the system, and work towards solutions that, at least, don't 
impair the operation of the system as a whole, rather than simply assuming 
we can slow the system down as much as we like, so long as we "secure" it, 
by tacking cryptographic processes and signatures into the "right places."

> Experience in the security area shows that people are very, very bad at 
> managing notions of trust. In the PKI arena, for example, anything other 
> than very simple models of "trust" are subject to frequent mismanagement, 
> and resulting vulnerabilities. So, why do you feel this is an essential 
> feature for BGP security? Don't we have lots of experience that suggests 
> that the current operational model which exhibits just this sort of 
> property, creates significant vulnerabilities?

In other words, because the system is insecure today, based on the 
individual choices of operators, we really need something that overrides 
the individual choices of operators, to enforce security whether or not 
they like it. I don't tend to agree with this assessment. The origin of 
this requirement comes from the unwillingness of the community, at large, 
to have a security system forced on them that disallows their individual 
policy choices, and leaves them no room for operational or business 
differentiation.

> Is speed of convergence a purely local matter? If not, then making this a 
> local parameter seems a bit odd, as described here.

You've fallen into the convergence trap! =:-O

The problem with the word "convergence" is it can mean many things to many 
people.... It can mean when a single process on a single device learns all 
the information it needs to build the tables required for forwarding 
information to directly connected peers. It might mean the time at which a 
single device has actually built all the tables required for forwarding 
traffic to directly connected peers. It might mean the time at a specific 
set of devices have all the information needed to build the tables to 
forward packets, or perhaps when all those same devices have actually built 
their forwarding tables. And on it goes.... :-)

In the previous instances of "convergence," I think Blaine is trying to get 
at the time required for the internetwork, as a whole, to converge. Here, 
he has shifted gears, and is discussing the time it takes for a specific 
device, locally, to build the tables required to forward traffic. There 
should be something noting this shift, I think, in the doc.

> relevance of trust models to the problem, instead it dives into examples. 
> Also, at this stage we have NO definition of what security is for BGP, 
> yet we seem to be starting to discuss properties of solutions.

I agree there should be some justification for adding trust models into the 
document, and how they relate to the problem. I also agree that the 
requirements in this area need some support. I also agree with the trust 
model discussion being a part of the document.

> BGP embodies a distributed decision making model for routing, but that is 
> NOT a distributed trust model. The filtering described here represents a 
> locally managed mechanism for enforcing business arrangements. But what 
> really happens in the system today, from a trust management perspective, 
> is transitive trust. The transitivity arise because updates nominally 
> represent data that has been passed from one AS to another (modulo 
> aggregation). So, it is not clear that BGP is appropriately described as 
> being based on a distributed trust model, it least not from the BGP RFC. 
> This discussion seems to confuse enforcement mechanisms and trust models.

I actually disagree with the characterization that transient trust 
characterizes the interdomain routing system today. You could claim that 
simply because an update passes from one AS to another, the "trust" also 
passes from one AS to another. In reality, there is a component of assuming 
what your peer sends you is valid (what you would term transitive trust), 
but there are also components of distributed trust in play, as well. They 
are part of the routing system, however, and not necessarily specifically 
outlined in the routing protocol specification--which is why it's so 
important not to try to secure BGP as a bag of bits, but rather to try and 
secure the system as a whole.

It's like trying to secure the door perfectly, while ignoring those old 
rusty locks on the windows, or the huge gaping whole in the wall just next 
to the door.

> The latter seems more relevant for BGP.

I assume you mean here that a strict heirarchical trust model seems more 
relevant for BGP. I would agree only if you consider BGP a bag of bits to 
be secured, and don't worry about the system at large, how the systems 
using BGP actually operate today, and what acceptable modes of operation 
are for those systems.

> Since the definition of distributed trust above is not quite accurate, I 
> question this assertion. Nonetheless, this paragraph seems to say that 
> since the current, insecure system is based on transitive trust and 
> distributed enforcement, that one should adopt that model as the basis 
> for what we hope will be a more secure system. Certainly this is not a 
> good argument to make.

You've answered the question without stating what the question is. Is the 
question how to force current providers to secure interdomain routing, or 
is the question how do we provide tools for the current providers to secure 
interdomain routing? Your assumption is that the current system of trust 
doesn't work because the actors in the system can't be trusted (as you've 
outlined in this response, and several other times).

My assumption is there is no point in trying to force the community to 
accept something they aren't going to accept anyway. It's better to give 
the community tools that can be incrementally deployed, and won't damage 
their current business models, and then attempt to motivate them to use 
those tools (not that they aren't motivated already, actually, based on my 
discussions with various providers).

Since this is a requirements document, it seems to me to be a legitimate 
place to address specifically this question. The sense of the design team 
has been, thus far, that we should require a set of usable tools, rather 
than defining what "perfect security" would look like, based on a specific 
view of the way the world really should work.

> requirement, instead of the more stringent requirement that each AS along 
> the path advertised a prefix to the next hop, is to abandon a security 
> capability rather early in the process! This looks like blatant 
> gerrymandering of a requirements document to accommodate a solution, 
> i.e., soBGP.

Steve, you are off in rant land here, and you know it. You are trying to 
overload the AS Path in BGP, pushing in information that simply wasn't ever 
designed to be there, and isn't there today, in any known operational BGP 
system.

As for shaping the requirements to favor an existing solution, you're flat 
wrong. The requirements doc currently states the maximum you can actually 
prove, definitively, within a routing system. Since you can't prove 
"transitive authorization" within a routing system, the requirements 
document doesn't ask any given security system to prove it. It's 
unprovable, and unprovable things can't be requirements.

> This seems to suggest that it is enough to verify that the UPDATE arrived 
> via an interface consistent with the asserted AS number of the last hop. 
> That sort of check does not ensure that the UPDATE was directed to the 
> recipient, i.e., it admits mis-delivery of UPDATEs.

This is what we, in Cisco land, call "enforce first as." I always fall back 
to this terminology, because I don't know of any accepted "three word term" 
that's currently used to describe what this paragraph is stating. Without 
this check, no amount of signatures, graphs, encryption, or anything else 
will secure BGP in any meaningful way. As for accepting mis-delivery of 
updates, well, this addresses one part of the problem.

As for the second part of your statement: Would you say it's more important 
to secure the information in the routing database, or more important to 
secure how it got there? Can you secure how something gets into a database, 
and still wind up with invalid data? The update process is how information 
gets into the database. While you focus on the process whereby information 
makes it into the database, I think the design team has, rightly, focused 
on the actual validation of information in the database.

:-)

Russ

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Nov 2004 18:54:32 -0500

Russ,

<SNIP>

>>point? That might be a suitable starting point for a document of 
>>this sort, if one also decides that correctness and security for 
>>BGP are closely related.
>
>The problem is larger than what is a "correct unit of data" within 
>the BGP protocol. The BGP protocol acts as part of a larger routing 
>system, and our focus should really be on securing routing as a 
>system, rather than on securing some set of specific "semantics of 
>BGP," which will vary depending on what your view of BGP is, and how 
>you see the routing system as a whole.

I agree that one needs to keep in mind the system context in which a 
protocol operates in order to develop appropriate security 
requirement and mechanisms. But, as a rule, the IETF develops 
standards for protocols, not for systems, although there are 
exceptions to this general rule. The charter for RPSEC discusses both 
routing systems and routing protocols, but in terms of this document, 
the relevant charter item seems to be:

	- Document security analysis and requirements for specific 
routing protocols (e.g., OSPF, BGP)

I believe the stated goal for this document is developing security 
requirements for BGP, the protocol, not for inter-domain routing as a 
system. One could discuss implementation vulnerability issues in BGP, 
best practices for ISP management of routers, etc. in a system 
context. But that does not appear to be within the scope for this 
document.

>If you think of security as primarily cryptography, this is true. 
>However, there are other elements of a security system which might, 
>actually, speed up the operation of a system, overall. The goal 
>being expressed here is that designers of any such security system 
>should focus on the overall speed of the system, and work towards 
>solutions that, at least, don't impair the operation of the system 
>as a whole, rather than simply assuming we can slow the system down 
>as much as we like, so long as we "secure" it, by tacking 
>cryptographic processes and signatures into the "right places."

While cryptography is a good example of a security technology that 
tends to make a system slower, rather than faster, it is not the only 
example. In general improving the security of a protocol (or an 
application, ...) involves performing additional checks on inputs and 
on the results of processing. Such checks take more time, and thus do 
not make the protocol faster. One might argue that, in the case of 
attack, suitable security measures may help avoid computations that 
are easily detected as bogus, and thus the time spent on the security 
checks will be less than the time spent acting on bogus inputs. But, 
the text talked in more general terms, and in the more general 
context it is unlikely that added security measures will reduce or 
maintain the performance of the protocol, all else being equal.

>>Experience in the security area shows that people are very, very 
>>bad at managing notions of trust. In the PKI arena, for example, 
>>anything other than very simple models of "trust" are subject to 
>>frequent mismanagement, and resulting vulnerabilities. So, why do 
>>you feel this is an essential feature for BGP security? Don't we 
>>have lots of experience that suggests that the current operational 
>>model which exhibits just this sort of property, creates 
>>significant vulnerabilities?
>
>individual choices of operators, we really need something that 
>overrides the individual choices of operators, to enforce security 
>whether or not they like it. I don't tend to agree with this 
>assessment. The origin of this requirement comes from the 
>unwillingness of the community, at large, to have a security system 
>forced on them that disallows their individual policy choices, and 
>leaves them no room for operational or business differentiation.

You have grossly mischaracterized my comments above, and then used 
that to justify your conclusion. I made two observations:

	- First, non-trivial, "trust based" PKIs have generally 
proven to be too hard for people to manage, especially as the size of 
the grows. This is an objectively true statement, based on a fair 
amount of experience with PKIs.
	- Second, a number of errors appear in routes advertised by 
ISPs and these errors are propagated. It is very hard for operators 
to get everything "right" and keep it right on a continuing basis. 
Transitive trust models allow for propagation of errors, and thus are 
intrinsically vulnerable.

We both agree that individual operators should be free to operate 
autonomously; after all, we call these ASes for a reason. I have 
never suggested that local policies are anything other than locally 
managed. But, that does not mean that we ought not make available 
data from authoritative sources, e.g., for address and AS number 
assignment, to enable operators (who choose to make use of such data) 
to avoid being victimized by the error of other operators, as happens 
today. Availability of such data in no way impinges on the ability of 
an operator to control the local routing policies that he manages 
today. It merely enables an operator to determine whether other 
operators are representing path attributes in a fashion that is 
independently verifiable. A serious vulnerability of today's system 
is the lack of securely available, authoritative data that operators 
can use to evaluate UPDATEs.

Does your last comment suggest that emitting bogus routes is a good 
means of business differentiation for an ISP :-)

>The problem with the word "convergence" is it can mean many things 
>to many people.... It can mean when a single process on a single 
>device learns all the information it needs to build the tables 
>required for forwarding information to directly connected peers. It 
>might mean the time at which a single device has actually built all 
>the tables required for forwarding traffic to directly connected 
>peers. It might mean the time at a specific set of devices have all 
>the information needed to build the tables to forward packets, or 
>perhaps when all those same devices have actually built their 
>forwarding tables. And on it goes.... :-)
>
>In the previous instances of "convergence," I think Blaine is trying 
>to get at the time required for the internetwork, as a whole, to 
>converge. Here, he has shifted gears, and is discussing the time it 
>takes for a specific device, locally, to build the tables required 
>to forward traffic. There should be something noting this shift, I 
>think, in the doc.

yes, one can look at convergence times in local or global contexts, 
and the text here is either ambiguous or inconsistent with the 
previous uses of the term in the document. so, the document needs to 
be fixed to avoid this apparent contradiction.

<SNIP>

>>from one AS to another (modulo aggregation). So, it is not clear 
>>that BGP is appropriately described as being based on a distributed 
>>trust model, it least not from the BGP RFC. This discussion seems 
>>to confuse enforcement mechanisms and trust models.
>
>characterizes the interdomain routing system today. You could claim 
>that simply because an update passes from one AS to another, the 
>"trust" also passes from one AS to another. In reality, there is a 
>component of assuming what your peer sends you is valid (what you 
>would term transitive trust), but there are also components of 
>distributed trust in play, as well. They are part of the routing 
>system, however, and not necessarily specifically outlined in the 
>routing protocol specification--which is why it's so important not 
>to try to secure BGP as a bag of bits, but rather to try and secure 
>the system as a whole.

We seem to agree that when on AS accepts an UPDATE from another AS 
and assumes that the route represented in the UPDATE is valid, that 
constitutes an example of transitive trust. Yes, it is possible for 
external, extra-protocol measures to be used to help reject bogus 
routes. But, if these system (vs. protocol) measures are based on 
what you call distributed trust, and if that distributed trust is 
vulnerable to the sorts of operator errors we see today, then the 
resulting system is intrinsically vulnerable, which is what we have 
today. Presumably, we are working on requirements that will improve 
BGP security, from both a protocol and system perspective.

>It's like trying to secure the door perfectly, while ignoring those 
>old rusty locks on the windows, or the huge gaping whole in the wall 
>just next to the door.

I think we agree that one needs to adopt a balanced approach to 
security, an approach that takes into account the implications of a 
"weakest link." But, we also have to be careful to not propose 
solutions that are intrinsically limited in the security they can 
achieve based on their reliance on any given facet of the solution. 
Foe example, we understand that if one insists on using passwords for 
user authentication the result will be a system with limited 
security, no matter how well we manage the passwords. If, on the 
other hand, we adopt a crypto-based approach to user authentication, 
we can improve the elements of the system to be more secure, even as 
the threat changes. Use of crypto does not ensure that user 
authentication will be more secure, but it allows that to be true.

>I assume you mean here that a strict heirarchical trust model seems 
>more relevant for BGP. I would agree only if you consider BGP a bag 
>of bits to be secured, and don't worry about the system at large, 
>how the systems using BGP actually operate today, and what 
>acceptable modes of operation are for those systems.

BGP is a protocol. As such it embodies syntax (your allusion to a 
"bag of bits") and a state machine. The semantics of BGP arise form 
analysis of the state machine, in the system context of inter-domain 
routing. I get the feeling that when you allude to "system" you mean 
a much broader set of things, some of which may be more like the 
procedures that one might document in a BCP, but not a standards 
track RFC for a protocol. I think the charter of this task for this 
WG, and the focus of this document is the former, not the latter.

>You've answered the question without stating what the question is. 
>Is the question how to force current providers to secure interdomain 
>routing, or is the question how do we provide tools for the current 
>providers to secure interdomain routing? Your assumption is that the 
>current system of trust doesn't work because the actors in the 
>system can't be trusted (as you've outlined in this response, and 
>several other times).

I didn't answer a question above; I said that there are flaws in the 
definitions and in the reasoning in the text, and these flaws 
undermine the asserted conclusion. You are the one stating a question 
above, a question that may be appropriate somewhere, but not at this 
point in the document.

Again you have grossly msicharacterized what I said. I noted that 
transitive trust models are inherently vulnerable and the way BGP 
operates reflects a transitive trust model, in most respects. I 
didn't say that the ISPs "can't be trusted."  However, any system 
which relies on transitive trust makes the parties vulnerable to 
errors made by "trusted" parties and to successful attacks against 
those parties.

>My assumption is there is no point in trying to force the community 
>to accept something they aren't going to accept anyway. It's better 
>to give the community tools that can be incrementally deployed, and 
>won't damage their current business models, and then attempt to 
>motivate them to use those tools (not that they aren't motivated 
>already, actually, based on my discussions with various providers).

Your paragraph starts with a tautology, which limits its utility in 
this discussion. Not only have you decided what is and is not 
acceptable to the community, but you have also decided what potential 
solutions fall into which categories. That suggests that you really 
want this requirements document to reinforce your pre-existing 
notions of what constitutes an acceptable solution, rather than it 
acting as a legitimate analysis of security requirements for BGP.

>Since this is a requirements document, it seems to me to be a 
>legitimate place to address specifically this question. The sense of 
>the design team has been, thus far, that we should require a set of 
>usable tools, rather than defining what "perfect security" would 
>look like, based on a specific view of the way the world really 
>should work.

This text is begging the question, and thus is not a useful 
contribution to this discussion.

>Steve, you are off in rant land here, and you know it. You are 
>trying to overload the AS Path in BGP, pushing in information that 
>simply wasn't ever designed to be there, and isn't there today, in 
>any known operational BGP system.

If you want to criticize my comment, the professional way is to 
explain how the protocol spec differs from what I asserted, rather to 
rail at me and offer no supporting evidence.

>As for shaping the requirements to favor an existing solution, 
>you're flat wrong. The requirements doc currently states the maximum 
>you can actually prove, definitively, within a routing system. Since 
>you can't prove "transitive authorization" within a routing system, 
>the requirements document doesn't ask any given security system to 
>prove it. It's unprovable, and unprovable things can't be 
>requirements.

You've gone off the deep end here, Russ. I don't recall any 
references to what one can "prove" in the document, or any mention by 
me above of "transitive authorization." I think you should restrict 
your comments to the text in the draft, and my comments on the draft.

>>the last hop. That sort of check does not ensure that the UPDATE 
>>was directed to the recipient, i.e., it admits mis-delivery of 
>>UPDATEs.
>
>This is what we, in Cisco land, call "enforce first as." I always 
>fall back to this terminology, because I don't know of any accepted 
>"three word term" that's currently used to describe what this 
>paragraph is stating. Without this check, no amount of signatures, 
>graphs, encryption, or anything else will secure BGP in any 
>meaningful way. As for accepting mis-delivery of updates, well, this 
>addresses one part of the problem.

Russ, try to pay attention to what I say, not what you think I might 
mean.  What I pointed out is that the check described above is not 
sufficient, as worded. In a requirements document one should be 
articulating the essence of what needs to be verified, and explaining 
why. This bullet fails to do so. My comment did not say what checks 
need to be done, but I did provide suggested text in a private 
message to John Scudder, in response to a query from him:

	- very that the Update is received via an authenticated and 
integrity-secure channel associated with a configured peer

	- verify that the first AS number appearing in the Update is 
that of the peer associated with the secure channel

The wording of the bullet is imprecise, and the phrase "enforce first 
as" is equally poor, as it fails to articulate the need to establish 
the authenticity of the source and the integrity of the communication 
path.

>As for the second part of your statement: Would you say it's more 
>important to secure the information in the routing database, or more 
>important to secure how it got there? Can you secure how something 
>gets into a database, and still wind up with invalid data? The 
>update process is how information gets into the database. While you 
>focus on the process whereby information makes it into the database, 
>I think the design team has, rightly, focused on the actual 
>validation of information in the database.

Russ, have you stopped beating your wife? That question is about as 
well formed as the one you pose above.

First, it is not clear what it would mean to "secure the information 
in the routing database." I assume what you really mean is to ensure 
that the data in the routing database is accurate, since accurate 
data is what one wants in order for BGP to work properly. Also, you 
say that the "update process is how information gets into the 
database" but this ignores static route entries, and the influence of 
local policies on what inputs are accepted from which peers.

Anyway, I think we agree that the goal is to try to work toward 
ensuring the accuracy of the routes that are accepted into the 
routing database. I do tend to focus on ways to allow an AS to verify 
that data received via UPDATEs is accurate, and thus to avoid being 
mislead in case an AS has made an error or has been attacked and is 
emitting "bogus" UPDATEs. You suggest that it is sufficient to verify 
that the database is accurate, irrespective of how the data in it has 
arrived. That is a legitimate strategy, but you emphasize "actual 
validation of the information in the database." This suggests use of 
some sort of oracle, that can tell an AS whether the data in its 
database is accurate. Oracles are popular notions in academic 
analyses of protocols, but in the real world we have few oracles. In 
the BGP context, we have no oracles that provide up to date info 
about the accuracy of routes. To do so would require omniscience. 
Only if one relaxes the definition of what constitutes accurate 
(valid) routes, might one be able to provide the sort of oracle you 
allude to indirectly. Specifically, one must be willing to ask "could 
the ASes along this path have announced this route based on published 
policy info," as opposed to  "have the ASes along this path announced 
this route. "  BGP operates based on the latter assumption, and has 
no concept of the former in its standard definition.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 15 Nov 2004 19:59:34 -0500 (Eastern Standard Time)

>> The problem is larger than what is a "correct unit of data" within the 
>> BGP protocol. The BGP protocol acts as part of a larger routing system, 
>> and our focus should really be on securing routing as a system, rather 
>> than on securing some set of specific "semantics of BGP," which will 
>> vary depending on what your view of BGP is, and how you see the routing 
>> system as a whole.
>
> protocol operates in order to develop appropriate security requirement 
> and mechanisms. But, as a rule, the IETF develops standards for 
> protocols, not for systems, although there are exceptions to this general 
> rule. The charter for RPSEC discusses both routing systems and routing 
> protocols, but in terms of this document, the relevant charter item seems 
> to be:
>
> 	- Document security analysis and requirements for specific routing 
> protocols (e.g., OSPF, BGP)
>
> best practices for ISP management of routers, etc. in a system context. 
> But that does not appear to be within the scope for this document.

In other words, you're unwilling to consider anything outside what you 
define to be "the semantics of BGP," as you've defined them, to be a valid 
discussion point. You've framed the argument around your definition, BGP as 
a bag of bits, and with the semantics you believe to be in the protocol 
spec (ignoring other's interpretations of that same specification), and you 
refuse to contemplate that there may be other, differing views, on what 
needs to be secured, what true requirements are, etc.

Within that definition, you have the perfect answer, and no-one else can 
argue with you. I'm sorry if I find your stance unhelpful.

>> actually, speed up the operation of a system, overall. The goal being 
>> expressed here is that designers of any such security system should 
>> focus on the overall speed of the system, and work towards solutions 
>> that, at least, don't impair the operation of the system as a whole, 
>> rather than simply assuming we can slow the system down as much as we 
>> like, so long as we "secure" it, by tacking cryptographic processes and 
>> signatures into the "right places."
>
> While cryptography is a good example of a security technology that tends 
> to make a system slower, rather than faster, it is not the only example. 
> In general improving the security of a protocol (or an application, ...) 
> involves performing additional checks on inputs and on the results of 
> processing. Such checks take more time, and thus do not make the protocol 
> faster. One might argue that, in the case of attack, suitable security 
> measures may help avoid computations that are easily detected as bogus, 
> and thus the time spent on the security checks will be less than the time 
> spent acting on bogus inputs. But, the text talked in more general terms, 
> and in the more general context it is unlikely that added security 
> measures will reduce or maintain the performance of the protocol, all 
> else being equal.

And, I don't agree. There are elements here that could easily help BGP's 
convergence speed, since the points at which BGP's convergence speed and 
BGP's security are weak probably overlap in many places. Rather than 
exploring those opportunities, you would like to force any possible system 
design into your box, and your definitions.

> You have grossly mischaracterized my comments above, and then used that to 
> justify your conclusion. I made two observations:
>
> 	- First, non-trivial, "trust based" PKIs have generally proven to 
> be too hard for people to manage, especially as the size of the grows. 
> This is an objectively true statement, based on a fair amount of 
> experience with PKIs.

> 	- Second, a number of errors appear in routes advertised by ISPs 
> and these errors are propagated. It is very hard for operators to get 
> everything "right" and keep it right on a continuing basis. Transitive 
> trust models allow for propagation of errors, and thus are intrinsically 
> vulnerable.
>
> autonomously; after all, we call these ASes for a reason. I have never 
> suggested that local policies are anything other than locally managed. 
> But, that does not mean that we ought not make available data from 
> authoritative sources, e.g., for address and AS number assignment, to 
> enable operators (who choose to make use of such data) to avoid being 
> victimized by the error of other operators, as happens today. 
> Availability of such data in no way impinges on the ability of an 
> operator to control the local routing policies that he manages today. It 
> merely enables an operator to determine whether other operators are 
> representing path attributes in a fashion that is independently 
> verifiable. A serious vulnerability of today's system is the lack of 
> securely available, authoritative data that operators can use to evaluate 
> UPDATEs.

First, you're again assuming that the attributes within an update are 
what's important to secure. The important thing to secure is what's in the 
database, not what's in the update. Again, you're assuming you have the 
only version of the right question, and assuming, therefore, that your 
answer is the only possible right answer.

> Does your last comment suggest that emitting bogus routes is a good means 
> of business differentiation for an ISP :-)

*sigh*

The problem is basically definitions. Unless we can agree on what, exactly, 
needs to be secured here (the bag of bits in a BGP update, or the 
information in the routing database), we aren't ever going to agree on 
what's a requirement, or what's an acceptable set of options.

> I think we agree that one needs to adopt a balanced approach to security, 
> an approach that takes into account the implications of a "weakest link." 
> But, we also have to be careful to not propose solutions that are 
> intrinsically limited in the security they can achieve based on their 
> reliance on any given facet of the solution.

Yes, exactly. You cannot prove transitive authorization to advertise 
something without outright banning aggregation and filtering in a routing 
system. You can secure anything in the way of updates all you want, but 
you aren't going to get around that.

So, let's focus on what actually _can_ be secured in routing, BGP 
specifically. Since you can't prove transitive authorization to advertise, 
then you can't require it in a requirements document.

> If you want to criticize my comment, the professional way is to explain 
> how the protocol spec differs from what I asserted, rather to rail at me 
> and offer no supporting evidence.

First, your comment is unprofessional because you are accusing the 
technical design team of doing something it has _explicitely_ not 
done--design the requirements to fit one specific solution currently 
available.

Second, your comment states that the requirements document should not give 
up "possibly stronger security" based on a specific belief in the way BGP 
works, based on your definition of the solution space. In other words, you 
state that BGP updates imply transitive authorization to readvertise. I 
countered this with the comment that the type of security you state the 
requirements document is "giving up" doesn't exist--it's not provable.

I've countered this in multiple forums, multiple times. I don't really want 
to rehash the whole thing here, but I've never seen anyone prove that 
transitive authority to advertise a specific address space, in a deployment 
where filtering and aggregation are allowed, exists. In other words, just 
because my peer advertises 10.1.0.0/16 to me, doesn't imply that I'm 
authorized to advertise every possible address within the /16 block to my 
peers as reachable through me.

And that is precisely what you are trying to overload onto the BGP update 
process--that if I receive an update for 10.1.0.0/16, I'm authorized to 
advertise every possible address within the block.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Mon, 15 Nov 2004 22:20:41 -0500 (Eastern Standard Time)

> gerrymandering of a requirements document to accommodate a solution, 

I was thinking about this entire argument some more, and decided to make 
one point: The design team, in a set of long an protected discussions, came 
to the rough concensus, I believe, that while you can ask to verify a path 
within BGP exists, you cannot ask to prove authorization to readvertise a 
specific prefix. I could be wrong on this point, but I believe that is 
what's in the document because such a rough consensus existed within the 
design team at the time of the document writing.

You claim that you _can_ prove transitive authorization to advertise 
something, and I believe I can provide an example where this simply isn't 
true. To wit:

+----B---+
|    |   |
A    |   C
|    |   |
+----D---+

-- D owns 10.1.0.0/16.
-- D suballocates 10.1.1.0/24 to A. D can provide a certificate proving 
this suballocation to any and all interested parties in the network--this, 
we can all agree on.
-- A determines it would like to advertise 10.1.1.0/24 to D and B, but 
would not like B to readvertise 10.1.1.0/24 to C. A therefore marks, in 
some way, it's route to B so B cannot readvertise 10.1.1.0/24. We don't 
care how this marking works, just so long as we assume such a marking 
exists, and B will always honor this marking.
-- D continues to advertise 10.1.0.0/16 to B.
-- B continues to adveritse 10.1.0.0/16 to C

Now, a series of questions:

-- Does 10.1.0.0/16 contain 10.1.1.0/24? I assume the answer is yes.

-- Does B, in fact, "gain authorization" to advertise 10.1.1.0/24 as a part 
of "gaining authorization" to advertise 10.1.0.0/16? Yes.

-- Can A, then, prevent B from advertising 10.1.1.0/24? No, as long as we 
agree that 10.1.1.0/24 is a part of 10.1.0.0/16.

In what sense, then, is A "given" the address space 10.1.1.0/24? D is still 
advertising it, without A's consent, correct? Either we must specify that D 
can no longer advertise address space it has suballocated (in other words, 
there can be no overlapping advertisements in the protocol), or the concept 
of "ownership" in this case is looser than we are expecting. In fact, the 
concept of "ownership" of address space, in this context, prevents A from 
ever controlling where address space it "owns" is avertised.

A cannot prevent its address space from being advertised to anyone on the 
internetwork, thus A cannot, in any meaningful sense, be said to "authorize 
the readvertisement" of its address space. If I can't prevent something 
from happening, then it's hard to say how I can authorize it, IMHO. Either 
I can control it, or I can't. Either I can withold the car keys and prevent 
my kids from driving the car, or I can't. If the kids have their own copies 
of the keys to my wife's car, and permanent permission to drive it anyplace 
they like anytime they like, then I don't have any meaningful control over 
the situation, most likely.

If you can find some hole in the logic, other than asserting that A 
shouldn't have such a policy, or that it all works without aggregation, and 
we can't expect the aggregation case to work anyway, then I would like to 
hear it. I don't know of any holes in this example, and it's a small, 
uncomplicated example.

The problem isn't just in BGP, it's in the concept of address 
ownership--which, while not outlined specifically in the BGP specification, 
the idea of overlapping addresses with suballocation without "complete 
ownership transfer" is embedded in the document as an environmental 
assumption. The protocol is built, to some degree, around this assumption, 
and is designed to accomidate it through aggregation.

Thus, if you try to secure BGP by focussing on BGP updates, you can miss 
the forest for the trees. I think the design team did a good job of 
focusing on the forest. I do believe the document needs more justification, 
and background, but I also believe the final requirements listed are 
realistic, in most places, and possible within the technical realm. There 
are some tongue in cheek things in there, but I don't believe those are out 
of place, in general, to get the point across that the team was trying to 
make.

:-)

Russ