BGP Countermeasures Update
(Secure-BGP)
BBN Technologies
Stephen Kent, Charles Lynn, Luis Sanchez,
Martha Steenstrup, Joanne Mikkelson, Karen Seo
CLynn@BBN.Com
Outline
------------------------------------------------------------------------
@ Brief review of presentation at last meeting
- See http://www.ir.bbn.com/projects/s-bgp/s-bgp-briefing/index.html
@ Problem Statement
@ Constraints
@ Correct Operation of BGP
@ Goals
@ Design Overview
@ Issues to Evaluate
@ Verification of Operation and Performance
The Problem
------------------------------------------------------------------------
@ The Border Gateway Protocol (BGP) is vulnerable to attacks due to
the lack of a scalable means of ensuring the authenticity and
legitimacy of BGP control traffic:
- no means of establishing the authority of an Autonomous System
(AS) or BGP speaker to advertise a portion of address space (NLRI
origin verification)
- no means of establishing the authority of an Autonomous System
(AS) or BGP speaker to advertise routes to a destination or
destinations (AS_PATH validation) }
- need for peer authentication and ensuring of UPDATE integrity in
conjunction with automated key management and anti-replay
protection
Constraints
------------------------------------------------------------------------
@ BGP implementations and Protocol Limitations
@ Dynamic
@ Current and projected usage
- Multi-Protocol, Communities, etc.
@ Scalable
@ Deployable
@ Mechanisms cannot depend on correct operation of global routing
@ Leverage of off existing infrastructure
Correct Operation of BGP
------------------------------------------------------------------------
@ Each UPDATE is intact, sent by the indicated sender, and is intended
for indicated receiver
@ Neighbor that sent the UPDATE was authorized to act on behalf of its
AS to advertise the routing information in the UPDATE to the BGP
speakers in the recipient AS
@ Neighbor withdrawing a route is the advertiser for that route
@ AS that generated the initial UPDATE is authorized by the
Organization that owns the address space in the NLRI to represent
the address space
Correct Operation of BGP (nice, but ...)
------------------------------------------------------------------------
@ Neighbor that sent the UPDATE, correctly applied BGP rules, local
policies, etc.
@ BGP speaker that received the UPDATE, correctly applied BGP rules,
local policies, etc.
@ Subscriber traffic forwarded by a BGP speaker is valid (not spoofed,
duplicated, etc.)
We can't enforce these aspects of correct operation because BGP
affords speakers considerable latitude with regard to local policy,
ASes do not tend to make public their local policies, and because
validation and tracking of subscriber traffic is impractical
@ Used to verify authorization to "advertise" a block of addresses
@ PKI hierarchy used to verify ownership of an address block
@ Parallels current address allocation mechanism
@ Owner of address block issues a signed Address Attestation that
specifies the ASes that are authorized to advertise the address block
Goals of these Countermeasures
------------------------------------------------------------------------
@ A scalable, deployable system that ensures
- integrity, authenticity, and partial sequence integrity for each
BGP routing UPDATE
- authorized forwarding of the UPDATE
- authorization of the initial speaker to advertise the address
space embodied in the UPDATE
@ Minimize the adverse effects of compromise of any BGP speaker, BGP
management system, or portion of the proposed security
infrastructure
Design Overview
------------------------------------------------------------------------
@ IPsec --> authenticity and integrity of peer-to-peer communication
@ Public Key Infrastructures (PKIs) --> secure identification of BGP
speakers and of owners of ASes and of address blocks
@ Attestations --> authorization of the subject (by the issuer) to
advertise the specified address blocks
@ Validation of UPDATEs using certificates and attestations
@ Distribution of countermeasures information --> certificates, CRLs,
attestations
Attestations -- Overview
------------------------------------------------------------------------
@ Each UPDATE includes one or more "address" attestations and a set of
"route" attestations
@ These are carried in a new, optional, transitive path attribute
@ They are used by BGP speakers to validate the destination address
blocks and the full end-to-end path (AS_PATH) information in the
UPDATE
Encoding of Attestations
------------------------------------------------------------------------
+------+-----------------+----------+------------+
UPDATE | BGP |Addr Pref of Rtes| Path | Dest. Addr |
|Header| Being Withdrawn |Attributes|Pref. (NLRI)|
+------+-----------------+----------+------------+
_____________| |________
| |
+---------+---------------+
Path Attribute |Attribute|Route + Address|
for Attestations | Header | Attestations |
+---------+---------------+
_______________________________| |__________
| |
Attestation: +-----------+------+-------+------+------------+
Route or |Attestation|Issuer|Cert ID|Signed|Algorithm ID|
Address | Header | | | Info | & Signature|
+-----------+------+-------+------+------------+
__________| |_________
| |
+-------+----+-------+------+
Signed Info |Subject|Exp |AS Path| NLRI |
| |Date| Info *|Info *|
+-------+----+-------+------+
* explicit in the aggregation case
Address Attestation
------------------------------------------------------------------------
@ Indicates that the final AS listed in the UPDATE is authorized by
the owner of those address blocks to advertise the address blocks
(NLRI) in the UPDATE
@ Includes identification of:
- owner's certificate
- AS to be advertising the address blocks
- address blocks
- expiration date
@ Digitally signed by owner of the address blocks, traceable up to the
IANA via certificate chain
@ Used to protect BGP from erroneous UPDATEs (authenticated but
misbehaving or misconfigured BGP speakers)
Route Attestation
------------------------------------------------------------------------
@ Indicates that the speaker or its AS authorizes the listener's AS
to use the route in the UPDATE
@ Includes identification of:
- AS's or BGP speaker's certificate issued by the owner of the AS
- the address blocks and the list of ASes in the UPDATE
- the neighbor
- expiration date
@ Digitally signed by owner of the AS (or BGP speaker) distributing
the UPDATE, traceable to the IANA ...
@ Used to protect BGP from erroneous UPDATEs (authenticated but
misbehaving or misconfigured BGP speakers)
Format of Route Attestation (RA)
+-------+-------+---------------+-+-------------+---------------+
RA |1 0 0 0| Attes Len |A| Id # ? |
+-------+-------+---------------+-+-------------+---------------+
Signer |0 0 0 1| Len = 4 or 6 | AF/Type = AS or IPv4 |
+-------+-------+---------------+---------------+---------------+
| Sending AS Num or Speaker IPv4 Router Id |
+-------+-------+---------------+---------------+---------------+
Sig |0 0 1 0| Len = 48 | Sig Alg Id = DSA |
+-------+-------+---------------+---------------+---------------+
| Actual Data Length Signed | Key Hash |Coverage Len =2|
+---------------+---------------+---------------+---------------+
Coverage|1 0 1 0 0 0 0 0 C 0 0 0 0 0 0 0| [Note bit "0" used for NLRI]
+---------------+---------------+---------------+---------------+
| |
+--- ---+
| |
+--- ---+
| |
+--- ---+
| |
+--- ---+
| 40 DSA |
+--- ---+
| Signature Bytes |
+--- ---+
| |
+--- ---+
| |
+--- ---+
| |
+--- ---+
| |
+-------+-------+-------+-------+---------+-----+---+-----------+ -----
NVB |0 0 1 1| Len |YearB:4|Month:4| Day:5 | Hour:5 | Minute:6 | ^
+-------+-------+-------+-------+---------+-----+---+-----------+ |
NVA | Year:12 |Month:4| Day:5 | Hour:5 | Minute:6 | |
+-------+-------+-------+-------+---------+-----+---+-----------+ |
Subj |0 1 0 0| Len = 4 | AF/Type = AS | Signed
+-------+-------+---------------+---------------+---------------+ |
| Receiving AS Num | :
+---------------+---------------+ :
(Implicit Data Header, Covered Attributes and NLRI are signed) v
----
Some explicit data case:
+-------+-------+---------------+---------------+---------------+ |
Explicit|0 1 0 1| Len (here) = 11 |O T | Community = 8 | :
+-------+-------+---------------+---------------+---------------+ :
| 8 | Sending AS | No ... | Signed
+---------------+---------------+---------------+---------------+ :
| ... Advertise | Other AS | 12 ... | :
+---------------+---------------+---------------+---------------+ :
| ... 34 |[If NLRI: T, 0, len, AF IPv4/IPv6, SAFI, NLRI] : :
+---------------+ :
(Other Implicit Covered Attributes and NLRI are signed, in order) v
----
Issues to Evaluate
------------------------------------------------------------------------
@ Functionality
- Prefixes moving between NLRI and MP-Reachable
- Transitive Attributes, e.g., Communities
@ Performance
- Cold start of router & verification policies
@ Robustness
- Appearance of new ASes and prefixes
- Access to certificate & Address Attestation servers
@ Deployment
- Transition policies for incomplete deployment
Verification of Operation and Performance
------------------------------------------------------------------------
@ Use the wide-area CAIRN testbed
- PC-based routers running FreeBSD/mrtd/gated
@ Partition into several Autonomous Systems
- Both external and internal peering sessions
@ Some S-BGP Speakers have cryptographic hardware, others only
software
@ Peer with topologically distant BGP Speakers in Internet
- Import full routing table: IPv4, IPv6, etc.
@ Replay some of the Merit historical data
Verification (cont.)
------------------------------------------------------------------------
@ Dynamically build cache of missing Attestations
@ Insert them into UPDATEs passed into testbed
@ Bring peering sessions up and down, etc.
@ Collect performance numbers
- Try various verification policies
- Try various optimizations
@ Evaluate what works and what needs improvement
@ Iterate
UPDATE Containing a Route (w/ implicit data) and Address Attestation
459: Sample 6 at 912783707.560850 = 7.560850 + Fri Dec 4 10:01:47 1998
475: Ether D=08:00:20:09:82:f7 S=00:10:4b:34:e1:11 T=x0800 IPv4
489: IP S=128.89.2.232 D=128.89.1.209 Id=12768 TOS=00 TTL=64 NoFrag DL=263 P=6 TCP
509: TCP S=4884(19.20) D=179(0.179) DL=243 ACK PSH
Seq=763150d8-763151cb Ack=731dba01 Wnd=17520-731dfe71
529: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
545: 0x00f30200 0x02080a00 0xd6400101 0x00400204
561: 0x02010001 0x40030480 0x5902e880 0x04040000
577: 0x0064c008 0x04000100 0x05c00b06 0x00010000
593: 0x006ec010 0xaa804800 0x001004ff 0x49000120
609: 0x30000100 0x35a402e0 0x90010203 0x04050607
625: 0x08090a0b 0x0c0d0e0f 0x10111213 0x14151617
641: 0x18191a1b 0x1c1d1e1f 0x20212223 0x24252627
657: 0x28361bdd 0x147cf108 0x004004ff 0x49271190
673: 0x5e000010 0x10fffe43 0x4c796e6e 0x2e42424e
689: 0x2e436f6d 0x00202e00 0x01001a55 0x00010203
705: 0x04050607 0x08090a0b 0x0c0d0e0f 0x10111213
721: 0x14151617 0x18191a1b 0x1c1d1e1f 0x20212223
737: 0x24252627 0x28361108 0x007cf108 0x004004ff
753: 0x49000150 0x0a000007 0x00010018 0xc0012518
769: 0xc00125
BGP Type Update (2) Marker ffffffff ffffffff ffffffff ffffffff
Withdrawn Routes len 2 Path Attributes len 214 NLRI len 4
Withdrawn: 10.0.0.0/8
Attr [1] T 1: Origin 0 IGP
Attr [4] T 2: AS_Path Seq 1: 1
Attr [4] T 3: NextHop 128.89.2.232
Attr [4] O 4: MED 100
Attr [4] OT 8: Community AS 1:5
Attr [6] OT 11: DestPref AS: 1 Metric: 110
_
| Attr [170] OT 16: Attestations
| RutAtt [72]
| Signer [4] AS 1
| Sig [48] Key Hash xa4 Len Signed 53 AlgId 1=DSA
| Cover[2] e090 ( ... )
| Data [40] 01020304 05060708 090a0b0c 0d0e0f10 11121314
| 15161718 191a1b1c 1d1e1f20 21222324 25262728
| Valid [6] From 1998/11/27 20:20 to 1999/ 1/ 1 0:00
| Subject[4] AS 10001
| AdrAtt [94]
| Signer [16] DNS CLynn.BBN.Com
| Sig [46] Key Hash x55 Len Signed 26 AlgId 1=DSA
| Data [40] 01020304 05060708 090a0b0c 0d0e0f10 11121314
| 15161718 191a1b1c 1d1e1f20 21222324 25262728
| Valid [6] From 1998/ 1/ 1 0:00 to 1999/ 1/ 1 0:00
| Subject[4] AS 1
| ExpPAs [10] ...
|_ attr [7] 0: NLRI 1 IPv4 SAFI 0 -NA- 192.1.37/24
NLRI: 192.1.37.0/24
UPDATE Containing a Route (w/ explicit data) and Address Attestation
848: Sample 8 at 912783710.779816 = 10.779816 + Fri Dec 4 10:01:50 1998
864: Ether D=08:00:20:09:82:f7 S=00:10:4b:34:e1:11 T=x0800 IPv4
878: IP S=128.89.2.232 D=128.89.1.209 Id=12773 TOS=00 TTL=64 NoFrag DL=302 P=6 TCP
898: TCP S=4884(19.20) D=179(0.179) DL=282 ACK PSH
Seq=763151cb-763152e5 Ack=731dba01 Wnd=17520-731dfe71
918: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
934: 0x011a0200 0x02080a00 0xfd400101 0x00400204
950: 0x02010001 0x40030480 0x5902e880 0x04040000
966: 0x0064c008 0x04000100 0x05c00b06 0x00010000
982: 0x006ec010 0xd1806f00 0x001004ff 0x49000120
998: 0x30000100 0x35a402e0 0x90010203 0x04050607
1014: 0x08090a0b 0x0c0d0e0f 0x10111213 0x14151617
1030: 0x18191a1b 0x1c1d1e1f 0x20212223 0x24252627
1046: 0x28361bdd 0x147cf108 0x004004ff 0x49271150
1062: 0x25400101 0x00400204 0x02010001 0xc0080400
1078: 0x010005c0 0x0b060001 0x0000006e 0xc0000700
1094: 0x010118c0 0x0125905e 0x00001010 0xfffe434c
1110: 0x796e6e2e 0x42424e2e 0x436f6d00 0x202e0001
1126: 0x001a5500 0x01020304 0x05060708 0x090a0b0c
1142: 0x0d0e0f10 0x11121314 0x15161718 0x191a1b1c
1158: 0x1d1e1f20 0x21222324 0x25262728 0x36110800
1174: 0x7cf10800 0x4004ff49 0x0001500a 0x00000700
1190: 0x010018c0 0x012518c0 0x0125
BGP Type Update (2) Marker ffffffff ffffffff ffffffff ffffffff
Withdrawn Routes len 2 Path Attributes len 253 NLRI len 4
Withdrawn: 10.0.0.0/8
Attr [1] T 1: Origin 0 IGP
Attr [4] T 2: AS_Path Seq 1: 1
Attr [4] T 3: NextHop 128.89.2.232
Attr [4] O 4: MED 100
Attr [4] OT 8: Community AS 1:5
Attr [6] OT 11: DestPref AS: 1 Metric: 110
Attr [209] OT 16: Attestations
RutAtt [111]
Signer [4] AS 1
Sig [48] Key Hash xa4 Len Signed 53 AlgId 1=DSA
Cover[2] e090 ( ... )
Data [40] 01020304 05060708 090a0b0c 0d0e0f10 11121314
15161718 191a1b1c 1d1e1f20 21222324 25262728
Valid [6] From 1998/11/27 20:20 to 1999/ 1/ 1 0:00
Subject[4] AS 10001
_ ExpPAs [37] ...
| attr [1] T 1: Origin 0 IGP
| attr [4] T 2: AS_Path Seq 1: 1
| attr [4] OT 8: Community AS 1:5
| attr [6] OT 11: DestPref AS: 1 Metric: 110
|_ attr [7] OT 0: NLRI 1 IPv4 SAFI 1 Uni 192.1.37/24
AdrAtt [94]
Signer [16] DNS CLynn.BBN.Com
Sig [46] Key Hash x55 Len Signed 26 AlgId 1=DSA
Data [40] 01020304 05060708 090a0b0c 0d0e0f10 11121314
15161718 191a1b1c 1d1e1f20 21222324 25262728
Valid [6] From 1998/ 1/ 1 0:00 to 1999/ 1/ 1 0:00
Subject[4] AS 1
ExpPAs [10] ...
attr [7] 0: NLRI 1 IPv4 SAFI 0 -NA- 192.1.37/24
NLRI: 192.1.37.0/24