1 CMPT 471 Networking II BGP

© Janice Regan, External Gateway Protocol  An EGP is designed to control the passage of information between autonomous systems. Information actually passes between AS boundary routers:  Boundary or Border routers are part of the AS communicate with routers outside the AS using an EGP Communicate with other router in the AS using an IGP

© Janice Regan, External Gateway Protocol  Boundary routers learn information from outside the AS using the EGP, and relay that information to the IGP  Boundary routers learn information from inside the AS using the IGP, and relay the information to the EGP to be shared with external routers.

© Janice Regan, Flow of routing information  IP packet forwarding using the routing table to forward a packet to the correct host or router  The IGP controls the maintenance of the entries in the routing tables and the transfer of routing information between routers within the autonomous system.  The EGP summarizes the data provided by the IGP and shares that data with routers in other ASs. It also collects summary data for the networks connected to other participating border routers and passes the information to the IGP and the AS’s other internal routers

© Janice Regan, Flow of routing information  A border router can also choose to advertise routes received from other border routers in its AS (who received it from other border routers on other ASs). If it does this the AS becomes transit network for packets taking those routes.

© Janice Regan, Distance-vector Routing  Each node exchanges information only with neighbor nodes  Each node maintains vector of link costs for each directly attached node, and distance and next-hop values for each destination node in the system  A node must transmit large amounts of information  Distance vector to all neighbors, Containing estimated path cost to all nodes in a configuration and next hop labels

© Janice Regan, Distance-vector Routing  Changes take long time to propagate (count to infinity) Refer to 371 notes for explanation (lec 17)  Used by first generation routing algorithm for ARPANET and by Routing Information Protocol (RIP, routed) RIP is an internal gateway protocol (IGP) used between routers within an AS

© Janice Regan, The original EGP  Now many use EGP as the general term, rather than the name of this specific original protocol.

© Janice Regan, The original EGP  EGP or External Gateway Protocol  A distance vector protocol (like RIP, or DVRMP) Different ASs use different distance metrics so combining multiple ASs with a single distance vector protocol requires relating these metrics to one another. RIP has metric 0-15, EGP uses If a RIP network has more than one external router, distance information cannot be maintained for packets transiting the network. Information is lost in conversion

© Janice Regan, Problems with the original EGP  Convergence became a problem as the internet grew, because of the problems of a distance vector protocol (count to infinity, … )  Can easily create a ‘black hole’ by advertising a route with cost 0 (purposely or accidentally). All traffic is routed to the cost 0 path is lost.  Retransmission, timers, and flow control were part of EGP making the state machine for EGP quite complex. The newer BGP communicates using TCP, reliable transport means retransmissiono times are not needed making BGP simple in comparison to EGP

© Janice Regan, Link-state Routing  When router initialized and at intervals thereafter, it determines link cost on each interface (cost to each directly connected node)  Advertises, floods to all other nodes, a set of link costs to all nearest neighbors  Each node constructs routing table containing minimum cost paths to all attached nodes ( costs and first hop to each router) using the data received from all other nodes’ advertisements.  Open shortest path first (OSPF) protocol uses link-state routing. (a common IRP)  Second generation routing algorithm for ARPANET

© Janice Regan, “Large amounts” of data  limitations of distance vector algorithms make them unusable for an exterior routing protocol: how do you define a metric?  large size of the Internet makes a link state algorithm computationally infeasible.  A limit of ~ 200 routers is recommended for link state calculations.  The Internet was approaching 18,000 AS’s (July 2004), each of which is likely to have several boundary routers; many will have 100’s of boundary routers.  A BGP speaker must maintain two tables of route information for each of its neighbours (routes received and routes advertised), plus a route table for its own use The June 2004 IETF draft BGP protocol analysis report estimates the total memory requirement to be on the order of 100MB for a router with 100 BGP peers.

© Janice Regan, What approach to routing is right for an Exterior Router Protocol  Link-state and distance-vector not effective for exterior router protocol  Link state requires flooding of link state information, and large memory requirements, for a large net this is not practical  Distance-vector requires all routers share common distance metric, different ASs may use different metrics

© Janice Regan, What approach to routing is right for an Exterior Router Protocol  Link-state and distance-vector not effective for exterior router protocol  ASs may have different priorities or restrictions that prohibit use of certain other ASs (those belonging to a competitor for instance),  Distance-vector gives no information about ASs visited on route, only about distance to destination, this is not always the most applicable information particularly when policy based routing is needed

© Janice Regan, ERP: Path Vector  No path cost information used  Each block of information lists all ASs visited on the way to the receiver, Each block is called a route  Allows the receiver to know the source for each path and whether the path originates in the local AS (coming from IRP or ERP)  Can be used to check for loops ( conceptually any node appearing more than once)

© Janice Regan, ERP: Path Vector  Each block of information lists all ASs visited on the way to the receiver, Each block is called a route  Enables router to perform policy routing based on Avoiding transiting a particular AS link speed, capacity, tendency to become congested, overall quality of operation, security minimizing number of transit ASs

© Janice Regan, Border Gateway Protocol  BGP is the preferred ERP for or use with TCP/IP internets  RFC 1771 and 1772  A path vector protocol  Messages sent over reliable TCP connections  4 types: Open, Update, Keep Alive, Notification  All message types have a common header  Maximum size of a message is 4096 bytes

© Janice Regan, BGP message header format Comer 2000: fig 15.5 and 15.6

© Janice Regan, BGP messages: common header  Marker: an agreed upon value to mark the start of a message, also can be used for authentication (contains 1’s in the initial message or an agreed upon authentication string)  Length: Length of the total message in octets ( ) Max length of message is 4096 octets  Type: code indicating type of message, Open(1), Update(2), Notification(3), KeepAlive(4)

© Janice Regan, Components of BGP operation  ALL BGP messages are sent through a TCP connection.  This eliminates the need for BGP to deal with flow control ( retransmission, acknowledgement, and sequencing) itself, and simplifies the BGP protocol removing the need for retransmission timers.  BGP assumes that TCP uses a graceful shutdown (all waiting packets are sent before connection is closed)

© Janice Regan, Additional Usage of Marker  The marker is also used for synchronization  A TCP connection is ‘always on’  How do we identify the beginning of a message? Each message has a length indicated in the message header. Take the bit following the end of this packet as the start of the next packet What if the length is wrong? Then the next message will not be interpreted correctly (off by one bit) To avoid this difficulty use the marker for synchronization. Watch for the marker, use it to define the beginning of the message

© Janice Regan, Components of BGP operation  Neighbor acquisition: Determine if a router physically connected to this router is willing to be a neighbor and Initiate neighbor relationship, negotiating parameters  Neighbor reachability: maintain neighbor relationship  Network reachability: build/maintain routing database  Reporting of error conditions

© Janice Regan, BGP : neighbor acquisition  Open TCP connection between router1 and router2, a pair of connected (neighbor) routers, on port 179  Router1 and router2 both send an Open message  Router1 receives router2’s open message. If router1 agrees to become a neighbor of router2 it replies to router2 with a keep-alive message (like an ACK)  Router2 receives router1’s open message. If router2 agrees to become a neighbor of router1 it replies to router1 with a keep-alive message

© Janice Regan, BGP : neighbor acquisition  If either router does not agree, or some other problem occurs a notification message will be sent and the connection will eventually be terminated  When both routers have received a keep-alive from the other router, after sending a keep-alive to the other router, the neighbor relationship is established.

© Janice Regan, BGP OPEN message Comer 2000: fig 15.7 (always the same interface)

© Janice Regan, Fields: BGP open message  BGP version number (current version is 4): Both routers must use the same version of BGP to be able to become neighbors  AS number: A number identifying the AS to which the sending router belongs  BGP option length: 0 if no options, otherwise the length of the options field

© Janice Regan, Fields: BGP open message  Hold time: maximum number of seconds between receipt of successive keep-alive messages. If no keep-alive or update message is received during the hold time the connection terminates  BGP Identifier: One of the IP addresses of the BGP router (sender) A BGP router will use the same identifier regardless of the interface through which the message is actually sent  BGP option length: 0 if no options, otherwise the length of the options field

© Janice Regan, BGP options fields  Each option takes at least 3 octets  One octet for type  One octet for length  A variable length data field (one or more octets)  Only one option, authentication information, is specified in RFC  This option is of limited use unless the TCP connection is secured.

© Janice Regan, BGP options fields  Only one option, authentication information, is specified in RFC  Contains one octet authentication code (how to interpret remaining information) identifies the authentication algorithm and the meaning of the authentication information.  Authentication information will determine the contents of the marker field in the common header for subsequent packets transferred between these neighbors  Values not defined in RFC would have to be previously agreed upon

© Janice Regan, Neighbor Acquisition Negotiating BGP Parameters  When one router receives the other routers Open message it will  Check that the version specified in the request is supported Versions must match for a neighbor relation  Check the requesting AS is acceptable to the local AS as a neighbor Policy routing; is the router attempting to establish a neighbor relation in this routers list of acceptable neighbors?

© Janice Regan, Neighbor Acquisition Negotiating BGP Parameters  When one router receives the other routers Open message it will  Select the minimum of local (sent) and received hold times as the hold time for this neighbor relationship Minimum can be 0. This indicates no keep alive messages should be sent  Check the authentication  Check the Identifier

© Janice Regan, Neighbor Acquisition Negotiating BGP Parameters  If any of the checks are negative an appropriate notification message will be sent and the TCP connection will be terminated  Otherwise a keep-alive message will be sent to indicate its willingness to be a member

© Janice Regan, Why secure TCP connection  An insecure connection can be compromised  A SYN flooding attack (tries to deny service by requiring creation of many half open connections)  A RST attack (tries to close the connection)  A data insertion attack (inserting forged packet into data stream)  A hijacking attack (substitute a third party for one of the endpoints of the connection)

© Janice Regan, Why secure TCP connection  If the TCP connection is carrying BGP traffic these attacks could bring down the BGP router and create havoc  Routes could be removed because a link in the connection was brought down. This could result in disconnecting networks  Hijacking could result in insertion of false routes that could cause problems such as loops, loss of traffic to ‘black holes’, or capture of traffic bound for some networks

© Janice Regan, How to prevent?  Use the authentication provided in BGP to authenticate the source.  Could also send over a secured IP connection  MD5 Signature option is now available (RFC-2358)  This is not a strong protection, and is vulnerable to known attacks  This is much stronger than the password used to protect BGP in its absence