certificates and determine which is more recent.
Requires that time synchronization for TEs, but not
for routers.
KEY FIELD LENGTH The length in bytes of the Router Public Key.
Does not include pad that may follow Router Public
Key field.
ROUTER ROLE Router (R=1), Area Border Router (ABR=2), Autonomous
System Border Router (ASBR=4), ABR and ASBR (ABR-
ASBR=6).
#NET RANGES The number of network ranges that follow. A network
range is defined to be an IP Address and an Address
Mask. This list of ranges defines the addresses that
the Router is permitted to advertise in its Router
Links LSA. Valid values are 0-255. If there are 0
ranges the router cannot advertise anything. This is
not generally useful. One range with address=0 and
mask=0 will allow a router to advertise any address.
IP ADDRESS & ADDRESS MASK
Define a range of addresses that this router may
advertise. Each is a 32 bit value. One range with
address=0 and mask=0 will allow a router to advertise
any address.
ROUTER PUBLIC KEY A key that can be used to verify the signatures
produced by this router. The internal format for the
Router Public Key is signature algorithm dependent.
A pad is added to the end of the Router Public Key
field to allow the next field to begin on a (4 byte)
word boundary.
The format used for an RSA-MD5 public key is defined
in section 3.5 of RFC2065 [10].
CERTIFICATION The Trusted Entity's signature of the certified data.
This signature can be verified with the TE public key
identified by TE Id and TE Key Id given in this
packet. The length of the certification depends on
the key size, and is stored in the PKLSA Cert Length
field. A pad is added to the end of the
Certification to allow the next field to begin on a
(4 byte) word boundary.
The format used for an RSA-MD5 signature is defined
in section 4.1.2 of RFC2065 [10].
7.3 Signed LSA
A signed LSA is an OSPF LSA with signature data and a digital
signature attached. The first bit of the LSA Type field is set to
indicate the presence of a signature. The signature follows the LSA
Data. Signature length and id fields are positioned at the end of
the signed LSA.
ANY SIGNED LSA
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Age | Options | LS Type |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LSA Data /
/ ... /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Signature /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Rtr Key Id | TE Id | Sign Length |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
LS AGE Defined in OSPF RFC[3].
OPTIONS Defined in OSPF RFC[3].
LS TYPE Standard LSA Type with the first bit set to indicate
the presence of security data and a signature. This
creates a new signed LSA type for each existing type.
LINK STATE ID Defined in OSPF RFC[3].
ADVERTISING ROUTER Defined in OSPF RFC[3].
LS SEQUENCE NUMBER Defined in OSPF RFC[3].
LS CHECKSUM Defined in OSPF RFC[3].
Checksum does not cover the signature.
LENGTH Defined in OSPF RFC[3].
Length does include the Signature and security
related fields at the end of the LSA.
SIGNATURE The advertising router's signature of this LSA. The
signature covers the LSA header and data starting
with the LSA header options field and ending with the
Trusted Entity certification field. For sign and
verify, the last three fields (Rtr Key Id, TE Id,
Sign Length) are appended to the Certificate. When
complete, the signature is inserted between the
Certification and the Rtr Key Id. There are two
exceptions to this coverage:
1) If the LSA was generated with an age=MaxAge, then
the signature begins with the age field (see section
3.3).
2) The checksum in the LSA Header is set to zero for
the computation & verification of the signature.
A pad is added to the end of the signature to allow
the next field to begin on a (4 byte) word boundary.
The format used for an RSA-MD5 signature is defined
in section 4.1.2 of RFC2065 [10].
RTR KEY ID Used to identify the router key used to sign this
LSA. The combination of (TE Id, Rtr Id, Rtr Key Id)
uniquely identifies a particular router key at a
given time, and can be used to look up the PKLSA for
the router key needed to verify this Signed LSA. A
number between 1-250. 0 reserved for null. 251-255
reserved for future needs.
TE ID The id of the Trusted Entity that produced the
certificate. TE Id must uniquely identify one TE in
the AS. A number between 1-250. 0 reserved for
null. 251-255 reserved for future needs.
SIGN LENGTH The length in bytes of the Signature.
Does not include pad that may follow Signature.
8. Configuration Information
Trusted Entity Information Set: (one per Trusted Entity used by this
router)
Trusted Entity ID - TE Id
Identifies the Trusted Entity within the AS (defined in 7.2).
Trusted Entity Key Id - TE Key Id
Identifies the particular key for this Trusted Entity
(defined in 7.2).
Trusted Entity Public Key
A public key for this Trusted Entity.
The format used for an RSA-MD5 public key is defined in
section 3.5 of RFC2065 [10].
Signature Algorithm < and optional parameters >
The signature algorithm for the public key (defined in 7.2).
Router Information Set: (at least one for the router)
Router Private Key
The router's private key that goes with the public key in the
certificate following. The format used for the private key
depends on the crypto package used by your implementation.
This key is not transmitted as part of this design. Our
implementation uses the private key format compatible with
RSAREF [9].
Router Certificate (format in 7.2).
Timing Intervals:
Trusted Entity Key Distribution Interval (TE_KEY_DIST_INT)
The period of time, in seconds, needed to get a TE public key
installed on all the routers in the TE's scope.
Maximum Transit Delay (MAX_TRANSIT_DELAY)
The maximum period of time, in seconds, that it should take
for an LSA to reach all the routers in the AS.
Router Information per attached Area:
Environment flag
Signed=1, Unsigned=0
9. Remaining Vulnerabilities
Note that with this mechanism, one router can still distribute
incorrect data in the information for which it itself is responsible.
Consequently, an autonomous system employing digital signatures with
this mechanism will not be completely invulnerable to routing
disruptions from a single router. For example, the area border
routers and autonomous system border routers will still be able to
inject incorrect routing information. Also, any single internal
router can be incorrect in the routing information it originates
about its own links.
9.1. Area Border Routers
Even with the design proposed here, the area border routers can
inject incorrect routing information into their attached areas about
the backbone and the other areas in Summary LSA's. They can also
inject incorrect routing information into the backbone about their
attached area.
Because all the area border routers in one area work from the same
database of LSA's received in their common area, it would be possible
for the area border routers to corroborate each other. Any area
border router for an area could double check the Summary LSA's
received over the backbone from other ABR's from the area, and could
double check the Summary LSA's flooded through the area from the
other area border routers. The other routers in the area or backbone
should be warned of a failure of this check. The warning could be a
signed message from the area border router detecting the failure,
flooded in the usual mechanism.
Another possibility would be that the area border routers in an area
could originate multiple sets of Summary LSA's -- one for itself
containing its own information and one for each of the area border
routers in the area containing the information each of them should
originate. Each router in the area or backbone could then determine
for itself whether the area border routers agreed. This distribution
of information but coordination of processing is in keeping with the
paradigm of link state protocols, where information and processing is
duplicated in each router.
Both alternatives mean much additional processing and additional
message transmission, over and above the additional processing
required for signature generation and verification. Because the
vulnerability is isolated to a few points in each area, because the
source of incorrect information is detectable (in those situations
where the incorrect information is spotted) and because the
protection is costly, we have not added this protection to this
design.
9.2. Internal Routers
The internal routers can be incorrect about information they
themselves originate.
A router could announce an incorrect metric for a valid link. There
is no way to guard against this, but the damage would be small and
localized even if the router is announcing that the link is up when
it is down or vice versa.
A router could announce a connection that does not in fact exist. If
a router announces a non-existent connection to a transit network,
the OSPF Dijkstra computation will not consider the connection
without a similar announcement from another router at the other
"end". Therefore, no damage would result (above network impact to
transmit and store the incorrect information) without the cooperation
of another router. A router could also announce a connection to a
stub network or a host route that does not exist. The Dijkstra
computation can not perform the same check for a similar announcement
from the other "end", because no other end exists. This is a
vulnerability.
A faulty router announcing a nonexistent connection to a stub network
or host could result in the faulty router receiving IP packets bound
for that network or host. Unless the faulty router then forwarded
the packets to the correct destination by source routing, the failure
of packet delivery could expose the incorrect routing. To exploit
the vulnerability deliberately, the faulty router would have to be
able to handle and pass on the received traffic for the incorrectly
announced destination. Furthermore, if the incorrect routing were
discovered, the signatures on the routing information would identify
the faulty router as the source of the incorrect information.
Finally, this design checks router advertisements against allowed
address ranges certified by a trusted entity. A faulty router could
announce nonexistent host or stub network routes, but only to
addresses within its allowed ranges.
9.3. Autonomous System Border Routers
The autonomous system boundary routers can produce incorrect routing
information in the external routes information they originate. There
is no way to double check or corroborate this information, as there
is with area border routers. No authority within an autonomous
system exists to authorize the networks an autonomous system boundary
router could announce, as is the case for the internal networks an
internal router could announce. Consequently, the autonomous system
boundary routers remain a unprotected vulnerability. With this in
mind, special care should be taken to protect the autonomous system
boundary routers with other means.
10. Security Considerations
This entire memo is about security considerations.
11. References
[1] Finn, Gregory G., "Reducing the Vulnerability of Dynamic Computer
Networks," ISI Research Report ISI/RR-88-201, University of
Southern California Information Sciences Institute,
Marina del Rey, California, June 1988.
[2] Kumar,B and Crowcroft,J., "Integrating Security in Inter-Domain
Routing Protocols", Computer Communications Review, Vol 23,
No. 5, October 1993.
[3] Moy, J., "OSPF Version 2," RFC1583, Proteon, Inc., March 1994.
[4] Perlman, R., "Network Layer Protocols with Byzantine Robustness",
Ph.D. Thesis, Department of Electrical Engineering and Computer
Science, MIT, August 1988.
[5] Perlman, R., "Interconnections: Bridges and Routers",
Addison-Wesley, Reading, Mass., 1992.
[6] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
Source Code in C," John Wiley & Sons, Inc., New York, 1994.
[7] Steenstrup, M., "Inter-Domain Policy Routing Protocol
Specification: Version 1", RFC1479, BBN Systems and
Technologies, July 1993.
[9] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., June
1991, Version 1.4.
[10] Eastlake D. & Kaufman C., "Domain Name System Security
Extensions", RFC2065, January 1997.
[11] Moy J., "OSPF Version 2", Cascade Communications Corp,
Work In Progress.
12. Authors' Addresses
Sandra Murphy murphy@tis.com
Madelyn Badger mrb@tis.com
Brian Wellington bwelling@tis.com
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738