idnits 2.17.1 draft-taylor-midcom-diameter-eval-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-taylor-midcom-diameter-eval-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-taylor-midcom-diameter-eval-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-taylor-midcom-diameter-eval-', but the file name used is 'draft-taylor-midcom-diameter-eval-01' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 249: '...lterRule filters MUST follow the forma...' RFC 2119 keyword, line 277: '... The bit width MUST be valid for the...' RFC 2119 keyword, line 278: '... IP version and the IP number MUST...' RFC 2119 keyword, line 382: '...ket that the access device MUST always...' RFC 2119 keyword, line 388: '... MUST terminate the session. An acc...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 2002) is 8045 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 122 looks like a reference -- Missing reference section? '2' on line 459 looks like a reference -- Missing reference section? '5' on line 60 looks like a reference -- Missing reference section? '3' on line 71 looks like a reference Summary: 6 errors (**), 1 flaw (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Tom Taylor 3 Document: draft-taylor-midcom-diameter-eval- Nortel Networks 4 01.txt 5 Expires: October 2002 April 2002 7 Evaluation Of DIAMETER Against MIDCOM Requirements 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document is submitted as part of the Midcom protocol selection 32 process. It evaluates the suitability of the Diameter protocol as a 33 transport for Midcom. The general conclusions are: 35 . the Diameter architecture may be too heavy for the Midcom 36 application, although this is a matter for discussion. It is 37 clear in any event that much of the Diameter base is not 38 needed; 40 . a new application extension to Diameter would have to be 41 defined to meet Midcom's requirements; 43 . with these reservations, the protocol is a good fit to Midcom 44 requirements. 46 This version contains added details describing how to use Diameter 47 to meet the requirements. 49 against MIDCOM requirements 51 1. Introduction 53 1.1 Background 55 The Midcom Working Group has created a set of requirements for a 56 protocol to control Middleboxes [1]. The Working Group is currently 57 evaluating a number of protocols as a basis for development of the 58 Midcom protocol. Diameter [2] is one of the candidates. This 59 document reports on how well Diameter meets the Midcom requirements, 60 using the template provided in [5]. 62 1.2 Diameter Architecture 64 Diameter is designed to support AAA for network access. It is meant 65 to operate through networks of Diameter nodes, which both act upon 66 and route messages toward their final destinations. Endpoints are 67 characterized as either clients, which perform network access 68 control, or servers, which handle authentication, authorization and 69 accounting requests for a particular realm. Intermediate nodes 70 perform relay, proxy, redirect, and translation services. Design 71 requirements for the protocol [3] include robustness in the face of 72 bursty message loads and server failures, resistance to specific DOS 73 attacks and protection of message contents, and extensibility 74 including support for vendor-specific attributes and message types. 76 The protocol is designed as a base protocol to be supported by all 77 implementations, plus extensions devoted to specific applications. 78 Messages consist of a header and an aggregation of "Attribute-Value 79 Pairs (AVPs)", each of which is a tag-length-value construct. The 80 header includes a command code, which determines the processing of 81 the message and what other AVP types must or may be present. AVPs 82 are strongly typed. Some basic and compound types are provided by 83 the base protocol specification, while others may be added by 84 application extensions. One of the types provided in the base is 85 the IPFilterRule, which may be sufficient to express the Policy 86 Rules that Midcom deals with. 88 Messaging takes the form of request-answer exchanges. Some 89 exchanges may take multiple round-trips to complete. The protocol 90 is connection-oriented at both the transport and application levels. 91 In addition, the protocol is tied closely to the idea of sessions, 92 which relate sequences of message exchanges through use of a common 93 session identifier. Each application provides its own definition of 94 the semantics of a session. Multiple sessions may be open 95 simultaneously. 97 1.3 Comparison With MIDCOM Architectural Requirements 99 The Midcom Agent does not perform the functions of a Diameter 100 client, nor does the Middlebox support the functions of a Diameter 101 server. Thus the Midcom application would introduce two new types 102 of endpoints into the Diameter architecture. Moreover, the Midcom 103 against MIDCOM requirements 105 requirements do not at this time imply any type of intermediate 106 node. 108 A general assessment might be that Diameter meets and exceeds Midcom 109 architectural requirements. The connection orientation may be too 110 heavy for the number of relationships the Middlebox must support: 111 this is a point for discussion. Certainly the focus on 112 extensibility, request-response messaging orientation, and treatment 113 of the session, are all well-matched to what Midcom needs. At this 114 point, MIDCOM is focussed on simple point-to-point relationships, so 115 the proxying and forwarding capabilities provided by Diameter are 116 not needed. Most of the commands and AVPs defined in the base 117 protocol are also surplus to MIDCOM requirements. 119 2. Detailed Comparison With Requirements 121 indicates the requirement documented in section x.x.x of 122 [1]. 124 2.1 Requirements Fully Met 126 <2.1.1> Ability to establish association between Agent and 127 Middlebox. 128 ---------------------------------------------------------- 130 Although this is out of scope, the Diameter specification describes 131 several ways to discover a peer. Having done so, a Diameter node 132 establishes a transport connection (TCP, TLS, or SCTP) to the peer. 133 The two peers then exchange Capability Exchange Request/Answer 134 messages to identify each other and determine the Diameter 135 applications each supports. 137 If the connection between two peers is lost, Diameter prescribes 138 procedures whereby it may be re-established. To ensure that loss of 139 connectivity is detected quickly, Diameter provides the Device- 140 Watchdog Request/Answer messages, to be used when traffic between 141 the two peers is low. 143 Diameter provides an extensive state machine to govern the 144 relationship between two peers. 146 <2.1.2> Agent can relate to multiple Middleboxes. 147 ------------------------------------------------- 149 Diameter allows connection to more than one peer (and encourages 150 this for improved reliability). Whether the Diameter connection 151 state machine is too heavy to support the number of connections 152 needed is a matter for discussion. 154 against MIDCOM requirements 156 <2.1.3> Middlebox can relate to multiple Agents. 157 ------------------------------------------------ 159 See previous answer. The Middlebox and Agent play symmetric roles 160 as far as Diameter peering is concerned. 162 <2.1.4> Deterministic outcome when multiple requests are presented 163 to the Middlebox simultaneously. 164 ------------------------------------------------------------------ 166 Diameter depends partly upon the transport protocol to provide flow 167 control when the server becomes heavily loaded. It also has 168 application-layer messaging to indicate that it is too busy or out 169 of space (DIAMETER_TOO_BUSY and DIAMETER_OUT_OF_SPACE result codes). 171 <2.1.6> Middlebox status report. 172 -------------------------------- 174 Diameter provides a number of response codes by means of which a 175 server can indicate error conditions reflecting status of the server 176 as a whole. The Disconnect-Peer-Request provides a means in the 177 extreme case to terminate a connection with a peer gracefully, 178 informing the other end about the reason for the disconnection. 180 <2.1.7> Middlebox can generate unsolicited messages. 181 ---------------------------------------------------- 183 The Diameter protocol permits either peer in a connection to 184 originate transactions. Thus the protocol supports Middlebox- 185 originated messages. 187 <2.1.8> Mutual authentication. 188 ------------------------------ 190 The Diameter base protocol assumes that messages are secured by 191 using either IP Security or TLS. Diameter requires that when using 192 the latter, peers must mutually authenticate themselves. 194 <2.1.9> Termination of session (connection, in Diameter terminology) 195 by either party. 196 -------------------------------------------------------------------- 198 Either peer in a connection may issue a Disconnect-Peer-Request to 199 end the connection gracefully. 201 <2.1.10> Indication of success or failure. 202 ------------------------------------------ 204 Every Diameter request is matched by a response, and this response 205 contains a result code as well as other information. 207 against MIDCOM requirements 209 <2.1.11> Version interworking. 210 ------------------------------ 212 The Capabilities Exchange Request/Answer allows two peers to 213 determine information about what each supports, including protocol 214 version and specific applications. 216 <2.1.12> Deterministic behaviour in the presence of overlapping 217 rules. 218 --------------------------------------------------------------- 220 The IPFilterRule type specification, which would probably be used as 221 the type of a Policy Rule AVP, comes with an extensive semantic 222 description which provides for a deterministic outcome, but one 223 which the individual Agent cannot know unless it knows all of the 224 Policy Rules installed on the Middlebox. The IPFilterRule type is 225 defined in [2] as follows: 227 IPFilterRule 229 The IPFilterRule format is derived from the OctetString AVP Base 230 Format. It uses the UTF-8 encoding and has the same requirements as 231 the UTF8String. Packets may be filtered based on the following 232 information that is associated with it: 234 Direction (in or out) 235 Source and destination IP address (possibly masked) 236 Protocol 237 Source and destination port (lists or ranges) 238 TCP flags 239 IP fragment flag 240 IP options 241 ICMP types 243 Rules for the appropriate direction are evaluated in order, with the 244 first matched rule terminating the evaluation. Each packet is 245 evaluated once. If no rule matches, the packet is dropped if the 246 last rule evaluated was a permit, and passed if the last rule was a 247 deny. 249 IPFilterRule filters MUST follow the format: 251 action dir proto from src to dst [options] 253 action permit - Allow packets that match the rule. 254 deny - Drop packets that match the rule. 256 dir "in" is from the terminal, "out" is to the 257 terminal. 259 proto An IP protocol specified by number. The "ip" 260 keyword means any protocol will match. 262 against MIDCOM requirements 264 src and dst
[ports] 266 The
may be specified as: 268 ipno An IPv4 or IPv6 number in dotted- 269 quad or canonical IPv6 form. Only 270 this exact IP number will match the 271 rule. 273 ipno/bits An IP number as above with a mask 274 width of the form 1.2.3.4/24. In 275 this case, all IP numbers from 276 1.2.3.0 to 1.2.3.255 will match. 277 The bit width MUST be valid for the 278 IP version and the IP number MUST 279 NOT have bits set beyond the mask. 281 For a match to occur, the same IP 282 version must be present in the 283 packet that was used in describing 284 the IP address. To test for a 285 particular IP version, the bits part 286 can be set to zero. The keyword 287 "any" is 0.0.0.0/0 or the IPv6 288 equivalent. The keyword "assigned" 289 is the address or set of addresses 290 assigned to the terminal. For IPv4, 291 a typical first rule is often 292 "deny in ip! assigned" 294 The sense of the match can be inverted by 295 preceding an address with the not modifier (!), 296 causing all other addresses to be matched 297 instead. This does not affect the selection of 298 port numbers. 300 With the TCP, UDP and SCTP protocols, optional 301 ports may be specified as: 303 {port|port-port}[,ports[,...]] 305 The '-' notation specifies a range of ports 306 (including boundaries). 308 Fragmented packets that have a non-zero offset 309 (i.e. not the first fragment) will never match 310 a rule that has one or more port 311 specifications. See the frag option for 312 details on matching fragmented packets. 314 options: 316 frag Match if the packet is a fragment and this is not 317 against MIDCOM requirements 319 the first fragment of the datagram. frag may not 320 be used in conjunction with either tcpflags or 321 TCP/UDP port specifications. 323 ipoptions spec 324 Match if the IP header contains the comma 325 separated list of options specified in spec. The 326 supported IP options are: 328 ssrr (strict source route), lsrr (loose source 329 route), rr (record packet route) and ts 330 (timestamp). The absence of a particular option 331 may be denoted with a '!'. 333 tcpoptions spec 334 Match if the TCP header contains the comma 335 separated list of options specified in spec. The 336 supported TCP options are: 338 mss (maximum segment size), window (tcp window 339 advertisement), sack (selective ack), ts (rfc1323 340 timestamp) and cc (rfc1644 t/tcp connection 341 count). The absence of a particular option may 342 be denoted with a '!'. 344 established 345 TCP packets only. Match packets that have the RST 346 or ACK bits set. 348 setup TCP packets only. Match packets that have the SYN 349 bit set but no ACK bit. 351 tcpflags spec 352 TCP packets only. Match if the TCP header 353 contains the comma separated list of flags 354 specified in spec. The supported TCP flags are: 356 fin, syn, rst, psh, ack and urg. The absence of a 357 particular flag may be denoted with a '!'. A rule 358 that contains a tcpflags specification can never 359 match a fragmented packet that has a non-zero 360 offset. See the frag option for details on 361 matching fragmented packets. 363 icmptypes types 364 ICMP packets only. Match if the ICMP type is in 365 the list types. The list may be specified as any 366 combination of ranges or individual types 367 separated by commas. Both the numeric values and 368 the symbolic values listed below can be used. The 369 supported ICMP types are: 371 echo reply (0), destination unreachable (3), 372 against MIDCOM requirements 374 source quench (4), redirect (5), echo request 375 (8), router advertisement (9), router 376 solicitation (10), time-to-live exceeded (11), IP 377 header bad (12), timestamp request (13), 378 timestamp reply (14), information request (15), 379 information reply (16), address mask request (17) 380 and address mask reply (18). 382 There is one kind of packet that the access device MUST always 383 discard, that is an IP fragment with a fragment offset of one. This 384 is a valid packet, but it only has one use, to try to circumvent 385 firewalls. 387 An access device that is unable to interpret or apply a deny rule 388 MUST terminate the session. An access device that is unable to 389 interpret or apply a permit rule MAY apply a more restrictive rule. 390 An access device MAY apply deny rules of its own before the supplied 391 rules, for example to protect the access device owner's 392 infrastructure. 394 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and 395 the ipfw.c code may provide a useful base for implementations. 397 <2.2.1> Extensibility. 398 ---------------------- 400 Diameter provides a great deal of flexibility for extensions, 401 including allowance for vendor-defined commands and AVPs and the 402 ability to flag each AVP as must-understand or ignorable if not 403 understood. 405 <2.2.3> Ruleset groups. 406 ----------------------- 408 Diameter allows message syntax definitions where multiple instances 409 of the same AVP (for example, a Policy Rule AVP whose syntax and 410 low-level semantics are defined by the IPFilterRule type definition) 411 may be present. If a tighter grouping is required, the set of 412 Diameter base types includes the Grouped type. Midcom can choose 413 how to make use of these capabilities to meet the rulreset group 414 requirement when defining its application extension to the Diameter 415 protocol as discussed below. 417 <2.2.4> Lifetime extension. 418 --------------------------- 420 The Diameter concept of a session includes the session lifetime, 421 grace period, and lifetime extension. It may make sense to 422 associate the Diameter session with the lifetime of a Midcom Policy 423 Rule, in which case support for lifetime extension comes ready-made. 425 against MIDCOM requirements 427 <2.2.6> Actionable failure reasons. 428 ----------------------------------- 430 Diameter provides an extensive set of failure reasons in the base 431 protocol. 433 <2.2.7> Multiple Agents operating on the same ruleset. 434 ------------------------------------------------------ 436 Diameter itself offers no impediment to such an operation. The 437 Midcom application specification must avoid introducing such an 438 impediment. 440 <2.2.11> More precise rulesets contradicting overlapping rulesets. 441 ------------------------------------------------------------------ 443 Allowed by the IPFilterRule semantics described above. 445 <2.3.1> Message authentication, confidentiality, and integrity. 446 --------------------------------------------------------------- 448 Diameter relies on either IPSEC or TLS for these functions. 450 <2.3.2> Optional confidentiality. 451 --------------------------------- 453 Implementation support of IPSEC ESP in Diameter applications is not 454 optional. Deployment of either IPSEC or TLS is optional. 456 <2.3.3> Operation across untrusted domains. 457 ------------------------------------------- 459 The Diameter specification [2] recommends the use of TLS across 460 untrusted domains. 462 <2.3.4> Mitigation of replay attacks. 463 ------------------------------------- 465 Diameter requires that implementations support the replay protection 466 mechanisms of IPSEC. 468 2.2 Requirements Partially Met 470 Requirements have been placed here in most cases because it will be 471 necessary to define a Midcom application extension of Diameter, and 472 the satisfaction of the requirements depends on proper definition of 473 the messages and AVPs in that extension. 475 against MIDCOM requirements 477 <2.1.5> Known and stable state. 478 ------------------------------- 480 Diameter documentation does not discuss the degree of atomicity of 481 message processing, so this would have to be specified in the Midcom 482 extension. 484 <2.2.2> Support of multiple Middlebox types. 485 -------------------------------------------- 487 Any necessary additional AVPs or values must be specified as part of 488 the Midcom application extension (see <2.2.8> below). 490 <2.2.5> Mandatory/optional nature of unknown attributes. 491 -------------------------------------------------------- 493 Indication of the mandatory or optional status of AVPs is fully 494 supported, provided it is enabled in the AVP definition. No 495 guidance is imposed regarding the return of diagnostic information 496 for optional AVPs. 498 <2.2.8> Transport of filtering rules. 499 ------------------------------------- 501 While Diameter defines the promising IPFilterRule data type (see 502 2.1.12 above), there is no existing message which would convey this 503 to a Middlebox along with other Midcom-required attributes. A new 504 Midcom application extension of Diameter would have to be defined. 506 <2.2.9> Mapped port parity. 507 --------------------------- 509 This capability is not part of the current IPFilterRule type 510 definition. Rather than modify the IPFilterRule type, Midcom could 511 group it with other AVPs which add the missing information. 513 <2.2.10> Consecutive range of port numbers. 514 ------------------------------------------- 516 This capability is not part of the current IPFilterRule type 517 definition. Rather than modify the IPFilterRule type, Midcom could 518 group it with other AVPs which add the missing information. 520 2.3 Requirements Not Met 522 None. 524 against MIDCOM requirements 526 References 528 1. R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 529 Communications (midcom) Protocol Requirements", draft-ietf- 530 midcom-requirements-05.txt (approved as RFC), November 2001. 532 2. P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, 533 "Diameter Base Protocol", draft-ietf-aaa-diameter-10.txt, IETF 534 work in progress, April 2002. 536 3. P. Calhoun, G. Zorn, P. Pan, H. Akhtar, "Diameter Framework 537 Document", draft-ietf-aaa-diameter-framework-01.txt, IETF work 538 in progress, March 2001. 540 4. P. Calhoun, W. Bulley, A. Rubens, J. Haag, G. Zorn, D. Spence, 541 "Diameter NASREQ Application", draft-ietf-aaa-diameter-nasreq- 542 09.txt, IETF work in progress, March 2002. 544 5. M. Barnes, "MIDCOM Protocol Evaluation Template", draft-midcom- 545 protocol-eval-template.txt, March 2002. 547 Author's Addresses 549 Tom Taylor 550 Nortel Networks 551 1852 Lorraine Ave. 552 Ottawa, Ontario, Phone: +1 613 736 0961 553 Canada K1H 6Z8 Email: taylor@nortelnetworks.com