BGP Security Requirements

1
BGP Security Requirements

• IETF-69
• Chicago 2007-07-24
• Are we there yet?....
• Tony Tauber

2
Imperatives

• SIDR (Secure Inter-Domain Routing) WG
• Starts on protocol extensions in parallel
• RPSEC not charted for those
• IDR is already very busy
• RPSEC needs to provide consensus items to SIDR
• Lets review....

3
Practical Concerns

• No flag-day
• Must be able to realize benefit even without
  global deployment
• General Operational (business) model can not be
  overhauled

4
Originating AS Authorization

• Must be able to bind authorization to advertise
  some address space to a given Autonomous System
• Must be able to handle delegation/transfer of
  authority to advertise
• Must be able to follow address delegation
  practices

5
Transport Layer Protection

• Old
• Replace TCP-MD5
• GTSM is nice but more is needed
• New
• draft-behringer-bgp-session-sec-req-01.txt
• Is transport even w/in scope (since its not part
  of the BGP protocol itself)?

6
Latest Bone(s) of Contention

• Sec. 4.2 (Incremental Deployment)
• A BGP security mechanism MUST provide backward
  compatibility in the message formatting,
  transmission, and processing of routing
  information carried through a mixed security
  environment. Message formatting in a fully
  secured environment MAY be handled in a non-
  backward compatible fashion though care must be
  taken to ensure UPDATES can traverse intermediate
  routers which don't support the new format.
• In an environment where both secured and
  non-secured systems are interoperating a
  mechanism MUST exist for secured systems to
  identify whether an originator intended the
  information to be secured.

7
Latest Bone(s) of Contention

• Sec. 4.2 (Incremental Deployment)
• Consensus that support for useful, non-contiguous
  deployment is a MUST (right?)
• Traversing legacy ASes
• How to handle intervening legacy AS?
• Lets see...

8
Propagate Info Opaquely?

• MAY?
• Demonstrates that we allow it, not much else
• SHOULD?
• We would like to (though to unclear effect)
• MUST?
• Requires (but to what end?)

9
Propagate Info Opaquely? (2)

• But what if...
• It is burdensome to the legacy ASes?
• MUST it be made possible to filter it?
• RFC 4271 (BGP), Sec. 9, paragraph 2 says
• If an optional transitive attribute is
  unrecognized, the Partial bit (the third
  high-order bit) in the attribute flags octet is
  set to 1, and the attribute is retained for
  propagation to other BGP speakers.
• So?

10
To What End?

• Do users (ISPs) want to have more data of unclear
  validity so they can make their own decisions?
• Does this just open the door to more possibility
  for mis-interpretation or mis-configuration and
  put us in the worse state than today (or the same
  state with more complexity which would be
  worse)?

11
Late-breaking!!

• Sec. 7 needs revision
• The AS_PATH for specific prefixes may be
  protected in any proposed security system in four
  ways, outlined below. Special Note On the first
  two categories below, the community has reached
  consensus on the latter two (AS_PATH Feasibility
  Check and Update Transit Check), the community
  has not reached consensus.

12
Late-breaking!! (2)

• Proposed
• The AS_PATH for specific prefixes may be
  protected in any proposed security system in four
  ways, outlined below. Special Note On the latter
  two categories below (AS_PATH Feasibility Check
  and Update Transit Check), the requirement will
  be revisited in the future once more experience
  has been garnered.

13
Please weigh in
14
Thanks!