BGP Security Requirements

1
BGP Security Requirements

• Blaine Christian

2
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

3
Things this draft will address in only a
tangential fashion

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

4
Summary of Attacks

• Unauthorized announcements/withdraws
• Session DOS

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

6
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

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

8
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

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

10
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
  its authenticity.

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

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

13
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

14
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

15
Mode 2 Delegation

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

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

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

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

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

20
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 its 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

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

22
Addressing thread comments

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

23
Addressing thread comments

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

24
Addressing thread comments

• 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 wouldnt
  improving our probability of security be better
  than an incomplete deployment?

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

26
Addressing thread comments

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

27
Addressing thread comments

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

28
Addressing thread comments

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

29
Addressing thread comments

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

30
Addressing thread comments

• 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 doesnt this thread the needle?

31
Addressing thread comments

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

32
Addressing thread comments

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

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

34
Addressing thread comments

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

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

36
Addressing thread comments

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

37
Addressing thread comments

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

38
Addressing thread comments

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

39
Addressing thread comments

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

40
Addressing thread comments

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

41
Addressing thread comments

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

42
Addressing thread comments

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

43
In Summary

• Please accept this draft as a working group
  document.
• Got any questions?