Hu Chunzhe Huawei Technologies Internet Draft: Deng Qiulin Document: Huawei Technologies draft-chunzhe-idr-protection-md5-00.txt Ni Hui Expiration Date: February 2003 Huawei Technologies Li Defeng Huawei Technologies BGP Sessions Protection via MD5 Authentication draft-chunzhe-idr-protection-md5-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026], except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes a BGP Extension to protect the route information on the basis of authentication on the BGP message between BGP speakers,In this mechanism,an addtional Capabilty option(Authentication Code) and random number used for authentication are added to OPEN message,and the Authentication Capability is negotiated between BGP speakers,when they pass the negotiation and setup the Established relationship, all the successive message will be authenticated using MD5 algorithm,with the Marker field in the BGP message substituted with the MD5 digest of the combination including message body.This mechanism can guard against that the BGP message be intercepted and tampered by the attacker. 1.0 Introduction The security of BGP connection is relatively not very robust,this problem can be understood by investigating the format of BGP OPEN message as following: Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication [Page 1] Internet Draft draft-huawei-idr-protection-md5-00.txt August 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Marker | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+--+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In normal situation(without any authentication),all the message headers are composed of the 16-octets all-one Marker. These messages are vulnerable to attack when the man-in-the-middle intercept and capture the TCP message between two BGP peers,parse off the all-one field and get the BGP messages,then he(she) can destroy the Routing System through handling messages as follows: (1)Get the BGP route information and attack the system on the basis of the route information in BGP update messages; (2)Get the BGP information,and change the route information and reput it into the TCP connection,if reput an error message such as message with the wrong length or disordered message,then the BGP error process procedure will disconnect the BGP connection, which will result in a route flapping or break-off.If reput an wrong route which will cause the route blackhole, or increase the traffic of some routers, make them reset or even worse. Such problems can be addressed by authentication on the per-message basis between BGP peers utilizing MD5 Arithmetic and increasing the Authentication Code and the relevant 16-octets random number in Option field of message of OPEN message.The realization procedure is as follows: Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication [Page 2] Internet Draft draft-huawei-idr-protection-md5-00.txt August 2002 (1)In section 4.1 of rfc 1771, Optional Parameters field may contain a list of optional parameters, where each parameter is encoded as a triplet. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Parm. Type | Parm. Length | Parameter Value (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... This paper provides Authentication Information in this parameter, Parameter Type is defined as 1,the Parameter Value field contains a 1-octet Authentication Code followed by a variable length Authentication Data. 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth. Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (2)This paper define Auth. Code as 1(can TBD) to specify the authentication mechanism on the basis of MD5 Algorithm,and Authentication Data field is 16-octets fixed-length random number produced by the BGP speaker which send the OPEN message during BGP peer establishment(BGP speaker1 in figure 1),and this 16-octets random number is used in the succeeding authentications on the per-message basis. (3)BGP speaker receiving the OPEN message with Authentication Information(BGP speaker2 in figure 1) will determine that if the message Authentication Capability based on MD5 algorithm can be supported,the normal KEEPALIVE message(the Marker field of the messageis composed of 16 octets all-one) will be send to BGP speaker1 if such Capability is supported. (4)If the message Authentication Capability based on MD5 algorithm can't be supported by BGP speaker2,BGP speaker1 will receive the normal NOTIFICATION message(the Marker field of the messageis composed of 16 octets all-one) with the Error Subcode set to Unsupported Optional Parameter. In this case the BGP speaker1 shouldn't attempt to re-establish a BGP connection with the BGP speaker2. (5)In situation specified in (3),the two BGP speakers will reach Established state,there will be some message exchanges between them, before BGP speaker1 send the message to BGP speaker2, it will compute the 16 octets MD5 digest of combination of such fields as message type(OPEN,value:1),password(shared between BGP speaker1, BGP speaker2),16 octets random Authentication Data and MSG1(the part in the message to be sent excluding 16-octets marker): Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication [Page 3] Internet Draft draft-huawei-idr-protection-md5-00.txt August 2002 MD5 digest1 = MD5(message type(OPEN)+ password + 16 octets Authentication Data + MSG1 ). then BGP speaker1 then replace the 16 octets marker with the MD5 digest1 derived above,After received the message sent by BGP speaker1,BGP speaker2 will compute MD5 digest with the same combination(message type(OPEN,value:1),password(shared between BGP speaker1, BGP speaker2),16 octets random Authentication Data and MSG2(the part in the message received excluding 16-octets marker)) MD5 digest2 = MD5(message type(OPEN)+ password + 16 octets Authentication Data + MSG2 ). If the 16 octets MD5 digest2 equals the 16 octets marker in the received message, then the message pass the authentication, otherwise will drop the message and logging this message is proposed for attack analysis.If the passwords of both sides are configured differently,all the messages can't pass the authentication all the time,BGP FSM will consider that no message is received. Then after Hold Timer,BGP speaker will disconnect the BGP neighbor,release the relevant resource,transition the neighbor's state to IDLE. In the light of MD5 Algorithm,only the condition that the password when computing MD5 digest2 is the same as the password computing MD5 digest1 AND the condition that MSG1 is the same as MSG2 are both meeted,MD5 digest1 will be the same as MD5 digest2 +-+-+-+--+ OPEN message:capability negotiation +-+-+-+--+ | | and carry Authentication Word | | | | ----------------------------------------------> | BGP | | | KEEPALIVE message:Acknowledge the capability | | | BGP | of message-based Authentication |speaker2| | | <---------------------------------------------- | | |speaker1| UPDATE/KEEPALIVE/NOTIFICATION message | | | | with replaced message header | | | | ---------------------------------------------->| | | | | | +-+-+-+--+ +-+-+-+--+ Figure 1: BGP neighbor establishment with MD5 authentication in OPEN message. The above procedure is stressed on one side of Authentication,where BGP speaker2 is authentication side,and BGP speaker1 is to be authenticated. In practical implementation,such procedure is the same to the situation vice versa. The primary motivation for this Authentication Option is to allow BGP Speaker to protect itself against the introduction of spoofed BGP messages from the peers into the connection stream.To spoof any message between BGP speakers using the scheme described in this paper, an attacker would not only have to guess 16 octets random Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication [Page 4] Internet Draft draft-huawei-idr-protection-open-00.txt August 2002 numbers in Optional Parameter, but would also have had to obtain the password included in the MD5 digest.This password never appears in the connection stream, and the actual form of the password is up to the configuration where password can be shown with encrypt form,that is out of the scope of this paper.With the Marker Field replaced with 16-octets digest1,it is difficult for the attacker to find out what is the beginning of BGP message. 2.0 Some Implications 2.1 Message Authentication period The procedure specified by section 1.0 is valid only during BGP FSM state transition period after OPEN message is sent from a BGP speaker,and if the BGP session is reset, the Authentication procedure is invalid until another session. 2.2 Performance The cost in calculating digests of authentication information and 16-byte compare isn't that much,so the impact of BGP message process efficiency is slim.So the performance of such BGP session protection based on OPEN message is presentable. 2.3 OPEN message Header Size The least OPEN message Header Size is 29 octets when there is no Optional Parameter,in the situation this paper concerned, The total Optional Parameter length is 19 octets (1 octet(Parm. Type)+ 1 octet(Parm. Length)+1 octet(Auth. Code)+16 octets Authentication Data),so the least OPEN message Header Size is 48 octets. 2.4 Password configuration It should be noted that the Password configuration mechanism of routers may restrict the possible passwords that may be used between peers. It is strongly recommended that an implementation be able to support at minimum a password composed of a string of printable ASCII of 80 bytes or less, as this is current practice. 3.0 Security Considerations This BGP extension mechanism provides an simple but efficient method to protect the security of BGP route information,compared with other methods which encrypt the whole BGP message,the impact to the performance of route protocol will be sustainable,and in contrast to the existing BGP security mechanism such as RFC2385, which is from the perspective of the transport layer ,this mechanism takes measure on the application layer and do nothing to the transport layer. 4.0 References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992. Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication [Page 5] Internet Draft draft-huawei-idr-protection-md5-00.txt August 2002 [RFC2385] Andy Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2842] Ravi Chandra, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. 5.0 Author's Address Hu Chunzhe C401 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : huchunzhe@huawei.com Deng Qiulin C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : kevin_deng@huawei.com Ni Hui C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : nihui@huawei.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication [Page 6]