Internet DRAFT - draft-chunzhe-idr-protection-md5
draft-chunzhe-idr-protection-md5
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 <Parameter Type, Parameter Length, Parameter Value>
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]
