idnits 2.17.1 draft-jones-msgmib-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 113 instances of too long lines in the document, the longest one being 50 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 342: '..." is reasonable, but the protocol MUST...' RFC 2119 keyword, line 376: '...of-domain access be treated as a MAY ?...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 21 has weird spacing: '... Drafts are ...' == Line 22 has weird spacing: '...cuments of t...' == Line 23 has weird spacing: '... groups may ...' == Line 27 has weird spacing: '... Drafts may ...' == Line 28 has weird spacing: '...iate to use ...' == (15 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9540 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 54 looks like a reference -- Missing reference section? '2' on line 58 looks like a reference -- Missing reference section? '3' on line 61 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSGMIB Working Group (proposed) G. Jones 3 INTERNET-DRAFT MITRE Corporation 4 [gbjones@mitre.org] 6 Bruce Ernst 7 Lotus Development Corporation 8 [bernst@softsw.ssw.com] 10 Greg Vaudreuil 11 Octel Network Service 12 [greg.vaudreuil@octel.com] 14 March 1998 16 Message Tracking Model 17 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its Areas, 23 and its Working Groups. Note that other groups may also distribute 24 working documents as Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six 27 months. Internet Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other than as a "working 30 draft" or "work in progress." 32 To learn the current status of any Internet-Draft, please check the 33 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 34 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 35 munnari.oz.au. 37 Abstract 39 This document defines an SNMP-based message tracking model for 40 electronic messaging management usage. Message tracking is the 41 ability to find out, after the fact, the path that a particular message 42 took through the messaging system, the current status of that 43 message, and its characteristics. 45 This document defines the model, architecture, and requirements for message 46 tracking. An SNMP MIB to support message tracking is found in a related 47 document. 49 1. The SNMP Network Management Framework. 51 The major components of the SNMP Network Management framework are 52 described in the documents listed below. 54 o RFC 1902 [1] defines the Structure of Management Information 55 (SMI), the mechanisms used for describing and naming objects 56 for the purpose of management. 58 o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed 59 objects (MO) for the Internet suite of protocols. 61 o RFC 1905 [3] defines the protocol used for network access to 62 managed objects. 64 o [ADD SNMPv3 HERE] 66 The framework is adaptable/extensible by defining new MIBs to suit the 67 requirements of specific applications/protocols/situations. 69 Managed objects are accessed via a virtual information store, the MIB. 70 Objects in the MIB are defined using the subset of Abstract Syntax 71 Notation One (ASN.1) defined in the SMI. In particular, each object type 72 is named by an OBJECT IDENTIFIER, which is an administratively assigned 73 name. The object type together with an object instance serves to 74 uniquely identify a specific instantiation of the object. For human 75 convenience, often a textual string, termed the descriptor, is used to 76 refer to the object type. 78 2. Message Tracking and the Need for Message Tracking 80 Message tracking refers, in its simplest form, to determining the path a message 81 has taken, its current location, and its characteristics. This capability is 82 analogous to the service provided by carriers of conventional paper mail - the 83 ability to quickly locate where a package is, and to determine whether or not 84 the package has been delivered to its destination. This document discusses a 85 specific SNMP-based per-message mechanism to query the messaging system 86 to perform message tracking. SNMP is an established network and application 87 management technology that provides an abundance of user tools and a cross- 88 vendor, cross-technology ubiquity. As SNMP continues to evolve (e.g. 89 SNMPv3), the mechanisms in this document will leverage those new 90 technologies. Use of the approach in this document will allow development of 91 message tracking applications that can operate in a multi-vendor messaging 92 environment: 94 o When there is a lack of trust in the messaging system, such as when an 95 originator claims a message failed to be delivered, the point of failure may be 96 isolated. This includes messages that were never delivered of messages that were 97 delivered incorrectly. Message tracking thus adds to the overall reliability of the 98 mail system; 100 o Per-message information can be used for accounting, billing, and performance 101 purposes. Traffic can be itemized on a per-origin or per-destination basis by 102 system or originator. This typically involves two steps - collection of message 103 traffic data, followed by the generation of appropriate reports and/or billing. 105 o Message tracking information adds security in that the origins of potential 106 security threats can be more precisely determined. If a system were flooded 107 with traffic, for instance, the origin of this traffic would become known. 108 Message tracking information is suitable for routine securty audits containing 109 the details of messaging traffic over specific time intervals; 111 o The message tracking MIB would aid in message loop detection, since unique 112 message identifiers of looping messages, when these exist, would be recorded 113 multiple times; 115 o Performance characteristics about the type of messaging traffic could be 116 determined, such as when an inbound message causes the creation of multiple 117 outbound messages, and the percentage of messages that were actually delivery 118 reports or receipts. This is valuable for performance measurement, among other 119 reasons; 121 o Standardized message tracking information acts as a bridge between dissimilar 122 messaging systems and dissimilar messaging communities; 124 3. Requirements 126 The following requirements and definitions are agreed upon by the group: 128 o A query is a question that a user asks to get message tracking 129 information. One or more SNMP operations may be necessary to complete a 130 query. 132 o A user is either an individual mail user or a mail system 133 administrator. 135 o A message tracking domain consists of all MTAs under the control of 136 an administrator. 138 o The user should be able to query based upon 139 - unique message identifier 140 - recipient 141 - originator 142 - time range (start time-to-end time) 144 o The user should be able to use wild-carded values. 146 o The user should be able to narrow the scope of the query using 147 multiple criteria and combinations of criteria from items (3) and (4). 149 o End users should only be able to get responses to queries about mail 150 they have sent or received. 152 o Privileged persons (system administrators) should be able to get 153 responses to queries about mail sent by or received by people for whom 154 they are designated or trusted administrators. (Remember one may be a 155 self-appointed yet legitimate system administer for a domain of only 2 156 mailboxes....) 158 o "Queries" that span domain boundaries have to be restricted to 159 traffic that left one domain for another 161 o The system must scale to the size of the email Internet 163 o The system must respond within a reasonable period to any request. 164 We would propose 10 seconds for a 3 hop path as reasonable. 166 o Queries should place no unreasonable burden upon the managed 167 systems. We propose an assumption of 1 query per 5,000 messages for 168 purpose of evaluating this requirement. 170 [THE FOLLOWING MATERIAL WAS PREVIOUSLY POSTED AND 171 MUST AGREE WITH THE ABOVE LIST] 173 The Messaging Manager must be able to trace a message on behalf of a user, to 174 discover whether the message was in fact delivered, or to determine where the 175 message may be stuck in the system. Message Tracking is often required more 176 by end users during times when they distrust the System - when moving from a 177 real-time delivery system to a store-and-forward system, or when the System is 178 new, or is undergoing significant change. The management information 179 described in this document provides for tracking on a per-message, per-recipient 180 basis. A message's current status, as well as the complete path taken by a 181 message, on a per-recipient basis, can be obtained by consulting Messaging 182 Management agents which comply with this specification. 184 As the Messaging System shifts to being used for applications which require 185 higher reliability (e.g., EDI), Message Tracking will be required to assure the 186 users that the requisite reliability is indeed in place. If a question of "lost mail" 187 arises, the mail manager must be able to track the message from its entry into 188 the mail system until it is delivered, non-delivered, or passes outside the 189 management sphere into another management sphere. The track must be able 190 to cross multiple messaging components from multiple vendors. There must be 191 provision for passing the query to the appropriate authority in the next 192 management sphere so that the track can be continued there. Cross-jurisdictional, 193 agent-based message tracking, as described in this document, addresses this 194 equirement. In addition to being multi-component and multi-vendor, this 195 specification also addresses multiple management technologies. 197 Messages must be trackable from point of origin, based on the sender providing 198 the posting date and time and destination. This includes one Mail Manager 199 asking the Mail Manager of the next management sphere to continue the track 200 of a message entering that sphere at a specific date and time from a stated point 201 of origin. Message tracking queries, filtered based on time and recipient (i.e., in 202 the case when a specific message ID is not known) is included in this 203 specification. Note however that support for this sort of filtering is optional. 205 Messages must also be trackable across domains - from one enterprise, across 206 the public wide-area network, and into the destination enterprise. 208 4. Architecture 210 Let [us] define three actors for the message trace model. 212 The first is the MTA that may have knowledge of a message and is 213 the target of the query. 215 The second is the email system used to send messages. This 216 sending email system is broadly defined such that sending system is able 217 to provide to the originator or recipient key information necessary to 218 initiate a trace. This information may include anything available in a 219 message header including date, recipient, and message-ID plus important 220 attributes such as the first-hop MTA the message was sent to. This is 221 more broadly defined than a typical email user agent in that the senders 222 email gateway may be considered part of the sending system. (For this 223 model, the sendmail that adds the date and message-ID is part of the 224 sending "system". The proprietary-to-Internet gateway that creates 225 internet-legal email addresses and message-id's is also part of the 226 sending system). 228 The third is a message tracking client. This may be integrated 229 into the email client, stand-alone, hosted on a web server, or otherwise 230 able to generate an SNMP query in response to input from an end user or 231 administrator. 233 The following "use case" illustrate the relationships between 234 the actors. 236 a. End users creates a email messages from the sending system 237 through one or more MTA's. 239 b. The originator desires a trace and forms a query from the 240 message tracking client using available from the message sending system. 242 c. The message trace clients issues the query to the first MTA 243 in the path. If successful, the MTA returns information regarding the 244 message including the canonical name of the next MTA in the path. The 245 message trace issues a subsequent query against the next MTA in the path 246 until either the query fails of the MTA indicates the delivery was 247 successful. 248 [NOTE: You need to expand item 3 to add the following: a utility might 249 also want to visit a list of MTAs simulataneously, in parallel, and later 250 correlate the information about path in a central place. You also might 251 not know the starting point, so you have to kick off a parallel trace to a 252 (hopefully limited) number of candidate MTAs in order to find out the 253 starting point. Thirdly, it might make sense to set up a periodic "pull" of 254 information from a list of MTAs at predefined intervals.] 256 The Outbox Model. 258 In the message trace model, the sending system is considered to 259 be atomic. In the current universe, there are various boundaries 260 between the user agent and the balance of the sending system. In some 261 cases the sending system is an all-in-one mail system. In others the 262 traditional Unix email client/Sendmail split is present. In many 263 corporate and proprietary email systems, the client, intermediate post 264 offices, and the Internet gateway together are a sending system. 265 Further, these systems have varying trust relationships between the 266 various part of the system. 268 It may be useful to define a separate model for those 269 implementations where the user interface portion of the sending system 270 does not have sufficient information to create a message trace query and 271 must rely upon a repository of general information stored elsewhere in 272 the sending system. 274 If one defines there to be an outbox agent as part of the 275 balance of the message sending system, one may consider there to be a 276 query protocol between the message trace client and the outbox agent. 277 This protocol must provide an authenticated link between the user and 278 the information necessary to create a message trace query. 280 Okay then, have we answered all of the following questions (probably not yet): 282 a. What components are in the messaging system ? The management system ? Define each one 283 (MTA, UA, agent, manager). Is a "message store" the same as an MTA for our purposes ? 284 Is a "gateway" the same as an MTA ? What components are out of scope ? 285 b. What does it mean to "track" a message ? What is the path of the message through the 286 components; e.g., what are we tracking and what are we not tracking ? (the charter says 287 we only track a message from the time an MTA accepts it to the time it is handed off to 288 something other than an MTA. This should be restated here) 289 c. What is routing ? What is a "previous hop" MTA and what is a "next hop" MTA ? 290 d. What is a MIB and what is SNMP ? 291 e. Which versions of SNMP are we using (assume both v1 and v3) and what are their differences ? 292 f. Are we addressing control functions; that is, the ability to control individual messages (beware, 293 if this genie gets out of the bottle I'm going to ask whoever proposes it to write a separate 294 document) 296 5. Security Topics 298 5.1 Tracking under SNMPv1 300 a. What technical information is available in SNMPv1 to support security ? We may have to mention 301 the definition of community string, access controls, additional MIB variables to support security 302 since MIB variables in v1 might have to serve as replacement for functions in v3 303 b. What types of users will be allowed to track messages ? Perhaps there should be two levels of 304 access: an "ordinary" user and an "adminstrative" user. For example, the ordinary user will have 305 to have an exact-match message ID; the administrative user will be allowed to get messages using 306 the delivery time and other people's e-mail addresses 307 c. An SNMPv1 community string serves as a password. If an e-mail user asks his/her provider to 308 track a message given a (sufficiently long) message ID and a community string, isn't this the same 309 as or better than a customer calling his/her bank with a social security ID and a mother's maiden 310 name on an unsecured phone line ? Note: such a scheme is still vulnerable to replay attack. 311 What about router management today. The control of IP routers is performed using community 312 strings in the clear, so why not message tracking ? 314 d. Can we restrict requests to certain recipient names or ranges of message IDs ? For example, bar 315 the ability to track messages going to/from the president of the company ? Could high-importance 316 messages be assigned IDs in a particular range to soignify their importance (note this is probably 317 too complicated to implement) ? 319 5.2 Tracking under SNMPv3 321 At the moment, the SNMPv3 security model that exists (user-based) assumes 322 that there are a countable number of interested parties, and an agent will have 323 a trust relationship with each one. Access by "a fairly sophisticated application" may mean 2 different things, like this: 325 o User -----|-----> Application -----> SNMP agent 326 trust boundary 327 non-SNMP proto SNMP 329 o User ---------> Application -----|----> SNMP agent 330 anything trust boundary 331 SNMP 333 In the first case, the application is trusted by the SNMP agent, and has the job of 334 verifying what the user is allowed to see. In this case, we should be designing 335 the non-SNMP protocol, not the MIB, since that's the interface that has to be 336 open. 338 In the second case, the application has exactly the same trust as the user, and 339 adding it into the chain contributes *nothing* to the trust model; the 340 application is, conceptually, just part of the user's User Interface. 342 The idea of "locally applied policy" is reasonable, but the protocol MUST 343 supply enough handles for at least ONE reasonable security policy 344 to work (apart from "everyone can see everything). 346 That said, we must look at the following: 348 a. What technical information is available in SNMPv3 to support security ? SNMPv3 has 349 authentication features (USM) and access controls (VACM). Additional MIBs were defined 350 to support security, we think 351 b. We still want to have levels of users. Here is an example: when there is no authentication, use the 352 scheme defined above for SNMPv1. When an "ordinary" user authenticates, allow that user to 353 track only those messages he/she is the originator or recipient of. When an "administrative" 354 user authenticates, allow tracking using full range of criteria including time ranges and wild-cards. 355 c. Note about the authentication feature in SNMPv3: when a user requests to authenticate, asks to 356 track a message, claims to be the originator of the message, and supplies the e-mail address to 357 be tracked, there has to be a way to correlate the authentication key with the e-mail address of 358 the requestor 360 5.3 For both v1 and v3 362 a. What is the role of access control ? Can we use built-in access control mechanisms to restrict access 363 to certain ranges of OIDs for certain lists of users ? 364 b. What is the role of firewalls and transport layer security ? Is there something we can leverage here ? 365 c. We can restrict the information that queries contain but we can also restrict the information returned 366 in the response; for instance, I can limit the response to contain only the message disposition status (it 367 got there or it didn't) if I really wanted to be fussy about it 369 6. Inter-domain Tracking 371 a. There are two walls we hit here: when a request to track a message reaches a "domain boundary" it 372 gets complicated EITHER because the IP address of the next hop MTA is not known (needs to be 373 looked up) OR access to the agent at the next hop is denied. In the first case, should mention that 374 there must be a way to look these things up (DNS, SQL database, table lookup) ? For the second case, 375 read on... 376 b. Should out-of-domain access be treated as a MAY ? 377 c. Do we need to define a class of user like an "out of domain" user, who can only track messages 378 entering or leaving their domain ? Could we use the domain names in the e-mail addresses they are 379 tracking to support this ? Can we limit the amount of information in the query response so we don't 380 give away important operational information ? 381 d. When a tracking request reaches a domain "boundary", do we want to issue a referral such as the 382 e-mail address of an administrator, a phone number, a person's name, or an IP address ? 383 e. Should we specify that each domain supply a special "boundary agent", which, when it receives a 384 request, queries other agents in the domain and correlates the responses ? 385 f. In all cases, should we declare that the responsiblity for delivering a message stops at the domain 386 boundary ? 388 7. Authors Addresses 390 Gordon Jones 391 MITRE Corporation 392 1820 Dolley Madison Blvd. 393 McLean, VA 22102-3481 395 Phone: +1 703 883 7670 396 E-Mail: gbjones@mitre.org 398 Bruce Ernst 399 Lotus Development Corporation 401 Phone: +1 610 251 3404 402 E-Mail: bernst@softsw.ssw.com 404 Gregory M. Vaudreuil 405 Octel Network Services 406 17080 Dallas Parkway 407 Dallas, TX 75248-1905 409 Phone/Fax: +1-214-733-2722 410 E-Mail: Greg.Vaudreuil@Octel.Com