Internet DRAFT - draft-etienne-rfc2154-flaws
draft-etienne-rfc2154-flaws
Network Working Group J. Etienne
Internet-Draft May 3, 2001
Expires: November 1, 2001
OSPF with digital signature against an insider
draft-etienne-rfc2154-flaws-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.
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.
This Internet-Draft will expire on November 1, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This text comments the security offered by RFC2154[1] "OSPF with
Digital Signatures" and shows it is insecure against insiders
attacks. It is describes an experimental extension of OSPF to
digitaly sign the LSAs.
Etienne Expires November 1, 2001 [Page 1]
Internet-Draft rfc2154 vs insider May 2001
Table of Contents
1. Reader requirement . . . . . . . . . . . . . . . . . . . . . . 3
2. Attacker model . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Authentication . . . . . . . . . . . . . . . . . . . . 3
3.1 Packet anti-replay . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Packet authentication per source . . . . . . . . . . . . . . . 3
4. LSA anti-replay . . . . . . . . . . . . . . . . . . . . . . . 4
5. Globally synchronized timestamps . . . . . . . . . . . . . . . 4
6. LSA's age . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Local roles . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Global roles . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1 Area Border Router . . . . . . . . . . . . . . . . . . . . . . 5
8.2 Autonomous System Boundary Router . . . . . . . . . . . . . . 5
9. Security considerations . . . . . . . . . . . . . . . . . . . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
Etienne Expires November 1, 2001 [Page 2]
Internet-Draft rfc2154 vs insider May 2001
1. Reader requirement
The reader is supposed to know OSPF(RFC2328[2]), the digital
signature extension(RFC2154[1]), and have notions in protocol
security. We have inserted precises references to help the reader.
2. Attacker model
The attacker model isn't clearly specified in the rfc, so we assume
an attacker who takes deliberate actions (unexpected by the
protocol) in order to influence the routing for personal gains (e.g.
make a network unreachable, route packets toward a attacker to
perform traffic analysis or man-in-the-middle attacks).
3. Packet Authentication
In OSPF cryptographic authentication (RFC2328.D.3[2]), the neighbors
of a link share a secret key and sign all the packets with it. It
provides some protections against external nodes injecting packets
in OSPF local exchanges without being detected. But this sheme has 2
weaknesses: (i) the authentication is done per link and (ii) the
anti-replay has a flaw.
3.1 Packet anti-replay
Packets can still be replayed because several packets can legally
have the same sequence numbers. The main reason is OSPF doesn't
provide a rollover procedure for the sequence number and to avoid
this case, the standard advices to use the number of seconds as
sequence number. So an external node can sucessfully replay a packet
multiple times until the destination router(s) accept(s) a packet
with a higher sequence number. This delay can be up to 10 seconds
(default hello interval) and more in case of packet loss.
RFC2154[1] doesn't mention this problem.
3.2 Packet authentication per source
The OSPF's authentication protects the routers from unauthorized
access by external nodes but a router can still send fake packets
without being detected.
RFC2154.2[1] shortly mentions this problem : "The basic idea of this
proposal is to ... use a neighbor-to-neighbor authentication
algorithm (like keyed MD5) to protect local protocol exchanges". But
this algorithm isn't described, so we consider the hole still open.
Etienne Expires November 1, 2001 [Page 3]
Internet-Draft rfc2154 vs insider May 2001
4. LSA anti-replay
In OSPF, the sequence numbers(RFC2328.12.1.6[2]) of LSAs aren't
stored in a non-volatile memory and are reused after a reboot. An
attacker may exploit this feature to feed victims with obsolete
LSAs. The replayed LSAs have a valid signature so the victims won't
detect the forgery.
RFC2154[1] doesn't mention this problem.
5. Globally synchronized timestamps
RFC2154.7.2.createtime[1] requires to have globally synchronized
clock between Trusted Entities but doesn't explain how to
synchronized them. The solution isn't trivial because the
synchronization must be secure against insider attacks as well. As
RFC2154[1] doesnt specify how to achieve a globally synchronized
clock with possibly subverted time servers, we consider this as a
weakness.
6. LSA's age
The age field (RFC2328.12.1.1[2]) of a LSA is modified in transit,
so it can't be cover by the digital signature and an attacker may
forge it.
RFC2154.3.1[1] proposes to cover the age field only when it is set
to MaxAge (RFC2328.B.MaxAge[2]). It is possible because OSPF never
increase a LSA's age beyond MaxAge so the field won't modified in
transit. It prevents a router from forging a LSA with an age of
MaxAge but an attacker can still set the age to any value between 0
to MaxAge-1. For example, an attacker can set the age close to
MaxAge and flood it. The LSA will be installed in each router and
prematurely expire, causing an easy denial of service, so we
consider the hole still open.
7. Local roles
On broadcast and NBMA networks, OSPF elects a designated router
(RFC2328.7.3[2]). A designated router has an influential role in
OSPF, it originates the net-LSA for transit broadcast/NBMA networks
and is the center on the database exchanges. The designated router
is elected (RFC2328.9.4[2]) based on a priority (RFC2328.9[2]). An
attacker may claim an higher priority to be elected and take
advantages of its designated role.
RFC2154[1] doesn't mention this problem.
Etienne Expires November 1, 2001 [Page 4]
Internet-Draft rfc2154 vs insider May 2001
8. Global roles
Area Border Routers (ABR RFC2328.3.3[2]) and Autonomous System
Boundary Routers (ASBR RFC2328.3.3[2]) advertize informations
(summary-LSA RFC2328.12.4.3[2] and AS-external-LSA
RFC2328.12.4.4[2]) about non directly connected links. If signing
LSAs prevent forgery, a router can still send incorrect informations
in its own LSAs. For example, an ABR can inject summary LSAs with
falsly small metrics and thus attrack the outgoing traffic of the
whole area (e.g. blackhole, traffic analisys, packet modification).
8.1 Area Border Router
ABRs of an area are connected together by the area and by the
backbone. Because they have access to the same informations (i.e.
the original data from a hierachical level and how the others ABRs
export it into the other), they can check each other.
This assumes there is at least one uncorrupted ABRs per area.
Moreover if the topology changes, the ABRs temporarily may have a
different database and obtain different results even if no router is
corrupted. So the result's exploitation may be difficult.
Using this, RFC2154.9.1[1] presents two interesting proposals: (i)
The first one is each ABR checks the calculation of the other ABRs
and issue a warning if an attack is diagnozed. With N ABRs connected
to a area, the cpu load is multiplied by N-1 on each ABR. (ii) The
second one goes further and originates the LSAs resulting from the
calculations, thus each router can choose which LSA to use. this
multiply the number of LSA originated by an ABR by N-1. These LSAs
will be flooded and stored in each router of the area, so the memory
and network cost are increased significantly.
Both solutions increases the protocol cost and RFC2154[1] finds them
too expensive to be used. Moreover if all the ABRs are corrupted,
the attack will be undetected.
8.2 Autonomous System Boundary Router
By definition, the informations external to the autonomous area
aren't controled by OSPF. so an ASBR can produce incorrect route
without being detected.
RFC2154.9.3[1] explain it.
9. Security considerations
This text shows that OSPF with digital signature is insecure against
insiders attacks.
Etienne Expires November 1, 2001 [Page 5]
Internet-Draft rfc2154 vs insider May 2001
If the attacker model is reduced to a faulty router which
accidentally send bogus packets due to software or hardware bugs,
the vulnerabilities described in this text are still valid but much
less likely.
References
[1] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
[2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Author's Address
Jerome Etienne
EMail: jme@off.net
URI: http://w3.arobas.net/~jetienne
Etienne Expires November 1, 2001 [Page 6]
Internet-Draft rfc2154 vs insider May 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Etienne Expires November 1, 2001 [Page 7]
