Bgp Security Requirements

BGP Security Requirements

Blaine Christian

What are we trying to do?

• Provide a means to verify and assure peering relationships and prefix advertisements

• Create a method to easily transition to a more secure environment for the distribution of prefixes

• Improve upon the current security model for BGP

• BGP MUST operate

Things this draft will address in only a tangential fashion

• Guaranteed packet delivery

• Preventing man in the middle attacks on non-BGP protocols.

Summary of Attacks

• Unauthorized announcements/withdraws

• Session DOS

Incremental Deployment Requirements

• We want our cake and we want to eat it too– BGP SHOULD continue to converge at similar

speeds.– Timers, such as keepalive and hold timers,

SHOULD NOT be impacted.– The degree of security MUST be locally

configurable based on various factors such as completeness of the internal security review process.

Incremental Deployment requirements continued

– The security system SHOULD allow the operator to determine locally whether convergence is more desirable than local security.

– Unsecured routing of secured prefixes MUST be supported in order to allow a migration path for, eventually, a greater level of prefix security

Trust models

• Strict Hierarchy– This goes all the way to the numbering

authorities.– Central authority does not appear to be

palatable to operators based on the perception of centralized models as brittle.

– Significant socio-economic barriers may increase deployment time or block deployment completely.

Trust Models continued

• Web of Trust/Distributed Trust– Providers rely on the distributed nature of the

Internet to assure “cooperation”. This model functions in a similar fashion to the network today and is the most preferred by the operators.

– Model is inherently less brittle than centralized models, if done properly. Distributed systems rely on the convergence of several “secured” systems towards a certain decision.

– Allows a continuum of trust/speed of convergence/etc…

Trust Models (cont.)

• Summary: While a distributed trust mechanism is highly desirable by Internet backbone operators it is acknowledged that private networks may have differing needs. In the light of these needs the ability to shift from distributed trust model to strict hierarchy is necessary. Distributed trust MUST be supported. Strict hierarchy SHOULD be supported.

Before we go further…

• We need to define the term “Verifiable”– Verifiable, for the purpose of this draft,

indicates the ability to determine, through algorithmic means, whether a unit of information is correct.

• Now we need to define “correct” as: A unit of information that successfully passed a test of it’s authenticity.

Path Attributes and NLRI Authentication

• The originating AS MUST be verifiable through the trust model. This method MUST account for mechanisms such as summarization.

• The AS Path list MUST correspond to a verifiable list of autonomous systems

• The first element of the AS Path list MUST correspond to the locally configured AS of a peer.

• The security mechanism MUST support the change of an originating AS for a prefix within the norms for convergence times on an unsecured network.

Verification types

• At this point in time two types of verification may be offered.– Contents of the UPDATE message

SHOULD be authenticated in real time.– The RIB MAY be authenticated periodically

or in an event driven manner.

• All BGP implementations MUST use at least one of the above mechanisms.

Address Allocation

• A significant issue for security mechanisms.– Two types of delegation are noted,

apologies for the not very original naming conventions (any suggestions?).

• Mode 1 Delegation• Mode 2 Delegation

Mode 1 Delegation

• A BGP speaker/listener have agreed to reduce the number of announcements shared between them. This normally comes in the form of auto-summary etc…

Mode 2 Delegation

• An entity allocates a chunk of prefix space to another entity.

Delegation Summary

• BGP security solutions MUST support delegation of an address block of any size in Mode 1 and Mode 2.

• BGP security solutions MUST allow for the propagation of a prefix by more than one originator AS.

NLRI and Path Attribute tracking

• All good security systems have detailed logging of activity. BGP security systems should not be the exception to this rule.– A BGP security systems SHOULD provide some

method to allow the receiver of an update to verify the originator as well as the AS path of the update.

– Path/NLRI/security attributes MUST be logged off using mechanisms such as syslog/snmp traps in a standard format across all BGP speakers.

• The amount of data this generates may be quite significant depending on external factors and care should be taken not to allow the process to overwhelm.

Transport protection

• The current “MD5” based implementations DO NOT work very well.– Any proposed security mechanism MUST include

provisions for session security.– It is considered highly desirable to reuse the

infrastructure for the NLRI/Path security to accomplish session security.

– Session security as well as NLRI/Path security are considered per AS. Keys, or other infrastructure, should be provisioned on a per AS basis (note we have not explored this in the draft yet).

Addressing Thread comments

• Abstract wording: Security or Authentication?– This can be changed to just security

• Abstract wording: What does security for BGP mean?– This can be worded differently. The two

key bits are authenticating, and then authorizing, the sessions and the prefixes.

Addressing Thread comments

• Introduction Comments: Not cohesive– The introduction was rewritten pretty much

completely. I am happier with it now but it could still improve. Let me know what you think.

• Definition of Verifiable: out of place in document– I am happier with it’s place in this presentation

than the document but it is still problematic. We can probably shift it to “just” before we start using the term…

Addressing thread comments

• Incremental deployment: improving convergence speed is not likely.– That probably was not meant as humor but more to

reinforce the point. Personally, I agree that it is highly improbable that we will improve convergence speed. HOWEVER, would convergence speed, under duress, improve if we did not listen/import “bad” route adverts?

– To be clear… I agree with the point made but thought it may be interesting to identify whether convergence times would improve under deaggregation.


• Current timers: Why are these a requirement?– That is a good question. I agree that we

need backup material for comments such as this. Personally, I am more concerned with the “hidden” timer optimizations than the public ones. My perception is that all other RFC specified timers should be left alone as a matter of course.


• Mixed prefix security: Secure route/prefix needs to be defined.– Agreed… Suggested wording would be

great. Also, we need to tighten up the phrasing and keep it to the prefix level.


• Range of security outputs (locally configured security levels): This usually gets mismanaged horribly.– Agreed… However, if we approach this

from a probabilities perspective, especially if a base level of security is predefined, then wouldn’t improving our probability of security be better than an incomplete deployment?

Address thread comments

• Speed of convergence vs. security: If this is network wide then it makes no sense.– The greater amount of time is spent local

to the devices responsible for propagating information. Network wide convergence is the resultant from locally configured policies and latency.


• Trust models: Off to a bad start– Any actual text to improve this would be

greatly appreciated! I think the revised version of the draft (the 01 version) should be reviewed before further comment though. Perhaps it helps?


• BGP distributed trust model: The BGP trust model is transitive not distributed.– This is a conflict in definitions that should be easy

to resolve. If a group of entities decide to trust what they propagate internally to each other and to trust to a lesser degree any subsidiary entities it sounds distributed to me. BUT, if it clarifies things we can revise. The point, I believe, remains the same.


• The root certificate trust model: Objection to the use of SSL/TLS as an example of root authority models.– If SSL and TLS dominantly use root

certificate authorities it seems to be a valid example. Suggestions of better root certificate verbiage or models would be welcome!


• More than two types of PKI model– The two mentioned seemed the most well used.

Are more examples necessary?

• Authentication vs. Authorization data where authorization seems more pertinent to BGP– I suspect that both are actually pertinent although

we should discuss. Authorization is probably the last step in a rather lengthy process starting with authentication.


• Distributed trust: assertion as “best” model rejected– Central authority is vulnerable to many of

the same concerns and issues. Distributed systems by their very nature tend to be more reliable. If providers are given the option to make path selections based on strict hierarchy OR distributed trust doesn’t this thread the needle?


• Current transitive trust model of BGP does not work well– I have to disagree… For the most part it is

working very well. What we are working on now is the outliers. Other than that it is my perception that authentication is a good starting point towards authorization. With a protocol such as BGP should we even consider authorizing without authenticating first?


• Auth of originating AS: Verifiable definition needs improvement.– Agreed with the recommended verbiage up

to the point where the “authorization” of an AS to use a prefix came about. I can understand root “less specific” prefix owners (ISPs) distributing authority for more specifics. But do not believe this needs to go further. Thoughts anyone?

Addressing thread comments• AS_PATH must correspond: This looks like

gerrymandering and is already a subset of what the semantics of BGP imply.– Implied does not mean that folks have jointly decided

to implement in a certain way. If we verify/authenticate the path then this seems like an improvement in overall security. I, at least, could care less about whose protocol this is. It could be anything as long as it fulfills the requirements. The goal with this draft is to create a set of achievable requirements based on real world operator requirements. I think as an additional requirement it should be okay (as long as it is not the only one).


• Announcing AS check: It is not enough to verify just the announcing AS.– Agreed, it is the combination of criteria that lead to

greater security not a single criteria.

• Real time update verification: What does auth mean here?– To me it means that each update received at the

border of your AS is checked as it is received. This happens before insertion in the RIB.

Addressing thread comments• Route table may be authenticated non-

real time: What damage may result?– Very much agreed and I had trouble with it

as well. Unfortunately, systems may well be computationally unable to keep up and maintain convergence speed. Significant damage may result. Does dampening as in the current BGP process fit? Eventually pulling a bad advert/withdraw from implementation is better than nothing.


• Network transition: Do time frames need to be stated?– From the operators perspective the ability

to propagate a prefix from a completely different AS should happen at current or better speeds than currently observed. Such changes can, indeed, be instantaneous. I can cite several examples.


• Address allocation Mode 1: Does not describe allocation.– Good point. It does describe the point we

were trying to get across though. Which is that prefix summarization is accomplished between peers and should be allowed for in any newly secured implementation of BGP.


• Address Allocation: This is a very odd way of stating things.– Better verbiage is always appreciated. This

document is meant to be a collective effort and, as such, things get pieced together and can sound rather odd. Does someone want to throw out a good term besides address allocation? Mode 2 definitely fits the term but Mode 1 has trouble.


• Non-Repudiation misused.– I would be happy to pull the value

judgment out (where repudiation is not seen as achievable). Other than that does the wording fit? I am not sure I agree with the rephrased version though. It seems more clear, for the purposes of readability, to just take out the value judgment.


• No mention of logging.– The terms tracking and logging were used

interchangeably.


• Need to explain linked transport/prefix authentication– Hmmm, I thought the following paragraphs

did this. It is hard to define a term before stating what the term is. After reading draft 01 and the following paragraphs in that section does it still not make sense? Suggestions for rephrasing?


• IPSec Misspelled– Okay… IPsec it is…

• No rationale for the iBGP/eBGP session security in text. No key infrastructure mentioned beforehand.– Having been on the MD5 side of things I can tell you

that reusing the key infrastructure would be a great boon to the operators. At this point stating that using the same key infrastructure for session security seems like the right thing to do. I agree that key management needs to be captured and hope that it can be accomplished in the next draft.

In Summary

• Please accept this draft as a working group document.

• Got any questions?

Technology

Bgp Security Requirements