Network Working Group J. Palme Request for Comments: 2110 Stockholm University/KTH Category: Standards Track A. Hopmann Microsoft Corporation March 1997 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) Status of this Document This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate using HTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content- Location" and "Content-Base". Table of Contents 1. Introduction.............................................. 2 2. Terminology............................................... 3 2.1 Conformance requirement terminology................... 3 2.2 Other terminology..................................... 4 3. Overview.................................................. 5 4. The Content-Location and Content-Base MIME Content Headers 6 4.1 MIME content headers.................................. 6 4.2 The Content-Base header............................... 7 4.3 The Content-Location Header........................... 7 4.4 Encoding of URIs in e-mail headers.................... 8 5. Base URIs for resolution of relative URIs................. 8 6. Sending documents without linked objects.................. 9 7. Use of the Content-Type: Multipart/related................ 9 8. Format of Links to Other Body Parts....................... 11 Palme & Hopmann Standards Track [Page 1] RFC 2110 MHTML March 1997 8.1 General principle..................................... 11 8.2 Use of the Content-Location header.................... 11 8.3 Use of the Content-ID header and CID URLs............. 12 9 Examples................................................... 12 9.1 Example of a HTML body without included linked objects 12 9.2 Example with absolute URIs to an embedded GIF picture 13 9.3 Example with relative URIs to an embedded GIF picture 13 9.4 Example using CID URL and Content-ID header to an embedded GIF picture.................................. 14 10. Content-Disposition header............................... 15 11. Character encoding issues and end-of-line issues......... 15 12. Security Considerations.................................. 16 13. Acknowledgments.......................................... 17 14. References............................................... 18 15. Author's Address......................................... 19 Mailing List Information Further discussion on this document should be done through the mailing list MHTML@SEGATE.SUNET.SE. To subscribe to this list, send a message to LISTSERV@SEGATE.SUNET.SE which contains the text SUB MHTML Archives of this list are available by anonymous ftp from FTP://SEGATE.SUNET.SE/lists/mHTML/ The archives are also available by e-mail. Send a message to LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a list of the archive files, and then a new message "GET " to retrieve the archive files. Comments on less important details may also be sent to the editor, Jacob Palme . More information may also be available at URL: HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML 1. Introduction There are a number of document formats, HTML [HTML2], PDF [PDF] and VRML for example, which provide links using URIs for their resolution. There is an obvious need to be able to send documents in these formats in e-mail [RFC821=SMTP, RFC822]. This document gives additional specifications on how to send such documents in MIME [RFC 1521=MIME1] e-mail messages. This version of this standard was based on full consideration only of the needs for objects with links in the Palme & Hopmann Standards Track [Page 2] RFC 2110 MHTML March 1997 Text/HTML media type (as defined in RFC 1866 [HTML2]), but the standard may still be applicable also to other formats for sets of interlinked objects, linked by URIs. There is no conformance requirement that implementations claiming conformance to this standard are able to handle URI-s in other document formats than HTML. URIs in documents in HTML and other similar formats reference other objects and resources, either embedded or directly accessible through hypertext links. When mailing such a document, it is often desirable to also mail all of the additional resources that are referenced in it; those elements are necessary for the complete interpretation of the primary object. An alternative way for sending an HTML document or other object containing URIs in e-mail is to only send the URL, and let the recipient look up the document using HTTP. That method is described in [URLBODY] and is not described in this document. An informational RFC will at a later time be published as a supplement to this standard. The informational RFC will discuss implementation methods and some implementation problems. Implementors are recommended to read this informational RFC when developing implementations of the MHTML standard. This informational RFC is, when this RFC is published, still in IETF draft status, and will stay that way for at least six months in order to gain more implementation experience before it is published. 2. Terminology 2.1 Conformance requirement terminology This specification uses the same words as RFC 1123 [HOSTS] for defining the significance of each particular requirement. These words are: MUST This word or the adjective "required" means that the item is an absolute requirement of the specification. SHOULD This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. Palme & Hopmann Standards Track [Page 3] RFC 2110 MHTML March 1997 MAY This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant." 2.2 Other terminology Most of the terms used in this document are defined in other RFCs. Absolute URI, See RFC 1808 [RELURL]. AbsoluteURI CID See [MIDCID]. Content-Base See section 4.2 below. Content-ID See [MIDCID]. Content-Location MIME message or content part header with the URI of the MIME message or content part body, defined in section 4.3 below. Content-Transfer-Enco Conversion of a text into 7-bit octets as ding specified in [MIME1]. CR See [RFC822]. CRLF See [RFC822]. Displayed text The text shown to the user reading a document with a web browser. This may be different from the HTML markup, see the definition of HTML markup below. Header Field in a message or content heading specifying the value of one attribute. Palme & Hopmann Standards Track [Page 4] RFC 2110 MHTML March 1997 Heading Part of a message or content before the first CRLFCRLF, containing formatted fields with attributes of the message or content. HTML See RFC 1866 [HTML2]. HTML Aggregate HTML objects together with some or all objects, to objects which the HTML object contains hyperlinks. HTML markup A file containing HTML encodings as specified in [HTML] which may be different from the displayed text which a person using a web browser sees. For example, the HTML markup may contain "<" where the displayed text contains the character "<". LF See [RFC822]. MIC Message Integrity Codes, codes use to verify that a message has not been modified. MIME See RFC 1521 [MIME1], [MIME2]. MUA Messaging User Agent. PDF Portable Document Format, see [PDF]. Relative URI, See RFC 1866 [HTML2] and RFC 1808[RELURL]. RelativeURI URI, absolute and See RFC 1866 [HTML2]. relative URL See RFC 1738 [URL]. URL, relative See [RELURL]. VRML Virtual Reality Markup Language. 3. Overview An aggregate document is a MIME-encoded message that contains a root document as well as other data that is required in order to represent that document (inline pictures, style sheets, applets, etc.). Aggregate documents can also include additional elements that are linked to the first object. It is important to keep in mind the differing needs of several audiences. Mail sending agents might send Palme & Hopmann Standards Track [Page 5] RFC 2110 MHTML March 1997 aggregate documents as an encoding of normal day-to-day electronic mail. Mail sending agents might also send aggregate documents when a user wishes to mail a particular document from the web to someone else. Finally mail sending agents might send aggregate documents as automatic responders, providing access to WWW resources for non-IP connected clients. Mail receiving agents also have several differing needs. Some mail receiving agents might be able to receive an aggregate document and display it just as any other text content type would be displayed. Others might have to pass this aggregate document to a browsing program, and provisions need to be made to make this possible. Finally several other constraints on the problem arise. It is important that it be possible for a document to be signed and for it to be able to be transmitted to a client and displayed with a minimum risk of breaking the message integrity (MIC) check that is part of the signature. 4. The Content-Location and Content-Base MIME Content Headers 4.1 MIME content headers In order to resolve URI references to other body parts, two MIME content headers are defined, Content-Location and Content-Base. Both these headers can occur in any message or content heading, and will then be valid within this heading and for its content. In practice, at present only those URIs which are URLs are used, but it is anticipated that other forms of URIs will in the future be used. The syntax for these headers is, using the syntax definition tools from [RFC822]: content-location ::= "Content-Location:" ( absoluteURI | relativeURI ) content-base ::= "Content-Base:" absoluteURI where URI is at present (June 1996) restricted to the syntax for URLs as defined in RFC 1738 [URL]. These two headers are valid only for exactly the content heading or message heading where they occurs and its text. They are thus not valid for the parts inside multipart headings, and are thus meaningless in multipart headings. Palme & Hopmann Standards Track [Page 6] RFC 2110 MHTML March 1997 These two headers may occur both inside and outside of a multipart/related part. 4.2 The Content-Base header The Content-Base gives a base for relative URIs occurring in other heading fields and in HTML documents which do not have any BASE element in its HTML code. Its value MUST be an absolute URI. Example showing which Content-Base is valid where: Content-Type: Multipart/related; boundary="boundary-example-1"; type=Text/HTML; start=foo2*foo3@bar2.net ; A Content-Base header cannot be placed here, since this is a ; multipart MIME object. --boundary-example-1 Part 1: Content-Type: Text/HTML; charset=US-ASCII Content-ID: Content-Location: http://www.ietf.cnir.reston.va.us/images/foo1.bar1 ; This Content-Location must contain an absolute URI, since no base ; is valid here. --boundary-example-1 Part 2: Content-Type: Text/HTML; charset=US-ASCII Content-ID: Content-Location: foo1.bar1 ; The Content-Base below applies to ; this relative URI Content-Base: http://www.ietf.cnri.reston.va.us/images/ --boundary-example-1-- 4.3 The Content-Location Header The Content-Location header specifies the URI that corresponds to the content of the body part in whose heading the header is placed. Its value CAN be an absolute or relative URI. Any URI or URL scheme may be used, but use of non-standardized URI or URL schemes might entail some risk that recipients cannot handle them correctly. The Content-Location header can be used to indicate that the data sent under this heading is also retrievable, in identical format, through normal use of this URI. If used for this purpose, it must contain an absolute URI or be resolvable, through a Content-Base Palme & Hopmann Standards Track [Page 7] RFC 2110 MHTML March 1997 header, into an absolute URI. In this case, the information sent in the message can be seen as a cached version of the original data. The header can also be used for data which is not available to some or all recipients of the message, for example if the header refers to an object which is only retrievable using this URI in a restricted domain, such as within a company-internal web space. The header can even contain a fictious URI and need in that case not be globally unique. Example: Content-Type: Multipart/related; boundary="boundary-example-1"; type=Text/HTML --boundary-example-1 Part 1: Content-Type: Text/HTML; charset=US-ASCII ... ... ... ... --boundary-example-1 Part 2: Content-Type: Text/HTML; charset=US-ASCII Content-Location: fiction1/fiction2 --boundary-example-1-- 4.4 Encoding of URIs in e-mail headers Since MIME header fields have a limited length and URIs can get quite long, these lines may have to be folded. If such folding is done, the algorithm defined in [URLBODY] section 3.1 should be employed. 5. Base URIs for resolution of relative URIs Relative URIs inside contents of MIME body parts are resolved relative to a base URI. In order to determine this base URI, the first-applicable method in the following list applies. (a) There is a base specification inside the MIME body part containing the link which resolves relative URIs into absolute URIs. For example, HTML provides the BASE element for this. (b) There is a Content-Base header (as defined in section 4.2), specifying the base to be used. Palme & Hopmann Standards Track [Page 8] RFC 2110 MHTML March 1997 (c) There is a Content-Location header in the heading of the body part which can then serve as the base in the same way as the requested URI can serve as a base for relative URIs within a file retrieved via HTTP [HTTP]. When the methods above do not yield an absolute URI the procedure in section 8.2 for matching relative URIs MUST be followed. 6. Sending documents without linked objects If a document, such as an HTML object, is sent without other objects, to which it is linked, it MAY be sent as a Text/HTML body part by itself. In this case, multipart/related need not be used. Such a document may either not include any links, or contain links which the recipient resolves via ordinary net look up, or contain links which the recipient cannot resolve. Inclusion of links which the recipient has to look up through the net may not work for some recipients, since all e-mail recipients do not have full internet connectivity. Also, such links may work for the sender but not for the recipient, for example when the link refers to an URI within a company-internal network not accessible from outside the company. Note that documents with links that the recipient cannot resolve MAY be sent, although this is discouraged. For example, two persons developing a new HTML page may exchange incomplete versions. 7. Use of the Content-Type: Multipart/related If a message contains one or more MIME body parts containing links and also contains as separate body parts, data, to which these links (as defined, for example, in RFC 1866 [HTML2]) refers, then this whole set of body parts (referring body parts and referred-to body parts) SHOULD be sent within a multipart/related body part as defined in [REL]. The root body part of the multipart/related SHOULD be the start object for rendering the object, such as a text/html object, and which contains links to objects in other body parts, or a multipart/alternative of which at least one alternative resolves to such a start object. Implementors are warned, however, that many mail programs treat multipart/alternative as if it had been multipart/mixed (even though MIME [MIME1] requires support for multipart/alternative). Palme & Hopmann Standards Track [Page 9] RFC 2110 MHTML March 1997 [REL] requires that the type attribute of the "Content-Type: Multipart/related" statement be the type of the root object, and this value can thus be "multipart/alternative". If the root is not the first body part within the multipart/related, [REL] further requires that its Content-ID MUST be given in a start parameter to the "Content-Type: Multipart/related" header. When presenting the root body part to the user, the additional body parts within the multipart/related can be used: (a) For those recipients who only have e-mail but not full Internet access. (b) For those recipients who for other reasons, such as firewalls or the use of company-internal links, cannot retrieve the linked body parts through the net. Note that this means that you can, via e-mail, send HTML which includes URIs which the recipient cannot resolve via HTTPor other connectivity-requiring URIs. (c) For items which are not available on the web. (d) For any recipient to speed up access. The type parameter of the "Content-Type: Multipart/related" MUST be the same as the Content-Type of its root. When a sending MUA sends objects which were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form prior to transmitting them. This will allow the receiving MUA to both verify MICs included with the email message, as well as verify the documents against their WWW counterpoints. In certain special cases this will not work if the original HTML document contains URIs as parameters to objects and applets. In such a case, it might be better to rewrite the docu Network Working Group S. Murphy Request for Comments: 2154 M. Badger Category: Experimental B. Wellington Trusted Information Systems June 1997 OSPF with Digital Signatures Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described. Table of Contents 1 Acknowledgements ............................................. 2 2 Introduction ................................................. 2 3 LSA Processing ............................................... 4 3.1 Signed LSA ................................................. 4 3.2 Router Public Key LSA (PKLSA) .............................. 5 3.3 MaxAge Processing .......................................... 7 4 Key Management ............................................... 8 4.1 Identifying Keys ........................................... 8 4.1.1 Identifying Router Keys and PKLSAs ....................... 8 4.1.2 Identifying TE Public Keys ............................... 8 4.1.3 Key to use for Signing ................................... 9 4.1.4 Key to use for Verification .............................. 9 4.2 Trusted Entity (TE) Requirements ........................... 10 4.3 Scope for Keys and Signature Algorithms..................... 10 4.4 Router Key Replacement ..................................... 11 4.5 Trusted Entity Key Replacement ............................. 12 4.6 Flexible Cryptographic Environments ........................ 14 4.6.1 Multiple Signature Algorithms ............................ 14 4.6.2 Multiple Trusted Entities ................................ 15 4.6.3 Multiple Keys for One Router ............................. 16 5 Compatibility with Standard OSPF V2 .......................... 16 6 Special Considerations/Restrictions for the ABR-ASBR ......... 17 7 LSA formats .................................................. 18 Murphy, et. al. Experimental [Page 1] RFC 2154 OSPF with Digital Signatures June 1997 7.1 Router Public Key LSA (PKLSA) .............................. 18 7.2 Router Public Key Certificate .............................. 20 7.3 Signed LSA ................................................. 23 8 Configuration Information .................................... 26 9 Remaining Vulnerabilities .................................... 26 9.1 Area Border Routers ........................................ 27 9.2 Internal Routers ........................................... 27 9.3 Autonomous System Border Routers ........................... 28 10 Security Considerations ..................................... 28 11 References .................................................. 29 12 Authors' Addresses .......................................... 29 1. Acknowledgements The idea of signing routing information is not new. Foremost, of course, there is the design that Radia Perlman reported in her thesis [4] and in her book [5] for signing link state information and for distribution of the public keys used in the signing. IDPR [7] also recommends the use of public key based signatures of link state information. Kumar and Crowcroft [2] discuss the use of secret and public key authentication of inter-domain routing protocols. Finn [1] discusses the use of secret and public key authentication of several different routing protocols. The design reported here is closest to that reported in [4] and [7]. It should be noted that [4] also presents techniques for protecting the forwarding of data packets, a topic that is not considered here, as we consider it not within the scope of the OSPF working group. The authors would also like to acknowledge many fruitful discussions with many members of the OSPF working group, particularly Fred Baker of Cisco Systems, Dennis Ferguson of MCI Telecommunications Corp., John Moy of Cascade Communications Corp., Curtis Villamizar of ANS, Inc., and Rob Coltun of FORE Systems. 2. Introduction It is well recognized that there is a need for greater security in routing protocols. OSPF currently provides "simple password" authentication where the password travels "in the clear", and there is work in progress[11] to provide keyed MD5 authentication for OSPF protocol packets between neighbors. The simple password authentication is vulnerable because any listener can discover and use the password. Keyed MD5 authentication is very useful for protection of protocol packets passed between neighbors, but does not address authentication of routing data that is flooded from source to eventual destination, through routers which may themselves be faulty or subverted. Murphy, et. al. Experimental [Page 2] RFC 2154 OSPF with Digital Signatures June 1997 The basic idea of this proposal is to add digital signatures to OSPF LSA data, distribute certified router information and keys, and use a neighbor-to-neighbor authentication algorithm (like keyed MD5) to protect local protocol exchanges. The content of a Hello packet, Link State Request, Link State Update, or Database Description will be protected by the neighbor-to-neighbor algorithm. The LSAs that are being flooded inside the Link State Update packets are individually protected by a digital signature. Each LSA will be signed by the originator of that information and the signature will stay with the data in its travels via OSPF flooding. This will provide end-to-end integrity and authentication for LSA data. The digital signature attached to an LSA by the source router provides assurance that the data comes from the advertising router. It will also ensure that the data has not been modified by some other router in the course of flooding. In the case where incorrect routing data is originated by a faulty router, the signature will identify the source of the problem. Digital signatures are implemented using public key cryptography. There are some good books on the subject of cryptography [6], but the high level view of how this design uses public key cryptography is as follows: Each router has a pair of keys, a public key and a private key. The private key is used to generate a unique signature of a block of data (in this case, the LSA). Each router signs its LSAs by first running a one-way hash algorithm (like MD5 or SHA) on the data, and then using its private key to sign the digest. The signature of an LSA is appended to the LSA. The public key can be used by any other router to verify the signature. The private key must be kept secret by one router and the public key must be distributed to all the routers that will receive link state information from the signer. The distribution is accomplished by creating a new LSA, the Public Key LSA (PKLSA), and distributing it via the standard OSPF flooding procedure. Flooding will ensure that a router public key is sent everywhere that the router's signed LSAs are sent. Any router can send out a public key and claim to be a given router, so the public key itself provides no assurance of the actual identity of the sender. This assurance must be provided by a Trusted Entity. The Trusted Entity (TE) is a system that generates certificates for routers. A certificate is a packet of information about a router that identifies the router and supplies a public key. Certified router information will include the router id, its role, the address ranges that the router may advertise, a timestamp and the router's public key. The certificate is signed by the TE. Each router must be configured with a certificate and a TE public key to use in verifying other routers' certificates. A router PKLSA contains the certificate for that router. A router receiving a PKLSA verifies the certificate using the TE public key, and then verifies the whole LSA using the Murphy, et. al. Experimental [Page 3] RFC 2154 OSPF with Digital Signatures June 1997 router public key contained in the certificate. Successful verification provides assurance that the PKLSA is from the correct router, and that it has not been altered by any other router in the flood path. OSPF with Digital Signatures is backward compatible with standard OSPF V2 in a limited way. Within an AS there may be "signed" areas and "unsigned" areas. The behavior of a mixed AS is discussed in section 5. Digital signatures for OSPF LSAs can be implemented with the following major functions: (1) Support for a digital signature algorithm (2) Support for a signed version of all routing information LSAs (3) Support for a new LSA: Router Public Key LSA (PKLSA) (4) A mechanism for key certification and certificate distribution (5) Extra configuration data (detail in section 7): Trusted Entity (TE) information and key(s) Router certification data and key Area environment flag (signed/unsigned) Timing intervals An implementation of this design exists, based on the OSPF in Gated version 3.5Beta3. This implementation is available for use/experimentation. Please contact the authors for information. 3. LSA Processing 3.1. Signed LSA A signed LSA contains the standard OSPF V2 header and data plus key identification information, a signature length and a signature. The top bit of the LS type field is set to indicate the presence of a signature. The signature covers the LSA header (starting with the options field), the LSA data, and the key identification information and the signature length that must be appended to the LSA data. There are two exceptions to this coverage: first, an LSA created with age=MaxAge has a signature that begins with the age field (see section on maxage); second, the LSA header checksum is set to zero for the generation of the signature. To assist in parsing the message, the key id information and the signature length fields are placed at the end of the LSA, following the signature. However, the Murphy, et. al. Experimental [Page 4] RFC 2154 OSPF with Digital Signatures June 1997 message must be signed and verified with these fields immediately appended to the LSA data. This can be accomplished either by doing the sign and verify "in parts" (allowed by RSAREF), or by storing the LSA data with appended fields and the LSA signature separately in the link state database (LSDB). When a signed LSA is received, the signature can be verified using the public key of the advertising router contained in the advertising router's PKLSA. If the signature verifies, then the signed LSA is stored for use in routing calculations. If the signature verification fails, the LSA must be discarded. If the identified key is not available (in a PKLSA from the advertising router), then the signed LSA must be stored for a period of time defined by the configurable MAX_TRANSIT_DELAY interval. If the key arrives within this interval, the LSA will be processed then. If the key does not arrive within this interval, the LSA will be discarded. This delay period prevents loss of routing information due to LSAs arriving prior to their associated PKLSAs (which should not normally be the case, but could happen). If the LSA is a Router Links LSA, the router's advertised links must be checked against the allowed address ranges stored in the PKLSA for the advertising router. All network links (link types 2 and 3) must have an IP address that fits in one of the ranges defined by the list of address ranges in the PKLSA (format 7.2). If there is a link that does not fit into one of these ranges, then an error must be logged and the LSA must be discarded. Careful subnetting and corresponding ranges can provide very tight control on what is advertised. A much less restrictive, but still useful, level of control can be obtained by defining allowed address ranges for an area, so that all routers in an area could be configured with the same set. To trivially satisfy this checking, one range with a zero address and mask can be defined that contains all IP addresses. Link State Acknowledgements must be sent for all LSAs that are discarded due to verification failures, that are stored waiting for keys, and that are discarded because they are advertising a link that they are not allowed to advertise. 3.2. Router Public Key LSA (PKLSA) A Router Public Key LSA (PKLSA) is sent in the same manner as all other LSAs. This LSA contains the router's public key and identifying information that has been certified by a Trusted Entity. The router public key is used to verify signatures produced by this router. There is only one PKLSA stored per router in the LSDB for an area, so the Router Id and LS type can be used to retrieve a given PKLSA. The Router Id is stored in the PKLSA Link State Id field to Murphy, et. al. Experimental [Page 5] RFC 2154 OSPF with Digital Signatures June 1997 use in retrieving the PKLSA. Identification information in the certified data (TE Id, Rtr Key Id) can be used to uniquely identify the current router key (section 7.2). To assist in parsing the message, the router signature length and the certification length fields are at the end of the LSA, following the signature. The message must be signed and verified with these fields immediately appended to the LSA data. The router signature of the PKLSA is verified in the same manner as other signed LSAs. In addition, the certification must be verified using the referenced TE public key. If either verification fails, for any reason, the PKLSA is discarded. A successfully verified PKLSA is stored for use in verifying signed LSAs from the advertising router. For every router that this router is in contact with, there may be one PKLSA stored at any given time. Each PKLSA is uniquely identified by the values (TE Id, Rtr Key Id) in the certified data (format in 7.2). When a PKLSA arrives for a given router, and there is already a PKLSA stored for that router, the PKLSA with the most recent "Create Time" is the one kept. Whenever groups of LSAs are sent by a router (as when synchronizing databases or sending updates), the PKLSAs must be sent/requested before other LSAs to minimize the time spent processing LSAs that arrive prior to their associated keys. The PKLSA is sent at intervals like all other LSAs, and it is sent immediately if a router obtains a new key to distribute. A PKLSA is sent via OSPF flooding within an OSPF area. PKLSAs are not flooded outside an area with the exception of an Autonomous System Border Router's PKLSAs which must be flooded wherever AS external LSAs are flooded. The decision to flood or not flood can be implemented by checking the router role (Rtr, ABR, ASBR, ABR-ASBR) stored in the certified part of the PKLSA. A router may flush its keys from routing tables by flooding a PKLSA for that key with age=MaxAge. This is called premature aging of the PKLSA. A key can also be removed from routing tables (superseded) by a PKLSA from the same router, containing a valid certificate for a new key with a more recent Create Time. If a key is superseded by a more recent key it is not necessary to flush the old key with a "MaxAge" PKLSA. When a new key is received, the LSAs stored in the LSDB that are signed with the old key must be replaced within MAX_TRANSIT_DELAY. if the sending router is working properly. This is because a router distributing a new key sends all of its self-originated LSAs signed with the new key immediately after sending the new PKLSA. (See section 4.4 on Router Key Replacement). To ensure that data signed with an old (possibly subverted) key does not persist in the LSDB in Murphy, et. al. Experimental [Page 6] RFC 2154 OSPF with Digital Signatures June 1997 error, all LSAs signed with a flushed or superseded key are aged to within MAX_TRANSIT_DELAY of MaxAge. This should allow time for the new LSAs signed with the new key to arrive. If new LSAs do not arrive, or if the key has been flushed and not replaced, then the old LSA data will disappear from the LSDB in a timely fashion. Link State Acknowledgements must be sent for PKLSAs that are discarded due to verification failures or because the PKLSA was less recent than the one already stored. 3.3. MaxAge Processing The age field in the OSPF LSA header is used to keep track of how long a given LSA has been in the system. When the age field reaches MaxAge, a router stops using the LSA for routing, and it floods the MaxAge LSA to make sure that all routers stop using this LSA. In the normal course of the OSPF protocol, an LSA is always replaced by an updated version before the age reaches MaxAge, unless the advertising router fails, or changes in the AS have made the routing information in the LSA inaccurate. An LSA with age=MaxAge is either: (1) being intentionally flushed from the AS by the advertising router because the information in it is no longer accurate, or (2) an orphan LSA that has aged to MaxAge because its originating router has not refreshed it at the normal refresh intervals. The age field cannot generally be included in the signature, because it must be updated by routers other than the originating router. For the same reason, the age field is not included in the checksum computation. The age field must be protected, because if a faulty router started to age out other router's LSAs, it would effectively deny service to those other routers. To protect the age field, the signature must include the age field if and only if the originating router creates an LSA with age=MaxAge. Verification of the signature on a signed LSA must include the age field if and only if the age field value is MaxAge. In this manner, the originating router can flush an LSA, but other routers cannot. An LSA that ages to MaxAge in the LSDB of any router is still discarded by that router, but it is not synchronously flushed from the AS. Murphy, et. al. Experimental [Page 7] RFC 2154 OSPF with Digital Signatures June 1997 An LSA will be removed from a router's Link State Database in one of two ways: 1) the router receives a version of the LSA with the age field set to MaxAge and a valid signature that covers the age field, or 2) the LSA incrementally reaches MaxAg