idnits 2.17.1 draft-stiemerling-midcom-simco-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2920. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 6 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([RFC3989]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2192 has weird spacing: '...version param...' == Line 2388 has weird spacing: '... tuple is re...' == Line 2677 has weird spacing: '...uration fails...' -- 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 (December 2005) is 6707 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: 'RFC3489' is mentioned on line 2815, but not defined ** Obsolete undefined reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Downref: Normative reference to an Informational RFC: RFC 3234 ** Downref: Normative reference to an Informational RFC: RFC 3303 ** Downref: Normative reference to an Informational RFC: RFC 3424 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3989 (Obsoleted by RFC 5189) Summary: 19 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Stiemerling 2 Document: draft-stiemerling-midcom-simco-08.txt J. Quittek 3 Expires: May 2006 NEC Europe Ltd. 4 C. Cadar 6 December 2005 8 Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 10 draft-stiemerling-midcom-simco-08.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a protocol for controlling middleboxes such 42 as firewalls and network address translators. It is a fully 43 compliant implementation of the MIDCOM semantics described in 44 [RFC3989]. Compared to earlier experimental versions of the SIMCO 45 protocol, this version 3 uses binary message encodings in order to 46 reduce resource requirements. 48 Table of Contents 50 1 Introduction ................................................. 5 51 1.1 Terminology ................................................ 5 52 1.2 Binary Encodings ........................................... 5 53 2 Compliance with MIDCOM Protocol Semantics .................... 6 54 3 SIMCO Sessions ............................................... 6 55 4 SIMCO Message Components ..................................... 7 56 4.1 Message Types .............................................. 7 57 4.2 The SIMCO Header ........................................... 8 58 4.2.1 Basic Message Types ...................................... 8 59 4.2.2 Message Sub-types for Requests and Positive Replies ...... 8 60 4.2.3 Message Sub-types for Negative Replies ................... 9 61 4.2.4 Message Sub-types for Notifications ...................... 10 62 4.2.5 Transaction Identifier ................................... 10 63 4.3 The SIMCO Payload .......................................... 10 64 4.3.1 SIMCO Protocol Version Attribute ......................... 11 65 4.3.2 Authentication Attributes ................................ 11 66 4.3.3 Middlebox Capabilities Attribute ......................... 12 67 4.3.4 Policy Rule Identifier Attribute ......................... 13 68 4.3.5 Group Identifier Attribute ............................... 14 69 4.3.6 Policy Rule Lifetime Attribute ........................... 14 70 4.3.7 Policy Rule Owner Attribute .............................. 14 71 4.3.8 Address Tuple Attribute .................................. 15 72 4.3.9 PRR Parameter Set Attribute .............................. 16 73 4.3.10 PER Parameter Set Attribute ............................. 18 74 5 SIMCO Message Formats ........................................ 18 75 5.1 Protocol Error Replies and Notifications ................... 19 76 5.1.1 BFM Notification ......................................... 19 77 5.1.2 Protocol Error Negative Replies .......................... 19 78 5.2 Session Control Messages ................................... 20 79 5.2.1 SE Request ............................................... 20 80 5.2.2 SE Positive Reply ........................................ 20 81 5.2.3 SA Positive Reply ........................................ 21 82 5.2.4 SA Request ............................................... 21 83 5.2.5 ST Request and ST Positive Reply ......................... 22 84 5.2.6 SE Negative Replies ...................................... 22 85 5.2.7 AST Notification ......................................... 23 86 5.3 Policy Rule Control Messages ............................... 23 87 5.3.1 Policy Events and Asynchronous Notifications ............. 24 88 5.3.2 PRR Request .............................................. 24 89 5.3.3 PER Request .............................................. 25 90 5.3.4 PEA Request .............................................. 25 91 5.3.5 PLC Request .............................................. 26 92 5.3.6 PRS Request .............................................. 27 93 5.3.7 PRL Request .............................................. 27 94 5.3.8 PDR Request .............................................. 27 95 5.3.9 PRR Positive Reply ....................................... 28 96 5.3.10 PER Positive Reply ...................................... 28 97 5.3.11 PLC Positive Reply ...................................... 29 98 5.3.12 PRD Positive Reply ...................................... 29 99 5.3.13 PRS Positive Reply ...................................... 30 100 5.3.14 PES Positive Reply ...................................... 30 101 5.3.15 PDS Positive Reply ...................................... 31 102 5.3.16 PRL Positive Reply ...................................... 32 103 5.3.17 PDR Positive Replies .................................... 32 104 5.3.18 Policy Rule Control Negative Replies .................... 32 105 5.3.19 ARE Notification ........................................ 33 106 6 Message Format Checking ...................................... 34 107 7 Session Control Message Processing ........................... 35 108 7.1 Session State Machine ...................................... 35 109 7.2 Processing SE Requests ..................................... 36 110 7.3 Processing SA Requests ..................................... 37 111 7.4 Processing ST Requests ..................................... 38 112 7.5 Generating AST Notifications ............................... 38 113 7.6 Session Termination by Interruption of Connection .......... 38 114 8 Policy Rule Control Message Processing ....................... 39 115 8.1 Policy Rule State Machine .................................. 39 116 8.2 Processing PRR Requests .................................... 40 117 8.2.1 Initial Checks ........................................... 40 118 8.2.2 Processing on Pure Firewalls ............................. 42 119 8.2.3 Processing on Network Address Translators ................ 42 120 8.3 Processing PER Requests .................................... 44 121 8.3.1 Initial Checks ........................................... 44 122 8.3.2 Processing on Pure Firewalls ............................. 46 123 8.3.3 Processing on Network Address Translators ................ 47 124 8.3.4 Processing on combined Firewalls and NATs ................ 49 125 8.4 Processing PEA Requests .................................... 49 126 8.4.1 Initial Checks ........................................... 49 127 8.4.2 Processing on Pure Firewalls ............................. 51 128 8.4.3 Processing on Network Address Translators ................ 52 129 8.5 Processing PLC Requests .................................... 53 130 8.6 Processing PRS Requests .................................... 54 131 8.7 Processing PRL Requests .................................... 55 132 8.8 Processing PDR requests .................................... 55 133 8.8.1 Extending the MIDCOM semantics ........................... 55 134 8.8.2 Initial Checks ........................................... 56 135 8.8.3 Processing on Pure Firewalls ............................. 58 136 8.8.4 Processing on Network Address Translators ................ 59 137 8.8.5 Processing on combined Firewalls and NATs ................ 59 138 8.9 Generating ARE Notifications ............................... 59 139 9 Security Considerations ...................................... 60 140 9.1 Possible Threats to SIMCO .................................. 60 141 9.2 Securing SIMCO with IPsec .................................. 61 142 10 IAB Considerations on UNSAF ................................. 61 143 11 Acknowledgments ............................................. 62 144 12 References .................................................. 62 145 13 Authors' Addresses .......................................... 63 146 14 Intellectual Property Statement ............................. 63 147 15 Disclaimer of Validity ...................................... 64 148 16 Full Copyright Statement .................................... 64 150 1. Introduction 152 The SImple Middlebox COntrol (SIMCO) protocol serves for controlling 153 firewalls and Network Address Translators (NATs). As defined in 154 [RFC3234], firewalls and NATs belong to the group of middleboxes. A 155 middlebox is a device on the datagram path between source and 156 destination, which performs other functions than just IP routing. As 157 outlined in [RFC3303], firewalls and NATs are potential obstacles to 158 packet streams, for example, if dynamically negotiated UDP or TCP 159 port numbers are used, as in many peer-to-peer communication 160 applications. 162 The semantics for the SIMCO protocol are described in [RFC3989]. 164 SIMCO allows applications to communicate with middleboxes on the 165 datagram path in order to request a dynamic configuration at the 166 middlebox that enables datagram streams to pass the middlebox. 167 Applications can request pinholes at firewalls and address bindings 168 at NATs. 170 1.1. Terminology 172 The terminology used in this document is fully aligned with the 173 terminology defined in [RFC3989]. In the remainder of the text, the 174 term SIMCO refers to SIMCO version 3.0. The term prefix length is 175 used as described in [RFC3513] and [RFC1519]. With respect to 176 wildcarding, the prefix length determines the part of an IP address 177 that will be used in address match operations. 179 1.2. Binary Encodings 181 Previous experimental versions of SIMCO used simple ASCII encodings 182 with augmented BNF for syntax specification. This encoding requires 183 more resources than binary encodings do for generation and parsing of 184 messages. This applies to resources for coding agents and 185 middleboxes as well as to resources for executing a SIMCO stack. 187 Low resource requirements are important properties for two main 188 reasons: 190 - For many applications, for example for IP telephony, session 191 setup times are critical. Users do accept setup times only up to 192 some limit, and some signaling protocols start retransmitting 193 messages if setup is not completed with a certain time. 195 - Many middleboxes are rather small and relatively low cost 196 devices. For these, support of resource intensive protocols 197 might be a problem. The acceptance of a protocol on these 198 devices depends among others on the cost of implementing the 199 protocol and of its hardware requirements. 201 Therefore, we decided to use a simple and efficient binary encoding 202 for SIMCO version 3.0 that is described in this document. 204 2. Compliance with MIDCOM Protocol Semantics 206 SIMCO version 3 is fully compliant with the MIDCOM protocol semantics 207 defined by [RFC3989]. SIMCO implements protocol transactions as 208 defined in section 2.1.1 of [RFC3989]. All message types defined in 209 section 2.1.2 of [RFC3989] are supported by SIMCO and all mandatory 210 transactions are implemented. SIMCO does not implement the optional 211 group transactions. For all implemented transactions, SIMCO 212 implements all parameters concerning the information contained. 214 SIMCO defines a few new terms to reference functionality in the 215 semantics. Among these terms are Session Authentication (SA) and 216 Policy Enable Rule After reservation (PEA) messages. SA is used to 217 model the state transition given in Figure 2 of [RFC3989] from NOAUTH 218 to OPEN. PEA is used to to model the state transition given in 219 Figure 4 of [RFC3989] from RESERVED to ENABLED. 221 SIMCO implements one additional transaction, the Policy Disable Rule 222 (PDR) transaction, to the ones defined in [RFC3989]. PDR 223 transactions are used by security functions such as intrusion 224 detection and attack detection. They allow the agent to block a 225 specified kind of traffic. PDRs have priority above Policy Enable 226 Rules (PERs). When a PDR is established, all conflicting PERs 227 (including PERs with just a partial overlap) are terminated, and no 228 new conflicting PER can be established before the PDR is terminated. 229 Support of the PDR transaction by SIMCO is optional. For a detailed 230 description of the PDR transaction semantics see section 8.8. 232 3. SIMCO Sessions 234 The SIMCO protocol uses a session model with two parties: an agent 235 representing one or more applications and a middlebox. Both parties 236 may participate in multiple sessions. An agent may simultaneously 237 communicate with several middleboxes using one session per middlebox. 238 A middlebox may simultaneously communicate with several agents using 239 one session per agent. 241 +-------+ SIMCO protocol +-----------+ 242 | agent +------------------+ middlebox | 243 +-------+ +-----------+ 245 Figure 1: Participants in a SIMCO session 247 SIMCO sessions must run over a reliable transport layer protocol and 248 are initiated by the agent. SIMCO implementations must support TCP, 249 while other reliable transport protocols can be used as transport for 250 SIMCO as well. When using TCP as transport, middleboxes must wait 251 for agents to connect on port 7626. This port is assigned to SIMCO 252 servers by IANA (see http://www.iana.org/assignments/port-numbers). 253 The session may be secured, if required, by either IPsec or TLS to 254 guarantee authentication, message integrity and confidentiality. The 255 use of IPsec is outlined in Section 9 "Security Considerations". 257 The transaction semantics of sessions is explained in [RFC3989] 258 Section 2.2. 260 4. SIMCO Message Components 262 All SIMCO messages from agent to middlebox and from middlebox to 263 agent are sent over the transport protocol as specified in Section 3. 264 SIMCO messages are Type-Length-Value (TLV) encoded using big endian 265 (network ordered) binary data representations. 267 All SIMCO messages start with the SIMCO header containing message 268 type, message length, and a message identifier. The rest of the 269 message, the payload, contains zero, one, or more TLV message 270 attributes. 272 4.1. Message Types 274 The message type in the SIMCO header is divided into a basic type and 275 a sub-type. There are four basic types of SIMCO messages: 276 - request, 277 - positive reply, 278 - negative reply, 279 - notification. 280 Messages sent from the agent to the middlebox are always of basic 281 type 'request message', while the basic type of messages sent from 282 the middlebox to the agent is one of the three other types. Request 283 messages, positive and negative reply messages belong to request 284 transactions. From the agent's point of view, notification messages 285 belong to notification transactions only. From the middlebox's point 286 of view, a notification message may also belong to a request 287 transaction. See section 2.3.4. of [RFC3989] for a detailed 288 discussion of this issue. 290 The message sub-type gives further information on the message type 291 within the context of the basic message type. Only the combination 292 of basic type and sub-type clearly identify the type of a message. 294 4.2. The SIMCO Header 296 The SIMCO header is the first part of all SIMCO messages. It 297 contains four fields, the basic message type, the message sub-type, 298 the message length (excluding the SIMCO header) in octets, and the 299 transaction identifier. The SIMCO header has a size of 64 bits. Its 300 layout is defined by Figure 2. 302 Message Type 303 _______________^_______________ 304 / \ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Basic Type | Sub-Type | Message Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Transaction Identifier (TID) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2: The SIMCO header 313 4.2.1. Basic Message Types 315 For the basic type field, the following values are defined: 317 0x01 : Request Message 318 0x02 : Positive Reply Message 319 0x03 : Negative Reply Message 320 0x04 : Notification Message 322 4.2.2. Message Sub-types for Requests and Positive Replies 324 For basic types 0x01 (request) and 0x02 (positive reply), a common 325 set of values for the sub-type field is defined. Most of the sub- 326 types can be used for both basic types. Restricted sub-types are 327 marked accordingly. 329 0x01 : (SE) session establishment 330 0x02 : (SA) session authentication 331 0x03 : (ST) session termination 332 0x11 : (PRR) policy reserve rule 333 0x12 : (PER) policy enable rule 334 0x13 : (PEA) PER after reservation (request only) 335 0x14 : (PDR) policy disable rule 336 0x15 : (PLC) policy rule lifetime change 337 0x16 : (PRD) policy rule deletion (positive reply only) 338 0x21 : (PRS) policy rule status 339 0x22 : (PRL) policy rule list 340 0x23 : (PES) policy enable rule status (positive reply only) 341 0x24 : (PDS) policy disable rule status (positive reply only) 343 4.2.3. Message Sub-types for Negative Replies 345 For basic type 0x03 (negative reply message), the following values of 346 the sub-type field are defined: 348 Replies concerning general message handling 349 0x10 : wrong basic request message type 350 0x11 : wrong request message sub-type 351 0x12 : badly formed request 352 0x13 : reply message too big 354 Replies concerning sessions 355 0x20 : request not applicable 356 0x21 : lack of resources 357 0x22 : protocol version mismatch 358 0x23 : authentication failed 359 0x24 : no authorization 360 0x25 : transport protocol problem 361 0x26 : security of underlying protocol layers insufficient 363 Replies concerning policy rules 364 0x40 : transaction not supported 365 0x41 : agent not authorized for this transaction 366 0x42 : no resources available for this transaction 367 0x43 : specified policy rule does not exist 368 0x44 : specified policy rule group does not exist 369 0x45 : not authorized for accessing specified policy 370 0x46 : not authorized for accessing specified group 371 0x47 : requested address space not available 372 0x48 : lack of IP addresses 373 0x49 : lack of port numbers 374 0x4A : middlebox configuration failed 375 0x4B : inconsistent request 376 0x4C : requested wildcarding not supported 377 0x4D : protocol type doesn't match 378 0x4E : NAT mode not supported 379 0x4F : IP version mismatch 380 0x50 : conflict with existing rule 381 0x51 : not authorized to change lifetime 382 0x52 : lifetime can't be extended 383 0x53 : illegal IP Address 384 0x54 : protocol type not supported 385 0x55 : illegal port number 386 0x56 : illegal number of subsequent ports (NOSP) 387 0x57 : already enable PID 388 0x58 : parity doesn't match 390 4.2.4. Message Sub-types for Notifications 392 For basic type 0x04, the following values of the sub-type field are 393 defined: 395 0x01 : (BFM) badly formed message received 396 0x02 : (AST) asynchronous session termination 397 0x03 : (ARE) asynchronous policy rule event 399 4.2.5. Transaction Identifier 401 The transaction identifier (TID) is an arbitrary number identifying 402 the transaction. In a request message, the agent chooses an agent- 403 unique TID, such that the same agent never uses the same TID in two 404 different request messages belonging to the same session. Reply 405 messages must contain the same TID as the request message they 406 correspond to. In a notification message, the middlebox chooses a 407 middlebox-unique TID, such that the same middlebox never uses the 408 same TID in two different notification messages belonging to the same 409 session. 411 4.3. The SIMCO Payload 413 A SIMCO payload consists of zero, one, or more type-length-value 414 (TLV) attributes. Each TLV attribute starts with a 16 bits type 415 field and a 16 bits length field as shown in Figure 3. 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | attribute type | attribute length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | value 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 ... 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 3: Structure of TLV attribute 431 The attribute length field contains the length of the value field in 432 octets. 434 The following attribute types are defined: 436 type description length 437 ---------------------------------------------------- 438 0x0001 : SIMCO protocol version 32 bits 439 0x0002 : authentication challenge <= 4096 octets 440 0x0003 : authentication token <= 4096 octets 441 0x0004 : middlebox capabilities 64 bits 442 0x0005 : policy rule identifier 32 bits 443 0x0006 : group identifier 32 bits 444 0x0007 : policy rule lifetime 32 bits 445 0x0008 : policy rule owner <= 255 octets 446 0x0009 : address tuple 32, 96 or 192 bits 447 0x000A : PRR parameter set 32 bits 448 0x000B : PER parameter set 32 bits 450 4.3.1. SIMCO Protocol Version Attribute 452 The SIMCO protocol version attribute has a length of four octets. 453 The first two octets contain the version number, one the major 454 version number and the other the minor version number. Two remaining 455 octets are reserved. 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | 0x0001 | 0x0004 | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |major version #|minor version #| reserved | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 4: Protocol version attribute 465 The SIMCO protocol specified within this document is version 3.0. 466 The version numbers carried in the protocol version attribute are 3 467 for major version number and 0 for minor version number. 469 4.3.2. Authentication Attributes 471 The authentication challenge attribute and the authentication token 472 attribute have the same format. Both contain a single value field 473 with variable length. For both, the maximum length is limited to 474 4096 octets. Please note that the length of these attributes may 475 have values that are not multiples of 4 octets. In case of an 476 authentication challenge attribute, the value field contains an 477 authentication challenge sent from one peer to the other requesting 478 the other peer to authenticate itself. 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | 0x0002 | challenge length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | challenge 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 ... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 5: Authentication challenge attribute 494 The authentication token attribute is used for transmitting an 495 authentication token. 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | 0x0003 | authentication length | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | authentication token 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 ... 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 6: Authentication attribute 511 4.3.3. Middlebox Capabilities Attribute 513 The middlebox capabilities attribute has a length of eight octets. 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | 0x0004 | 0x0008 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | MB type |I|E|P|S|IIV|EIV| reserved | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | max policy rule lifetime | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 7: Capabilities attribute 525 The first parameter field carries a bit field called MB type and 526 provides information about the middlebox type. The following bits 527 within the field are defined. The remaining ones are reserved. 528 0x80 : packet filter firewall 529 0x40 : network address translator 530 0x10 : support of PDR transaction 531 0x01 : port translation (requires 0x40 set) 532 0x02 : protocol translation (requires 0x40 set) 533 0x04 : twice NAT support (requires 0x40 set) 535 For middleboxes that implement combinations of NAT and firewalls, 536 combinations of those flags are possible. For instance, a Network 537 Address and Port Translator (NAPT) with packet filter and PDR 538 transaction support, the value of the MB type parameter field is 539 0xD1. 541 The following four parameters fields are binary flags with a size of 542 one bit: 543 I : internal IP address wildcard support 544 E : external IP address wildcard support 545 P : port wildcard support 546 S : persistent storage of policy rules 548 The supported IP version for the internal and external network are 549 coded into the IIV (Internal IP version) and EIV (external IP 550 version) parameter fields. They both have a size of two bits. 551 Allowed values are 0x1 for IP version 4 (IPv4), 0x2 for IP version 6 552 (IPv6), and the combination of both (0x3) for IPv4 and IPv6 dual 553 stack. 555 The next parameter field with a length of 16 bits is reserved. 557 The max policy rule lifetime parameter field specifies the maximum 558 lifetime a policy rule may have. 560 4.3.4. Policy Rule Identifier Attribute 562 The policy rule identifier (PID) attribute contains an identifier of 563 a policy rule. The identifier has a length of four octets. 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | 0x0005 | 0x0004 | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | policy rule identifier (PID) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 8: Policy rule identifier attribute 573 4.3.5. Group Identifier Attribute 575 The group identifier (GID) attribute contains an identifier of a 576 policy rule group. The identifier has a length of four octets. 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | 0x0006 | 0x0004 | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | group identifier (GID) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 9: Group identifier attribute 586 4.3.6. Policy Rule Lifetime Attribute 588 The policy rule lifetime attribute specifies the requested or actual 589 remaining lifetime of a policy rule in seconds. Its value field 590 contains a 32-bit unsigned integer. 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | 0x0007 | 0x0004 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | policy rule lifetime | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Figure 10: Policy rule lifetime attribute 600 4.3.7. Policy Rule Owner Attribute 602 The policy rule owner attribute specifies the authenticated agent 603 that created and owns the policy rule. Its value field does not have 604 a fixed length, but its length is limited to 255 octets. Please note 605 that the length of this attribute may have values that are not 606 multiples of 4 octets. The owner is set by the middlebox. 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | 0x0008 | owner length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | owner 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 ... 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 11: Policy rule owner attribute 622 4.3.8. Address Tuple Attribute 624 The address tuple attribute contains a set of parameters specifying 625 IP and transport addresses. The length of this attribute is either 626 32, 96, or 192 bits. 628 The first parameter field has a length of 4 bits. It indicates 629 whether the contained parameters specify just the used protocols or 630 also concrete addresses. Defined values for this field are: 631 0x0 : full addresses 632 0x1 : protocols only 634 The second parameter field has also a length of 4 bits. It specifies 635 the IP version number. Defined values for this field are: 636 0x1 : IPv4 637 0x2 : IPv6 639 The third parameter field has a length of 8 bits. It specifies a 640 prefix length to be used for IP address wildcarding (see Section 641 1.1). 643 The fourth parameter field has also a length of 8 bits. It specifies 644 the transport protocol. Defined values for this field are all values 645 that are allowed in the 'Protocol' field of the IPv4 header [RFC791] 646 or in the 'Next Header field' of the IPv6 header [RFC2460]. The set 647 of defined numbers for these fields is maintained by the Internet 648 Assigned Numbers Authority (IANA) under the label 'PROTOCOL NUMBERS'. 650 The fifth parameter field has also a length of 8 bits. It specifies 651 the location of the address. Defined values for this field are: 652 0x00 : internal (A0) 653 0x01 : inside (A1) 654 0x02 : outside (A2) 655 0x03 : external (A3) 657 Port and address wildcarding can only be used in PER and PEA 658 transactions. The address tuple attribute carries a port number of 0 659 if the port should be wildcarded. For IPv4 a prefix length less than 660 0x20 is IP address wildcarding. For IPv6 a prefix length less than 661 0x80 is IP address wildcarding. 663 The port range field must be always greater than zero, but at least 664 1. 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | 0x0009 | 0x0004 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | 0x1 |IP ver.| prefix length |trnsp. protocol| location | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | 0x0009 | 0x000C | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | 0x0 | 0x1 | prefix length |trnsp. protocol| location | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | port number | port range | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | IPv4 address | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | 0x0009 | 0x0018 | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | 0x0 | 0x2 | prefix length |trnsp. protocol| location | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | port number | port range | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 + + 691 | | 692 + IPv6 address + 693 | | 694 + + 695 | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Figure 12: Address tuple attributes 700 4.3.9. PRR Parameter Set Attribute 702 The policy reserve rule (PRR) parameter set attribute contains all 703 parameters of the PRR request except the group identifier: 705 - NAT mode 706 - port parity 707 - requested inside IP version 708 - requested outside IP version 709 - transport protocol 710 - port range 712 The attribute value field has a total size of 32 bits. It is sub- 713 divided into six parameter fields. 715 The first parameter field called NM has a length of 2 bits and 716 specifies the requested NAT mode of the middlebox at which a 717 reservation is requested. Defined values for this field are: 718 01 : traditional 719 10 : twice 721 The second parameter field called PP has also a length of 2 bits. It 722 specifies the requested port parity. Defined values for this field 723 are: 724 00 : any 725 01 : odd 726 10 : even 728 The third and the fourth parameter field are called IPi and IPo, 729 respectively. Both have a length of 2 bits. They specify the 730 requested version of the IP protocol at the inside (IPi) or outside 731 (IPo) of the middlebox, respectively. Defined values for these 732 fields are: 733 00 : any 734 01 : IPv4 735 10 : IPv6 737 The fifth parameter field has a length of 8 bits. It specifies the 738 transport protocol for which the reservation should be made. A value 739 of zero indicates that the reservation is requested for an IP address 740 without specific selection of a protocol and a port number. Allowed 741 non-zero values are the defined values for the 'protocol' field in 742 the IPv4 header and IPv6 extension headers. The set of defined 743 numbers for these fields is maintained by the Internet Assigned 744 Numbers Authority (IANA) under the label 'PROTOCOL NUMBERS'. 746 The sixth parameter field has a length of 16 bits. It contains an 747 unsigned integer specifying the length of the port range that should 748 be supported. A value of 0xFFFF indicates that the reservation 749 should be made for all port numbers of the specified transport 750 protocol. A port range field with the value of 0x0001 specifies that 751 only a single port number should be reserved. Values greater than 752 one indicate the number of consecutive port numbers to be reserved. A 753 value of zero is not valid for this field. 755 Please note that the wildcarding value 0xFFFF can only be used in the 756 port range field in the PRR parameter set attribute. In the address 757 tuple attribute, wildcarding of port numbers is specified by the port 758 number field having a value of zero (see section 4.3.8). 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | 0x000A | 0x0004 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |NM |PP |IPi|IPo|trnsp. protocol| port range | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Figure 13: PRR parameter set attribute 768 4.3.10. PER Parameter Set Attribute 770 The policy enable rule (PER) parameter set attribute contains two 771 parameters: the requested port parity and the direction of the 772 enabled data stream. The attribute value field has a total size of 773 32 bits and it is sub-divided into 3 parameter fields. 775 The first parameter field has a length of 8 bits. It specifies the 776 requested port parity. Defined values for this field are: 777 0x00 : any 778 0x03 : same 780 The second parameter field has a length of 8 bits. It specifies the 781 direction of the enabled data stream. Defined values for this field 782 are: 783 0x01 : inbound 784 0x02 : outbound 785 0x03 : bi-directional 787 The third parameter field has a length of 16 bits and is reserved. 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | 0x000B | 0x0004 | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | port parity | direction | reserved | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Figure 14: PER parameter set attribute 797 5. SIMCO Message Formats 799 In the following, the formats of the different SIMCO message types 800 are defined. The definitions are grouped into protocol error 801 messages, session control messages, and policy rule control messages. 803 5.1. Protocol Error Replies and Notifications 805 When processing a received message, the middlebox might run into 806 message processing problems before it can identify whether the 807 message concerns session control or policy rule control. Also it 808 might not be possible to determine the message type or it might 809 detect a wrong message format. In these cases, the Badly Formed 810 Message (BFM) notification or one of the following negative replies 811 is sent: 813 0x0401 : BFM notification 814 0x0310 : wrong basic request message type 815 0x0311 : wrong request message sub-type 816 0x0312 : badly formed request 818 5.1.1. BFM Notification 820 The Badly Formed Message (BFM) notification message is sent from the 821 middlebox to the agent after a message was received that does not 822 comply to the SIMCO message format definition. The BFM notification 823 has no attributes and contains the SIMCO header only. 825 +--------------------------+ 826 | SIMCO header | 827 +--------------------------+ 829 Figure 15: BFM notification structure 831 5.1.2. Protocol Error Negative Replies 833 Protocol error negative replies are sent from the middlebox to the 834 agent if a message cannot be clearly interpreted, because it does not 835 comply with any defined message format. Protocol error negative 836 replies include 'wrong basic request message type' (0x0310), 'wrong 837 request message sub-type' (0x0311), 'badly formed request' (0x0312). 838 These replies have no attributes. They consist of the SIMCO header 839 only. 841 +--------------------------+ 842 | SIMCO header | 843 +--------------------------+ 845 Figure 16: Protocol error negative reply structure 847 5.2. Session Control Messages 849 Session control messages include the following list of message types 850 (composed of basic type and sub-type): 852 0x0101 : SE request 853 0x0102 : SA request 854 0x0103 : ST request 855 0x0201 : SE positive reply 856 0x0202 : SA positive reply 857 0x0203 : ST positive reply 858 0x0310 : negative reply: wrong basic request message type 859 0x0311 : negative reply: wrong request message sub-type 860 0x0312 : negative reply: badly formed request 861 0x0320 : negative reply: request not applicable 862 0x0321 : negative reply: lack of resources 863 0x0322 : negative reply: protocol version mismatch 864 0x0323 : negative reply: authentication failed 865 0x0324 : negative reply: no authorization 866 0x0325 : negative reply: transport protocol problem 867 0x0326 : negative reply: security of underlying protocol layers insufficient 868 0x0401 : BFM notification 869 0x0402 : AST notification 871 5.2.1. SE Request 873 The Session Establishment (SE) request message is sent from the agent 874 to the middlebox to request establishment of a session. The SE 875 request message contains one or two attributes, a mandatory SIMCO 876 version number attribute and an optional authentication challenge 877 attribute requesting the middlebox to authenticate itself. 879 +--------------------------+ 880 | SIMCO header | 881 +--------------------------+ 882 | SIMCO protocol version | 883 +--------------------------+ 884 | authentication challenge | optional 885 +--------------------------+ 887 Figure 17: Structure of SE request 889 5.2.2. SE Positive Reply 891 The Session Establishment (SE) reply message indicates completion of 892 session establishment. It contains a single mandatory attribute, the 893 middlebox capabilities attribute. 895 +--------------------------+ 896 | SIMCO header | 897 +--------------------------+ 898 | middlebox capabilities | 899 +--------------------------+ 901 Figure 18: Structure of SE positive reply 903 5.2.3. SA Positive Reply 905 If the agent requested middlebox authentication or if the middlebox 906 wants the agent to authenticate itself, then the middlebox replies on 907 the SE request with a Session Authentication (SA) reply message 908 instead of a SE reply message. The SA reply message contains two 909 optional attributes, but at least one of them need to be present. 910 The first one is an authentication challenge attribute requesting the 911 agent to authenticate itself. The second one is an authentication 912 token attribute authenticating the middlebox as reply on an 913 authentication request by the agent. 915 +--------------------------+ 916 | SIMCO header | 917 +--------------------------+ 918 | authentication challenge | optional 919 +--------------------------+ 920 | authentication token | optional 921 +--------------------------+ 923 Figure 19: Structure of SA positive reply 925 5.2.4. SA Request 927 The Session Authentication (SA) request message is sent from the 928 agent to the middlebox after an initial SE request was answered by a 929 SA reply. The SE request message contains one optional attribute, an 930 authentication token attribute authenticating the agent as response 931 on an authentication challenge sent by the middlebox in a SA reply. 933 +--------------------------+ 934 | SIMCO header | 935 +--------------------------+ 936 | authentication token | optional 937 +--------------------------+ 939 Figure 20: Structure of SA request 941 5.2.5. ST Request and ST Positive Reply 943 The Session Termination (ST) request message is sent from the agent 944 to the middlebox to request termination of a session. The ST 945 positive reply is returned acknowledging the session termination. 946 Both messages have no attributes and contain the SIMCO header only. 948 +--------------------------+ 949 | SIMCO header | 950 +--------------------------+ 952 Figure 21: Structure of ST request and positive reply 954 5.2.6. SE Negative Replies 956 There are nine different negative reply messages that can be sent 957 from a middlebox to the agent if the middlebox rejects a SE request. 958 Three of them are protocol error negative replies (0x031X) already 959 covered in section 4.1.2. 961 The remaining six negative replies are specific to session 962 establishment. One of them, the 'protocol version mismatch' negative 963 reply (0x0322) contains a single attribute, the protocol version 964 attribute. 966 +--------------------------+ 967 | SIMCO header | 968 +--------------------------+ 969 | SIMCO protocol version | 970 +--------------------------+ 972 Figure 22a: Structure of SE negative replies 974 The remaining three replies include 'request not applicable' 975 (0x0320), 'lack of resources' (0x0321), 'authentication failed' 976 (0x0323), 'no authorization' (0x0324), 'transport protocol problem' 977 (0x0325), and 'security of underlying protocol layers insufficient' 978 (0x0326). They consist of the SIMCO header only. 980 +--------------------------+ 981 | SIMCO header | 982 +--------------------------+ 984 Figure 22b: Structure of SE negative replies 986 5.2.7. AST Notification 988 The Asynchronous Session Termination (AST) notification message is 989 sent from the middlebox to the agent, if the middlebox wants to 990 terminate a SIMCO session. It has no attributes and contains the 991 SIMCO header only. 993 +--------------------------+ 994 | SIMCO header | 995 +--------------------------+ 997 Figure 22a: Structure of AST notifications 999 5.3. Policy Rule Control Messages 1001 Policy Rule control messages include the following list of message 1002 types (composed of basic type and sub-type): 1004 0x0111 : PRR request 1005 0x0112 : PER request 1006 0x0113 : PEA request 1007 0x0114 : PDR request 1008 0x0115 : PLC request 1009 0x0121 : PRS request 1010 0x0122 : PRL request 1011 0x0211 : PRR positive reply 1012 0x0212 : PER positive reply 1013 0x0214 : PDR positive reply 1014 0x0215 : PLC positive reply 1015 0x0216 : PRD positive reply 1016 0x0221 : PRS positive reply 1017 0x0223 : PES positive reply 1018 0x0224 : PDS positive reply 1019 0x0222 : PRL positive reply 1020 0x0310 : negative reply: wrong basic request message type 1021 0x0311 : negative reply: wrong request message sub-type 1022 0x0312 : negative reply: badly formed request 1023 0x0340 : negative reply: transaction not supported 1024 0x0341 : negative reply: agent not authorized for this transaction 1025 0x0342 : negative reply: no resources available for this transaction 1026 0x0343 : negative reply: specified policy rule does not exist 1027 0x0344 : negative reply: specified policy rule group does not exist 1028 0x0345 : negative reply: not authorized for accessing this policy 1029 0x0346 : negative reply: not authorized for accessing specified group 1030 0x0347 : negative reply: requested address space not available 1031 0x0348 : negative reply: lack of IP addresses 1032 0x0349 : negative reply: lack of port numbers 1033 0x034A : negative reply: middlebox configuration failed 1034 0x034B : negative reply: inconsistent request 1035 0x034C : negative reply: requested wildcarding not supported 1036 0x034D : negative reply: protocol type doesn't match 1037 0x034E : negative reply: NAT mode not supported 1038 0x034F : negative reply: IP version mismatch 1039 0x0350 : negative reply: conflict with existing rule 1040 0x0351 : negative reply: not authorized to change lifetime 1041 0x0352 : negative reply: lifetime can't be extended 1042 0x0353 : negative reply: illegal IP Address 1043 0x0354 : negative reply: protocol type not supported 1044 0x0355 : negative reply: illegal port number 1045 0x0356 : negative reply: illegal NOSP 1046 0x0357 : negative reply: already enable PID 1047 0x0358 : negative reply: parity doesn't match 1048 0x0401 : negative reply: BFM notification 1049 0x0403 : negative reply: ARE notification 1051 5.3.1. Policy Events and Asynchronous Notifications 1053 SIMCO maintains an owner attribute for each policy rule at the 1054 middlebox. Depending on the configuration of the middlebox several 1055 agents may access the same policy rule, see also [RFC3989] section 1056 2.1.5. and 2.3.4. 1058 To keep all agents synchronized about the state of their policy rules 1059 SIMCO generates Asynchronous Rule Event (ARE) notifications. When an 1060 agent is reserving or enabling a policy rule, then the middlebox 1061 sends an ARE to all agents that are authorized to access this policy 1062 rule. The middlebox sends an ARE to all agents authorized to access 1063 this policy rule when the rule lifetime is modified or if the rule is 1064 deleted. 1066 5.3.2. PRR Request 1068 The Policy Reserve Rule (PRR) request message is sent from the agent 1069 to the middlebox to request reservation of an IP address (and 1070 potentially also a range of port numbers) at the middlebox. Besides 1071 the SIMCO header, the request message contains two or three 1072 attributes. The first one is the PRR parameter set attribute 1073 specifying all parameters of the request except the requested policy 1074 rule lifetime and the group identifier. The missing parameters are 1075 covered by the following two attributes. The last attribute, the 1076 group identifier, is optional. 1078 +--------------------------+ 1079 | SIMCO header | 1080 +--------------------------+ 1081 | PRR parameter set | 1082 +--------------------------+ 1083 | policy rule lifetime | 1084 +--------------------------+ 1085 | group identifier | optional 1086 +--------------------------+ 1088 Figure 23: Structure of PRR request 1090 5.3.3. PER Request 1092 The Policy Enable Rule (PER) request message is sent from the agent 1093 to the middlebox to request enabling of data communication between an 1094 internal and an external address. Besides the SIMCO header, the 1095 request message contains four or five attributes. The first one is 1096 the PER parameter set attribute specifying all parameters of the 1097 request except the internal address, the external address, the 1098 requested policy rule lifetime and the group identifier. The missing 1099 parameters are covered by the following four attributes. Two address 1100 tuple parameters specify internal and external address tuples. 1101 Analogously to the PRR request, the last two attributes specify 1102 requested lifetime and group identifier. The group identifier 1103 attribute is optional. 1105 +--------------------------+ 1106 | SIMCO header | 1107 +--------------------------+ 1108 | PER parameter set | 1109 +--------------------------+ 1110 | address tuple (internal) | 1111 +--------------------------+ 1112 | address tuple (external) | 1113 +--------------------------+ 1114 | policy rule lifetime | 1115 +--------------------------+ 1116 | group identifier | optional 1117 +--------------------------+ 1119 Figure 24: Structure of PER request 1121 5.3.4. PEA Request 1123 The Policy Enable rule After reservation (PEA) request message is 1124 sent from the agent to the middlebox to request enabling of data 1125 communication between an internal and an external address. It is 1126 similar to the PER request. There is just one difference. The 1127 optional group identifier attribute of the PER request is replaced by 1128 a mandatory policy rule identifier attribute referencing an already 1129 established policy reserve rule established by a PRR transaction. 1131 +--------------------------+ 1132 | SIMCO header | 1133 +--------------------------+ 1134 | PER parameter set | 1135 +--------------------------+ 1136 | address tuple (internal) | 1137 +--------------------------+ 1138 | address tuple (external) | 1139 +--------------------------+ 1140 | policy rule lifetime | 1141 +--------------------------+ 1142 | policy rule identifier | 1143 +--------------------------+ 1145 Figure 25: Structure of PEA request 1147 The group identifier attribute is not included in the PEA request, 1148 since the group membership of the policy enable rule is inherited of 1149 the policy reserve rule. 1151 5.3.5. PLC Request 1153 The Policy Rule Lifetime Change (PLC) request message is sent from 1154 the agent to the middlebox to request a change of the remaining 1155 policy lifetime. Besides the SIMCO header, the request message 1156 contains two attributes specifying the policy rule to which the 1157 change should be applied and specifying the requested remaining 1158 lifetime. 1160 +--------------------------+ 1161 | SIMCO header | 1162 +--------------------------+ 1163 | policy rule identifier | 1164 +--------------------------+ 1165 | policy rule lifetime | 1166 +--------------------------+ 1168 Figure 26: Structure of PLC request 1170 5.3.6. PRS Request 1172 The Policy Rule Status (PRS) request message is sent from the agent 1173 to the middlebox to request a report on the status of a specified 1174 policy rule. Besides the SIMCO header, the request message contains 1175 just one attribute specifying the policy rule for which the report is 1176 requested. 1178 +--------------------------+ 1179 | SIMCO header | 1180 +--------------------------+ 1181 | policy rule identifier | 1182 +--------------------------+ 1184 Figure 27: Structure of PRS request 1186 5.3.7. PRL Request 1188 The Policy Rule List (PRL) request message is sent from the agent to 1189 the middlebox to request a list of all policy rules accessible to the 1190 agent. The message consists of the SIMCO header only. 1192 +--------------------------+ 1193 | SIMCO header | 1194 +--------------------------+ 1196 Figure 28: Structure of PRL request 1198 5.3.8. PDR Request 1200 The Policy Disable Rule (PDR) request message is sent from the agent 1201 to the middlebox to request a disable rule. The message consists of 1202 the SIMCO header, an internal address tuple, an external address 1203 tuple, and a lifetime attribute. 1205 +--------------------------+ 1206 | SIMCO header | 1207 +--------------------------+ 1208 | address tuple (internal) | 1209 +--------------------------+ 1210 | address tuple (external) | 1211 +--------------------------+ 1212 | policy rule lifetime | 1213 +--------------------------+ 1215 Figure 29: Structure of PDR request 1217 5.3.9. PRR Positive Reply 1219 The Policy Reserve Rule (PRR) positive reply is sent after successful 1220 reservation of an address at the inside or outside of the middlebox. 1221 The message contains four mandatory attributes and an optional 1222 attribute: the policy rule identifier of the new policy reserve rule, 1223 the corresponding group identifier, the remaining lifetime of the 1224 policy rule, the reserved outside address tuple, and the optional 1225 reserved inside address tuple. The reserved inside address tuple is 1226 only returned when the middlebox is of type twice-NAT. 1228 +--------------------------+ 1229 | SIMCO header | 1230 +--------------------------+ 1231 | policy rule identifier | 1232 +--------------------------+ 1233 | group identifier | 1234 +--------------------------+ 1235 | policy rule lifetime | 1236 +--------------------------+ 1237 | address tuple (outside) | 1238 +--------------------------+ 1239 | address tuple (inside) | optional 1240 +--------------------------+ 1242 Figure 30: Structure of PRR positive reply 1244 5.3.10. PER Positive Reply 1246 The Policy Enable Rule (PER) positive reply is sent after the 1247 middlebox successfully enabled data transfer between an internal and 1248 an external address (by using a PER or PEA request message). The 1249 message contains five attributes: the policy rule identifier of the 1250 new policy enable rule, the corresponding group identifier, the 1251 remaining lifetime of the policy rule, the address tuple at the 1252 outside of the middlebox, and the address tuple at the inside of the 1253 middlebox. 1255 +--------------------------+ 1256 | SIMCO header | 1257 +--------------------------+ 1258 | policy rule identifier | 1259 +--------------------------+ 1260 | group identifier | 1261 +--------------------------+ 1262 | policy rule lifetime | 1263 +--------------------------+ 1264 | address tuple (outside) | 1265 +--------------------------+ 1266 | address tuple (inside) | 1267 +--------------------------+ 1269 Figure 31: Structure of PER positive reply 1271 5.3.11. PLC Positive Reply 1273 The Policy Lifetime Change (PLC) positive reply is sent after the 1274 middlebox changed the lifetime of a policy rule to a positive (non- 1275 zero) value. The message contains just a single attribute: the 1276 remaining lifetime of the policy rule. 1278 +--------------------------+ 1279 | SIMCO header | 1280 +--------------------------+ 1281 | policy rule lifetime | 1282 +--------------------------+ 1284 Figure 32: Structure of PLC positive reply 1286 5.3.12. PRD Positive Reply 1288 The Policy Rule Deleted (PRD) positive reply is sent after the 1289 middlebox changed the remaining lifetime of a policy rule to zero, 1290 which means that it terminated the policy rule. The message consists 1291 of the SIMCO header only. 1293 +--------------------------+ 1294 | SIMCO header | 1295 +--------------------------+ 1297 Figure 33: Structure of PRD positive reply 1299 5.3.13. PRS Positive Reply 1301 The Policy Reserve Rule Status (PRS) positive reply is used for 1302 reporting the status of a policy reserve rule. The message format is 1303 identical with the format of the PRR positive reply except that it 1304 contains in addition a policy rule owner attribute. 1306 +--------------------------+ 1307 | SIMCO header | 1308 +--------------------------+ 1309 | policy rule identifier | 1310 +--------------------------+ 1311 | group identifier | 1312 +--------------------------+ 1313 | policy rule lifetime | 1314 +--------------------------+ 1315 | address tuple (outside) | 1316 +--------------------------+ 1317 | address tuple (inside) | optional 1318 +--------------------------+ 1319 | policy rule owner | 1320 +--------------------------+ 1322 Figure 34: Structure of PRS positive reply 1324 5.3.14. PES Positive Reply 1326 The Policy Enable Rule Status (PES) positive reply is used for 1327 reporting the status of a policy enable rule. 1329 +--------------------------+ 1330 | SIMCO header | 1331 +--------------------------+ 1332 | policy rule identifier | 1333 +--------------------------+ 1334 | group identifier | 1335 +--------------------------+ 1336 | PER parameter set | 1337 +--------------------------+ 1338 | address tuple (internal) | 1339 +--------------------------+ 1340 | address tuple (inside) | 1341 +--------------------------+ 1342 | address tuple (outside) | 1343 +--------------------------+ 1344 | address tuple (external) | 1345 +--------------------------+ 1346 | policy rule lifetime | 1347 +--------------------------+ 1348 | policy rule owner | 1349 +--------------------------+ 1351 Figure 35: Structure of PES positive reply 1353 5.3.15. PDS Positive Reply 1355 The Policy Disable Rule Status (PDS) positive reply is used for 1356 reporting the status of a policy disable rule. The message contains 1357 five attributes: the policy rule identifier, the internal and 1358 external address tuple, the policy disable rule lifetime, and the 1359 policy rule owner. 1361 +--------------------------+ 1362 | SIMCO header | 1363 +--------------------------+ 1364 | policy rule identifier | 1365 +--------------------------+ 1366 | address tuple (internal) | 1367 +--------------------------+ 1368 | address tuple (external) | 1369 +--------------------------+ 1370 | policy rule lifetime | 1371 +--------------------------+ 1372 | policy rule owner | 1373 +--------------------------+ 1375 Figure 36: Structure of PDS positive reply 1377 5.3.16. PRL Positive Reply 1379 The Policy Rule List (PRL) positive reply is used for reporting the 1380 list of all established policy rules. The number of attributes of 1381 this message is variable. The message contains one policy rule 1382 identifier attribute per established policy rule. 1384 +--------------------------+ 1385 | SIMCO header | 1386 +--------------------------+ 1387 | policy rule identifier | 1388 +--------------------------+ 1389 | policy rule identifier | 1390 +--------------------------+ 1391 | | 1392 . . . 1393 | | 1394 +--------------------------+ 1395 | policy rule identifier | 1396 +--------------------------+ 1398 Figure 37: Structure of PRL positive reply 1400 5.3.17. PDR Positive Replies 1402 The Policy Disable Rule (PDR) positive reply is sent after the 1403 middlebox successfully enabled the policy disable rule and removal of 1404 conflicting policy rules. The message contains two attributes: the 1405 policy rule identifier of the new policy disable rule, the remaining 1406 lifetime of the policy rule. 1408 +--------------------------+ 1409 | SIMCO header | 1410 +--------------------------+ 1411 | policy rule identifier | 1412 +--------------------------+ 1413 | policy rule lifetime | 1414 +--------------------------+ 1416 Figure 38: Structure of PDR positive reply 1418 5.3.18. Policy Rule Control Negative Replies 1420 Session establishment negative replies are sent from the middlebox to 1421 the agent if a middlebox rejects a policy rule control request. 1423 Beyond protocol error replies, a number of policy rule control- 1424 specific negative reply messages that can be sent. They are listed 1425 at the beginning of section 5.3. They all have no attributes. They 1426 consist of the SIMCO header only. 1428 +--------------------------+ 1429 | SIMCO header | 1430 +--------------------------+ 1432 Figure 39: Structure of Policy rule control negative replies 1434 5.3.19. ARE Notification 1436 The Asynchronous Policy Rule Event (ARE) notification message is sent 1437 from the middlebox to the agent. All agents participating in an open 1438 SIMCO session, that are authorized to access this policy rule and are 1439 not explicitly requesting an action (i.e., reserving, enabling, and 1440 changing lifetime) receive such an ARE notification, when: 1442 - a policy rule is deleted (lifetime attribute = 0) 1444 - a policy rule is reserved (lifetime attribute = lifetime) 1446 - a policy rule is enabled (lifetime attribute = lifetime) 1448 - a policy rule's lifetime changed(lifetime attribute = lifetime) 1450 Besides the SIMCO header, the request message contains two attributes 1451 specifying the policy rule which is concerned and the current 1452 lifetime. 1454 +--------------------------+ 1455 | SIMCO header | 1456 +--------------------------+ 1457 | policy rule identifier | 1458 +--------------------------+ 1459 | policy rule lifetime | 1460 +--------------------------+ 1462 Figure 40: Structure of ARE notification 1464 6. Message Format Checking 1466 This section describes common processing of all messages that are 1467 received by a middlebox. When a message arrives at a middlebox, then 1468 the header is checked for consistency, before the payload is 1469 processed. The middlebox sends a BFM notification if the header 1470 checks fail. If a session is already established, then the middlebox 1471 also sends an AST notification and closes the connection. 1473 The middlebox waits until is has received as many octets from the 1474 agent as specified by the message length plus 8 octets (the length of 1475 the SIMCO header). If the middlebox is still waiting and does not 1476 receive any more octets from the agent for 60 seconds, it sends a BFM 1477 notification. If a session is already established, then the 1478 middlebox also sends an AST notification and closes the connection 1479 after sending the BFM notification, otherwise it closes the 1480 connection without sending another message. 1482 After receiving a sufficient number of octets, the middlebox reads 1483 the transaction identifier and the basic message type. If the value 1484 of the basic message type fields does not equal 0x01 (request 1485 message), then the middlebox stops processing the message and sends a 1486 negative reply of type 'wrong basic request message type' (0x0310) to 1487 the agent. If no session is established, then the middlebox closes 1488 the connection after sending the 0x0310 reply. 1490 Then the middlebox checks the message sub-type. If no session is 1491 established, then only sub-type 'session establishment' (0x01) is 1492 accepted. For all other sub-types, the middlebox sends a reply of 1493 type 'wrong request message sub-type' (0x0311) to the agent and 1494 closes the connection after sending the reply. If a session is 1495 already established, then the middlebox checks if the message sub- 1496 type is one of the sub-types defined in section 4.2.2. (excluding 1497 'session establishment' (0x01), 'session termination' (0x03), and 1498 'policy rule deletion'(0x15)). If not, then the middlebox stops 1499 processing the message and sends a reply of type 'wrong request 1500 message sub-type' (0x0311) to the agent. 1502 Then the middlebox checks the TLV-structured attributes in the 1503 message. If their type or number does not comply with the defined 1504 format for this message type, the middlebox stops processing the 1505 message and sends a reply of type 'badly formed request' (0x0312) to 1506 the agent. If no session is established, then the middlebox closes 1507 the connection after sending the 0x0312 reply. 1509 After all message format checks are passed, the middlebox processes 1510 the content of the attributes as described in the following sections. 1512 7. Session Control Message Processing 1514 For session control, the agent can send SE, SA, and ST request 1515 messages. The middlebox then sends per request a single reply back 1516 to the agent. Additionally, the middlebox may send unsolicited AST 1517 notifications. 1519 7.1. Session State Machine 1521 For each session, there is a session state machine illustrated by the 1522 figure below. 1524 SE/BFM 1525 SE/0x031X 1526 SE/0x032X 1527 +-------+ 1528 | v 1529 +----------+ 1530 | CLOSED |----------------+ 1531 +----------+ | 1532 | ^ ^ | 1533 | | | SA/BFM | SE/SA 1534 | | | SA/0x031X | 1535 | | | SA/0x032X | 1536 SE/SE | | | ST/ST v 1537 | | | AST +----------+ 1538 | | +------------| NOAUTH | 1539 | | +----------+ 1540 | | AST | 1541 v | ST/ST | SA/SE 1542 +----------+ | 1543 | OPEN |<---------------+ 1544 +----------+ 1546 Figure 41: Session state machine 1548 The figure illustrates all possible state transitions of a session. 1549 Request transactions (SE, SA, ST) are denoted by a descriptor of the 1550 request message, a '/' symbol, and a descriptor of the reply message. 1551 Notification transactions are denoted just by the a notification 1552 descriptor. For example, a successful SE transaction is denoted by 1553 'SE/SE' and an AST notification is denoted by 'AST'. 1555 Initially, all sessions are in state CLOSED. From there, a 1556 successful SE transaction can change its state either to NOAUTH or to 1557 OPEN. From state NOAUTH, a successful SA transaction changes session 1558 state to OPEN. A failed SA transaction changes session state from 1559 NOAUTH back to CLOSED. Successful ST transactions and AST 1560 notifications change sessions from state NOAUTH or from state OPEN to 1561 state CLOSED. 1563 A SIMCO session is established in state OPEN, which is the only state 1564 in which the middlebox accepts requests other than SE, SA, and ST. 1566 7.2. Processing SE Requests 1568 The SE request is only applicable, if the session is in state CLOSED. 1569 If a session is in state NOAUTH or OPEN, then the middlebox sends a 1570 negative reply message of type 'request not applicable' (0x0320) to 1571 the agent, leaving the state of the session unchanged. 1573 Before processing the content of the SE request message, the 1574 middlebox may check its resources and decide that available resources 1575 are not sufficient to serve the agent. In such a case, the middlebox 1576 returns a negative reply of type 'lack of resources' (0x0321) and 1577 closes the connection. Furthermore, the middlebox may decide to 1578 reject the SE request, if the selected network connection and its 1579 protocol specific parameters are not acceptable for the middlebox. 1580 In such a case, the middlebox returns a negative reply of type 1581 'transport protocol problem' (0x0325) and closes the connection. The 1582 middlebox returns a negative reply of type 'security of underlying 1583 protocol layers insufficient' (0x0326) and closes the connection, if 1584 the security properties of the network connection do not match the 1585 middlebox's requirements. 1587 Processing of an SE request message starts with checking the major 1588 and minor protocol version number in the protocol version attribute. 1589 If the middlebox does not support the specified version number, then 1590 the middlebox returns a negative reply message of type 'protocol 1591 version mismatch' (0x0322) with the protocol version attribute 1592 indicating a version number that is supported by the middlebox. 1593 After sending this reply, the middlebox closes the connection. 1595 If the agent is already sufficiently authenticated by means of the 1596 underlying network connection (for instance, IPsec or TLS), then the 1597 middlebox checks, if the agent is authorized to configure the 1598 middlebox. If not, the middlebox returns a negative reply of type 1599 'no authorization' (0x0324) and closes the connection. 1601 A positive reply on the SE request may be of sub-type SE or SA. A SE 1602 request is sent after both parties sufficiently authenticated and 1603 authorized each other. A SA reply message is sent if explicit 1604 authentication is requested by any party. The agent requests 1605 explicit authentication by adding an authentication challenge 1606 attribute to the SE request message. The middlebox requests explicit 1607 authentication by returning a SA reply message with an authentication 1608 challenge attribute to the agent. If both parties request explicit 1609 authentication, then the SA reply message contains both, an 1610 authentication challenge attribute for the agent and an 1611 authentication token attribute authenticating the middlebox. 1613 If the SE request message contains an authentication challenge 1614 attribute, then the middlebox checks if it can authenticate itself. 1615 If yes, it adds a corresponding authentication token attribute to the 1616 SA reply. If it cannot authenticate based on the authentication 1617 challenge attribute, it adds an authentication token attribute to the 1618 SA reply message with a value field of length zero. 1620 If the middlebox wants the agent to explicitly authenticate itself, 1621 then the middlebox creates an authentication challenge attribute for 1622 the agent and adds it to the SA reply message. 1624 If the middlebox replies to the SE request message with a SA reply 1625 message, then the session state changes from CLOSED to NO_AUTH. 1627 If the SE request message did not contain an authentication challenge 1628 attribute and if the middlebox does not request the agent to 1629 explicitly authenticate itself, then the middlebox sends a SE reply 1630 message as response to the SE request message. This implies that the 1631 session state changes from CLOSED to OPEN. 1633 The SE reply message contains a capabilities attribute describing the 1634 middlebox capabilities. 1636 7.3. Processing SA Requests 1638 The SA request is only applicable, if the session is in state NOAUTH. 1639 If a session is in state CLOSED or OPEN, then the middlebox sends a 1640 negative reply message of type 'request not applicable' (0x0320) to 1641 the agent. The state of the session remains unchanged. 1643 After receiving an SA request message in state NOAUTH, the middlebox 1644 checks if the agent is sufficiently authenticated. Authentication 1645 may be based on an authentication token attribute that is optionally 1646 contained in the SA request message. If the agent is not 1647 sufficiently authenticated, then the middlebox returns a negative 1648 reply of type 'authentication failed' (0x0323) and closes the 1649 connection. 1651 If authentication of the agent is successful, the middlebox checks, 1652 if the agent is authorized to configure the middlebox. If not, the 1653 middlebox returns a negative reply of type 'no authorization' 1654 (0x0324) and closes the connection. 1656 If authorization is successful, then the session state changes from 1657 NOAUTH to OPEN and the agent returns a SE reply message that 1658 concludes session set-up. The middlebox states its capabilities in 1659 the capability attribute contained in the SE reply message. 1661 7.4. Processing ST Requests 1663 The ST request is only applicable, if the session is in state NOAUTH 1664 or OPEN. If a session is in state CLOSED, then the middlebox sends a 1665 negative reply message of type 'request not applicable' (0x0320) to 1666 the agent. The state of the session remains unchanged. 1668 The middlebox replies to a correct ST request always with a positive 1669 ST reply. The state of the session changes from OPEN or from NOAUTH 1670 to CLOSED. After sending the ST reply, the middlebox closes the 1671 connection. Requests received after receiving the ST request and 1672 before closing the connection are ignored by the middlebox. 1674 7.5. Generating AST Notifications 1676 At any time, the middlebox may terminate an established session and 1677 change the session state from OPEN or from NOAUTH to CLOSED. Session 1678 termination is indicated to the agent by sending an AST notification. 1680 Before sending the notification, the middlebox ensures that for all 1681 requests that have been processed, according replies are returned to 1682 the agent, such that the agent exactly knows the state of the 1683 middlebox at the time of session termination. After sending the AST 1684 notification, the middlebox sends no more messages to the agent and 1685 it closes the connection. 1687 7.6. Session Termination by Interruption of Connection 1689 Section 2.2.4 of [RFC3989] describes the session behavior when the 1690 network connection is interrupted. The behavior is defined for the 1691 middlebox (i.e., the SIMCO server) only and does not consider the 1692 behavior of the SIMCO agent in such an event. 1694 If the SIMCO agent detects an interruption of the underlying network 1695 connection, it can terminate the session. The detection of the 1696 interrupted network connection can be done by several means, for 1697 instance, feedback of the operating system or a connection timeout. 1698 The definition of this detection mechanism is out of scope of this 1699 memo. 1701 8. Policy Rule Control Message Processing 1703 For policy rule control and monitoring, the agent can send the PRR, 1704 PER, PEA, PLC, PRS and PRL requests. The middlebox then sends a 1705 single reply message per request message back to the agent. 1706 Additionally, the middlebox may send unsolicited ARE notifications at 1707 any time. 1709 The transaction semantics of policy rule control messages is 1710 explained in detail in [RFC3989] Section 2.3. 1712 For examples about protocol operation see Section 4 of [RFC3989]. 1714 8.1. Policy Rule State Machine 1716 Policy rules are established by successful PRR, PEA or PER 1717 transactions. Each time a policy rule is created, an unused policy 1718 rule identifier (PID) is assigned to the new policy rule. For each 1719 policy rule identifier, a state machine exists at the middlebox. The 1720 state machine is illustrated by the figure below. 1722 PRR/PRR +---------------+ 1723 +----+ +-----------------+ PID UNUSED |<-+ 1724 | | | +---------------+ | 1725 | v v PLC(lt=0)/ ^ | | 1726 | +-------------+ PRD | | PER/PER | ARE(lt=0) 1727 | | RESERVED +------------+ | | PLC(lt=0)/ 1728 | +-+----+------+ ARE(lt=0) v | PRD 1729 | | | +---------------+ | 1730 +----+ +---------------->| ENABLED +--+ 1731 PLC(lt>0)/ PEA/PER +-+-------------+ 1732 PLC | ^ 1733 +-----------+ 1734 lt = lifetime PLC(lt>0)/PLC 1736 Figure 42: Policy rule state machine 1738 The figure illustrates all possible state transitions of a PID and 1739 its associated policy. Successful configuration request transactions 1740 (PER, PRR, PEA, PLC) are denoted by a descriptor of the request 1741 message, a '/' symbol, and a descriptor of the reply message. Failed 1742 configuration request transactions are not displayed, because they do 1743 not change the PID state. Notification transactions are denoted just 1744 by the a notification descriptor. For example, a successful PRR 1745 request transaction is denoted by 'PRR/PRR' and an ARE notification 1746 is denoted by 'ARE'. For PLC request transactions, the descriptor 1747 for the request message is extended by an indication of the value of 1748 the lifetime parameter contained in the message. 1750 A successful PRR transaction (PRR/PRR) picks a PID in state UNUSED 1751 and changes the state to RESERVED. A successful PER transitions 1752 picks a PID in state UNUSED and changes the state to ENABLED. A PID 1753 in state RESERVED is changed to ENABLED by a successful PEA 1754 transaction. In state RESERVED or UNUSED, a successful PLC 1755 transaction with a lifetime parameter greater than zero does not 1756 change the PID's state. A successful PLC transaction with a lifetime 1757 parameter equal to zero changes the state of a PID from RESERVED to 1758 UNUSED or from ENABLED to UNUSED. 1760 A failed request transaction does not change state at the middlebox. 1762 An ARE notification transaction with the lifetime attribute set to 1763 zero has the same effect as a successful PLC transaction with a 1764 lifetime parameter equal to zero. 1766 8.2. Processing PRR Requests 1768 Processing PRR requests is much simpler on pure firewalls than on 1769 middleboxes with NAT functions. Therefore, this section has three 1770 sub-sections: The first one describes initial checks that are 1771 performed in any case. The second sub-section describes processing 1772 of PRR requests on pure firewalls, and the third one describes 1773 processing on all devices with NAT functions. 1775 8.2.1. Initial Checks 1777 When a middlebox receives a PRR request message, it first checks if 1778 the authenticated agent is authorized for requesting reservations. 1779 If not, it returns a negative reply message of type 'agent not 1780 authorized for this transaction' (0x0341). 1782 If the request contains the optional group identifier, then the 1783 middlebox checks if the group already exists. If not, the middlebox 1784 returns a negative reply message of type 'specified policy rule group 1785 does not exist' (0x0344). 1787 If the request contains the optional group identifier, then the 1788 middlebox checks if the authenticated agent is authorized for adding 1789 members to this group. If not, the middlebox returns a negative 1790 reply message of type 'not authorized for accessing specified group' 1791 (0x0346). 1793 The middlebox may then check the PRR parameter set. A negative reply 1794 of type 'IP version mismatch' (0x034F) is returned if the IPi field 1795 does not match the inside IP version of the address at the middlebox. 1797 A negative reply of type 'IP version mismatch' (0x034F) is returned 1798 if the IPo field does not match the outside IP version of the address 1799 at the middlebox. The requested transport protocol type is checked 1800 and a negative reply of type 'protocol type not supported' (0x0354) 1801 is returned if it is not supported. The middlebox may return a 1802 negative reply of type 'requested address space not available' 1803 (0x0347) if the requested address space is completely blocked or not 1804 supported by the middlebox in any way. For example, if a UDP port 1805 number is requested and all UDP packets are blocked by a the 1806 middlebox acting as firewall. 1808 The latter check at the middlebox is optional. If the check would 1809 fail and is not performed at this transaction, then two superfluous 1810 transactions will follow. First, the agent will send a request 1811 message for a corresponding PER transaction and will receive a 1812 negative reply on this. Second, either the agent will send a 1813 corresponding PLC request message with lifetime set to zero in order 1814 to delete the reservation, or the reservation will time out and the 1815 middlebox sends an ARE notification message with lifetime attribute 1816 set to zero. Both transactions can be avoided, if the middlebox 1817 initially performs this checks. 1819 A reason for avoiding this check might be its complexity. If the 1820 check is passed, the same check will have to be performed again for a 1821 subsequent corresponding PEA request. If processing two more 1822 transactions is considered to consume less resources than performing 1823 the check twice, it might be desirable not to perform it during the 1824 PRR transaction. 1826 After checking the PRR parameter set, the middlebox chooses a 1827 lifetime value for the new policy rule to be created, which is 1828 greater than or equal to zero and less than or equal to the minimum 1829 of the requested value and the maximum lifetime specified by the 1830 middlebox capabilities attribute at session setup. Formally, the 1831 lifetime is chosen such that 1833 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1835 holds, where 'lt_granted' is the actual lifetime chosen by the 1836 middlebox, 'lt_requested' is the lifetime requested by the agent, and 1837 'lt_maximum' is the maximum lifetime specified during capability 1838 exchange at session setup. 1840 If there are further sessions in state OPEN with authenticated agents 1841 authorized to access the policy rule, then to each of these agents a 1842 corresponding ARE notification with lifetime set to lt_granted is 1843 sent. 1845 If the chosen lifetime is zero, the middlebox sends a negative reply 1846 of type 'middlebox configuration failed' (0x034A) to the agent. 1848 8.2.2. Processing on Pure Firewalls 1850 If the middlebox is configured as a pure firewall, then it accepts 1851 the request after the initial checks. It establishes a new policy 1852 reserve rule and assigns to it a policy rule identifier in state 1853 RESERVED. It generates a positive PRR reply and sets the attributes 1854 as specified below. No configuration of the firewall function is 1855 required. 1857 The identifier chosen for the new policy rule is reported in the 1858 policy rule identifier attribute of the PRR reply. 1860 If a group identifier attribute is contained in the PRR request, then 1861 the middlebox adds the new policy rule to the members of this group. 1862 If the PRR request does not contain a group identifier attribute, 1863 then the middlebox creates a new group with the new policy rule as 1864 the only member. In any case, the middlebox reports the group of 1865 which the new policy rule is a member in the group identifier 1866 attribute of the PRR reply. 1868 The chosen lifetime is reported in the lifetime attribute of the PRR 1869 reply. 1871 In address tuple (outside) attribute of the PRR reply, the first 1872 parameter field is set to 'protocols only' (0x1). Consequently, the 1873 attribute has a length of 32 bits. The IP version parameter field is 1874 set according to the IPo parameter field in the PRR parameter set 1875 attribute of the PRR request message. The prefix length parameter 1876 field is set to 0x00 and the transport protocol parameter field in 1877 the address tuple (outside) attribute of the PRR reply is set 1878 identical to the transport protocol attribute in the PRR parameter 1879 set attribute of the PRR request message. The location parameter 1880 field is set to 'outside' (0x02). 1882 8.2.3. Processing on Network Address Translators 1884 If the middlebox is configured as a Network Address Translator (NAT), 1885 then it tries to reserved a NAT binding. 1887 The middlebox first checks further the PRR parameter set if the NM 1888 (NAT mode) parameter matches its configuration. A negative reply of 1889 type 'NAT mode not supported' (0x034E) is returned by the middlebox 1890 if the configuration is not matched. 1892 Following actions are performed depending on the middlebox NAT type: 1894 - traditional NAT 1895 A NAT binding at the outside (A2) with the requested transport 1896 protocol, external IP version, port range, and port parity is 1897 reserved. 1899 - twice NAT 1900 A NAT binding at the outside (A2) with the requested transport 1901 protocol, external IP version, port range, and port parity is 1902 reserved. Furthermore, the middlebox reserves an inside (A1) 1903 NAT binding with the requested transport protocol, internal IP 1904 version, port range, and port parity. 1906 The identifier chosen for the new policy rule is reported in the 1907 policy rule identifier attribute of the PRR reply. 1909 After the checks are successfully performed, the middlebox 1910 establishes a new policy reserve rule, with the requested PRR 1911 parameter set, and assigns to it a policy rule identifier in state 1912 RESERVED. It generates a positive PRR reply and sets the attributes 1913 as specified below. 1915 If a group identifier attribute is contained in the PRR request, then 1916 the middlebox adds the new policy rule to the members of this group. 1917 If the PRR request does not contain a group identifier attribute, 1918 then the middlebox creates a new group with the new policy rule as 1919 the only member. In any case, the middlebox reports the group of 1920 which the new policy rule is a member in the group identifier 1921 attribute of the PRR reply. 1923 The chosen lifetime is reported in the lifetime attribute of the PRR 1924 reply. 1926 In the address tuple (outside) attribute of the PRR reply, the first 1927 parameter field is set to 'full addresses' (0x0). The location 1928 parameter field is set to 'outside' (0x02). The IP version parameter 1929 field is set according to the IPo parameter field in the PRR 1930 parameter set attribute of the PRR request message. For IPv4 1931 addresses the prefix length field is set to 0x20 to indicate a full 1932 address and the reserved outside IPv4 address is set in the address 1933 field. For IPv6 addresses the prefix length field is set 0x80 to 1934 indicate a full address and the reserved outside IPv6 address is set 1935 in the address field. The transport protocol parameter field in the 1936 address tuple (outside) attribute of the PRR reply is set identical 1937 to the transport protocol attribute in the PRR parameter set 1938 attribute of the PRR request message. The reserved outside base port 1939 number, i.e., the lowest port number of the allocated range, is 1940 stored in the port number parameter field and the allocated port 1941 range is stored in the port range parameter field. 1943 If the NM (NAT mode) parameter in the PRR parameter set attribute of 1944 the PRR request message has the value 'traditional', then the PRR 1945 reply message does not contain an address tuple (inside) attribute. 1946 If otherwise, it has the value 'twice', then the PRR reply message 1947 contains an address tuple (inside) attribute. In the address tuple 1948 (inside) attribute of the PRR reply, the first parameter field is set 1949 to 'full addresses' (0x0). The location parameter field is set to 1950 'inside' (0x01). The IP version parameter field is set according to 1951 the IPi parameter field in the PRR parameter set attribute of the PRR 1952 request message. For IPv4 addresses the prefix length field is set 1953 to 0x20 to indicate a full address and the reserved inside IPv4 1954 address is set in the address field. For IPv6 addresses the prefix 1955 length field is set 0x80 to indicate a full address and the reserved 1956 inside IPv6 address is set in the address field. The transport 1957 protocol parameter field in the address tuple (inside) attribute of 1958 the PRR reply is set identical to the transport protocol attribute in 1959 the PRR parameter set attribute of the PRR request message. The 1960 reserved inside base port number, i.e., the lowest port number of the 1961 allocated range, is stored in the port number parameter field and the 1962 allocated port range is stored in the port range parameter field. 1964 8.3. Processing PER Requests 1966 Processing PER requests is much simpler on pure firewalls than on 1967 middleboxes with NAT functions. Therefore, this section has three 1968 sub-sections: The first one describes initial checks that are 1969 performed in any case. The second sub-section describes processing 1970 of PER requests on pure firewalls, and the third one describes 1971 processing on all devices with NAT functions. 1973 8.3.1. Initial Checks 1975 When a middlebox receives a PER request message, it first checks if 1976 the authenticated agent is authorized for requesting middlebox 1977 configurations for enabling communication. If not, it returns a 1978 negative reply message of type 'agent not authorized for this 1979 transaction' (0x0341). 1981 If the request contains the optional group identifier, then the 1982 middlebox checks if the group already exists. If not, the middlebox 1983 returns a negative reply message of type 'specified policy rule group 1984 does not exist' (0x0344). 1986 If the request contains the optional group identifier, then the 1987 middlebox checks if the authenticated agent is authorized for adding 1988 members to this group. If not, the middlebox returns a negative 1989 reply message of type 'not authorized for accessing specified group' 1990 (0x0346). 1992 Then the middlebox checks the contained address tuple attributes. 1994 If the first one does not have the location parameter field set to 1995 'internal' (0x00) or if the second one does not have the location 1996 parameter field set to 'external' (0x03), then the middlebox returns 1997 a negative reply message of type 'inconsistent request' (0x034B). 1999 If the transport protocol parameter field does not have the same 2000 value in both address tuple attributes, then the middlebox returns a 2001 negative reply message of type 'inconsistent request' (0x034B). 2003 If both address tuple attributes contain a port range parameter field 2004 and if both port range parameter fields have values not equal to 2005 0xFFFF and if the values of both port range parameter fields are 2006 different, then the middlebox returns a negative reply message of 2007 type 'inconsistent request' (0x034B). 2009 Then the agent checks if wildcarding is requested and if the 2010 requested wildcarding is supported by the middlebox. Wildcarding 2011 support may be different for internal address tuples and external 2012 address tuples. The following parameter fields of the address tuple 2013 attribute can indicate wildcarding: 2015 - the first parameter field 2016 If it is set to 'protocols only' (0x1), then IP addresses and 2017 port numbers are completely wildcarded. 2019 - the transport protocol field 2020 If it is set to 0x00, then the transport protocol is completely 2021 wildcarded. Please note that a completely wildcarded transport 2022 protocol might still support only a limited set of transport 2023 protocols according to the capabilities of the middlebox. For 2024 example a typical NAT implementation may apply transport 2025 wildcarding to UDP and TCP transport only. Wildcarding the 2026 transport protocol implies wildcarding of port numbers. If this 2027 field is set to 0x00, then the values of the port number field 2028 and the port range field are irrelevant. 2030 - the prefix length field 2031 If the IP version number field indicates IPv4 and the value of 2032 this field is less than to 0x20, then IP addresses are 2033 wildcarding according to this prefix length. If the IP version 2034 number field indicates IPv6 and the value of this field is less 2035 than to 0x80, then IP addresses are wildcarding according to 2036 this prefix length. If the first parameter filed is set to 2037 'protocols only' (0x1), then the value of the prefix length 2038 field is irrelevant. 2040 - the port number field 2041 If it is set to zero, then port numbers are completely 2042 wildcarded. In this case, the value of the port range field is 2043 irrelevant. 2045 If any of these kinds of wildcarding is used and if this is in 2046 conflict with wildcarding support for internal or external addresses 2047 of the middlebox, then the middlebox returns a negative reply message 2048 of type 'requested wildcarding not supported' (0x034C). 2050 Please note that the port range field cannot be used for wildcarding. 2051 If it is set to a value greater than one, then middlebox 2052 configuration is requested for all port numbers in the interval 2053 starting with the specified port number and containing as many 2054 consecutive port numbers as specified by the parameter. 2056 If the direction parameter field in the PER parameter set attribute 2057 has the value 'bi-directional', then only transport protocol 2058 wildcarding is allowed. If any other kind of wildcarding is 2059 specified in one or both of the IP address tuple attributes, then the 2060 middlebox returns a negative reply message of type 'inconsistent 2061 request' (0x034B). 2063 If the PER request conflicts with any policy disable rule (see 2064 Section 8.8.1) then the middlebox returns a negative reply message of 2065 type 'conflict with existing rule' (0x0350). 2067 After checking the address tuple attributes, the middlebox chooses a 2068 lifetime value for the new policy rule to be created, which is 2069 greater than or equal to zero and less than or equal to the minimum 2070 of the requested value and the maximum lifetime specified by the 2071 middlebox capabilities attribute at session setup. Formally, the 2072 lifetime is chosen such that 2074 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2076 holds, where 'lt_granted' is the actual lifetime chosen by the 2077 middlebox, 'lt_requested' is the lifetime requested by the agent, and 2078 'lt_maximum' is the maximum lifetime specified during capability 2079 exchange at session setup. 2081 If there are further sessions in state OPEN with authenticated agents 2082 authorized to access the policy rule, then to each of these agents a 2083 corresponding ARE notification with lifetime set to lt_granted is 2084 sent. 2086 If the chosen lifetime is zero, the middlebox sends a negative reply 2087 of type 'middlebox configuration failed' (0x034A) to the agent. 2089 8.3.2. Processing on Pure Firewalls 2091 If the middlebox is acting as a pure firewall, then it tries to 2092 configure the requested pinhole. The firewall configuration ignores 2093 the port parity parameter field in the PER parameter set attribute, 2094 but it considers the direction parameter field in this attribute. 2095 The pinhole is configured such that communication between the 2096 specified internal and external address tuples is enabled in the 2097 specified direction and covering the specified wildcarding. If the 2098 configuration fails, for example because the pinhole would conflict 2099 with high-level firewall policies, then the middlebox returns a 2100 negative reply message of type 'middlebox configuration failed' 2101 (0x034A). 2103 If the configuration was successful, the middlebox establishes a new 2104 policy enable rule and assigns to it a policy rule identifier in 2105 state ENABLED. It generates a positive PER reply and sets the 2106 attributes as specified below. 2108 The identifier chosen for the new policy rule is reported in the 2109 policy rule identifier attribute of the PER reply. 2111 If a group identifier attribute is contained in the PER request, then 2112 the middlebox adds the new policy rule to the members of this group. 2113 If the PRR request does not contain a group identifier attribute, 2114 then the middlebox creates a new group with the new policy rule as 2115 the only member. In any case, the middlebox reports the group of 2116 which the new policy rule is a member in the group identifier 2117 attribute of the PER reply. 2119 The chosen lifetime is reported in the lifetime attribute of the PER 2120 reply. 2122 The address tuple (internal) attribute of the PER request is reported 2123 as address tuple (outside) attribute of the PER reply. The address 2124 tuple (external) attribute of the PER request is reported as address 2125 tuple (inside) attribute of the PER reply. 2127 8.3.3. Processing on Network Address Translators 2129 If the middlebox is configured as a NAT, then it tries to configure 2130 the requested NAT binding. The action taken by the NAT are quite 2131 similar to the actions of the Policy Reserve Rule (PRR) request, but 2132 in the PER request a NAT binding is enabled. 2134 Following actions are performed depending on the middlebox NAT type 2136 - traditional NAT 2137 A NAT binding is established between the internal and external 2138 address tuple with the requested transport protocol, port range, 2139 direction, and port parity. The outside address tuple is 2140 created. 2142 - twice NAT 2143 A NAT binding is established between the internal and external 2144 address tuple with the requested transport protocol, port range, 2145 and port parity. But two address tuples are created: An outside 2146 address tuple and an inside address tuple. 2148 Should in either NAT case the configuration fail, a negative reply 2149 'middlebox configuration failed' (0x034A) is returned. 2151 If the configuration was successful, the middlebox establishes a new 2152 policy enable rule and assigns to it a policy rule identifier in 2153 state ENABLED. It generates a positive PER reply and sets the 2154 attributes as specified below. 2156 The identifier chosen for the new policy rule is reported in the 2157 policy rule identifier attribute of the PER reply. 2159 If a group identifier attribute is contained in the PER request, then 2160 the middlebox adds the new policy rule to the members of this group. 2161 If the PRR request does not contain a group identifier attribute, 2162 then the middlebox creates a new group with the new policy rule as 2163 the only member. In any case, the middlebox reports the group of 2164 which the new policy rule is a member in the group identifier 2165 attribute of the PER reply. 2167 The chosen lifetime is reported in the lifetime attribute of the PER 2168 reply. 2170 In the address tuple (outside) attribute of the PER reply, the first 2171 parameter field is set to 'full addresses' (0x0). The location 2172 parameter field is set to 'outside' (0x02). The IP version parameter 2173 field is set according to the IP version parameter field in the PER 2174 parameter set attribute of the PER request message. For IPv4 2175 addresses the prefix length field is set to 0x20 to indicate a full 2176 address and the reserved outside IPv4 address is set in the address 2177 field. For IPv6 addresses the prefix length field is set 0x80 to 2178 indicate a full address and the reserved outside IPv6 address is set 2179 in the address field. The transport protocol parameter field in the 2180 address tuple (outside) attribute of the PER reply is set identical 2181 to the transport protocol attribute in the PER parameter set 2182 attribute of the PER request message. The reserved outside base port 2183 number, i.e., the lowest port number of the allocated range, is 2184 stored in the port number parameter field and the allocated port 2185 range is stored in the port range parameter field. 2187 The address tuple (inside) is only returned if the middlebox is a 2188 twice NAT, otherwise it is omitted. In the address tuple (inside) 2189 attribute of the PER reply, the first parameter field is set to 'full 2190 addresses' (0x0). The location parameter field is set to 'inside' 2191 (0x01). The IP version parameter field is set according to the IP 2192 version parameter field in the PER parameter set attribute of the 2193 PER request message. For IPv4 addresses the prefix length field is 2194 set to 0x20 to indicate a full address and the reserved inside IPv4 2195 address is set in the address field. For IPv6 addresses the prefix 2196 length field is set 0x80 to indicate a full address and the reserved 2197 inside IPv6 address is set in the address field. The transport 2198 protocol parameter field in the address tuple (inside) attribute of 2199 the PER reply is set identical to the transport protocol attribute in 2200 the PER parameter set attribute of the PER request message. The 2201 reserved inside base port number, i.e., the lowest port number of the 2202 allocated range, is stored in the port number parameter field and the 2203 allocated port range is stored in the port range parameter field. 2205 8.3.4. Processing on combined Firewalls and NATs 2207 Middleboxes that are combinations of firewall and NAT are configured 2208 in such a way that first the NAT bindings are configured and 2209 afterwards the firewall pinholes. This sequence is needed since the 2210 firewall rules must be configured accordingly to the outside address 2211 tuples and for twice NATs the inside address tuples as well. This 2212 aspect of middlebox operation may be irrelevant to SIMCO, since some 2213 NATs already do firewall configuration on their own. 2215 8.4. Processing PEA Requests 2217 Processing PEA requests is much simpler on pure firewalls than on 2218 middleboxes with NAT functions. Therefore, this section has three 2219 sub-sections: The first one describes initial checks that are 2220 performed in any case. The second sub-section describes processing 2221 of PEA requests on pure firewalls, and the third one describes 2222 processing on all devices with NAT functions. 2224 8.4.1. Initial Checks 2226 When a middlebox receives a PEA request message, it first checks if 2227 the authenticated agent is authorized for requesting middlebox 2228 configurations for enabling communication. If not, it returns a 2229 negative reply message of type 'agent not authorized for this 2230 transaction' (0x0341). 2232 Then the middlebox checks the policy rule identifier attribute 2233 contained in the PEA message. If no policy rule with this identifier 2234 exists, then the middlebox returns a negative reply message of type 2235 'specified policy rule does not exist' (0x0343). If there exists a 2236 policy with this identifier and if it is in a state other than 2237 RESERVED, then the middlebox returns a negative reply message of type 2238 'inconsistent request' (0x034B). 2240 If a policy rule with this identifier exists, but the authenticated 2241 agent is not authorized for terminating this policy reserve rule, 2242 then the middlebox returns a negative reply message of type 'agent 2243 not authorized for accessing this policy' (0x0345). 2245 Then the middlebox checks the contained address tuple attributes. 2247 If the first one does not have the location parameter field set to 2248 'internal' (0x00) or if the second one does not have the location 2249 parameter field set to 'external' (0x03), then the middlebox returns 2250 a negative reply message of type 'inconsistent request' (0x034B). 2252 If the transport protocol parameter field does not have the same 2253 value in both address tuple attributes, then the middlebox returns a 2254 negative reply message of type 'inconsistent request' (0x034B). 2256 If both address tuple attributes contain a port range parameter field 2257 and if both port range parameter fields have values not equal to 2258 0xFFFF and if the values of both port range parameter fields are 2259 different, then the middlebox returns a negative reply message of 2260 type 'inconsistent request' (0x034B). 2262 Then the agent checks if wildcarding is requested and if the 2263 requested wildcarding is supported by the middlebox. Wildcarding 2264 support may be different for internal address tuples and external 2265 address tuples. The following parameter fields of the address tuple 2266 attribute can indicate wildcarding: 2268 - the first parameter field 2269 If it is set to 'protocols only' (0x1), then IP addresses and 2270 port numbers are completely wildcarded. 2272 - the transport protocol field 2273 If it is set to 0x00, then IP the transport protocol is 2274 completely wildcarded. Please note that a completely wildcarded 2275 transport protocol might still support only a limited set of 2276 transport protocols according to the capabilities of the 2277 middlebox. For example a typical NAT implementation may apply 2278 transport wildcarding to UDP and TCP transport only. 2280 - the prefix length field 2281 If the IP version number field indicates IPv4 and the value of 2282 this field is less than to 0x20, then IP addresses are 2283 wildcarding according to this prefix length. If the IP version 2284 number field indicates IPv6 and the value of this field is less 2285 than to 0x80, then IP addresses are wildcarding according to 2286 this prefix length. If the first parameter field is set to 2287 'protocols only' (0x1), then the value of the prefix length 2288 field is irrelevant. 2290 - the port number field 2291 If it is set to zero, then port numbers are completely 2292 wildcarded. 2294 - the port range field 2295 If it is set to a value greater than one, then port numbers are 2296 wildcarded within an interval starting with the specified port 2297 number and containing as many consecutive port numbers as 2298 specified by the parameter. 2300 If any of these kinds of wildcarding is used and if this is in 2301 conflict with wildcarding support for internal or external addresses 2302 of the middlebox, then the middlebox returns a negative reply message 2303 of type 'requested wildcarding not supported' (0x034C). 2305 If the PEA request conflicts with any policy disable rule (see 2306 Section 8.8.1) then the middlebox returns a negative reply message of 2307 type 'conflict with existing rule' (0x0350). 2309 After checking the address tuple attributes, the middlebox chooses a 2310 lifetime value for the new policy enable rule to be created, which is 2311 greater than or equal to zero and less than or equal to the minimum 2312 of the requested value and the maximum lifetime specified by the 2313 middlebox capabilities attribute at session setup. Formally, the 2314 lifetime is chosen such that 2316 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2318 holds, where 'lt_granted' is the actual lifetime chosen by the 2319 middlebox, 'lt_requested' is the lifetime requested by the agent, and 2320 'lt_maximum' is the maximum lifetime specified during capability 2321 exchange at session setup. 2323 If there are further sessions in state OPEN with authenticated agents 2324 authorized to access the policy rule, then to each of these agents a 2325 corresponding ARE notification with lifetime set to lt_granted is 2326 sent. 2328 If the chosen lifetime is zero, the middlebox sends a negative reply 2329 of type 'middlebox configuration failed' (0x034A) to the agent. 2331 8.4.2. Processing on Pure Firewalls 2333 If the middlebox is configured as a pure firewall, then it tries to 2334 configure the requested pinhole. The firewall configuration ignores 2335 the port parity parameter field in the PER parameter set attribute, 2336 but it considers the direction parameter field in this attribute. 2337 The pinhole is configured such that communication between the 2338 specified internal and external address tuples is enabled in the 2339 specified direction and covering the specified wildcarding. If the 2340 configuration fails, then the middlebox returns a negative reply 2341 message of type 'middlebox configuration failed' (0x034A). 2343 If the configuration was successful, the middlebox replaces the 2344 policy reserve rule referenced by the policy rule identifier 2345 attribute in the PEA request message by a new policy enable rule. 2346 The policy enable rule re-uses the policy rule identifier of the 2347 replaced policy reserve rule. The state of the policy rule 2348 identifier changes from RESERVED to ENABLED. The policy reserve rule 2349 is member of the same group as the replaced policy reserve rule was. 2351 Then the middlebox generates a positive PER reply and sets the 2352 attributes as specified below. 2354 The identifier chosen for the new policy rule is reported in the 2355 policy rule identifier attribute of the PER reply. 2357 The group identifier is reported in the group identifier attribute of 2358 the PER reply. 2360 The chosen lifetime is reported in the lifetime attribute of the PER 2361 reply. 2363 The address tuple (internal) attribute of the PER request is reported 2364 as address tuple (outside) attribute of the PER reply. The address 2365 tuple (external) attribute of the PER request is reported as address 2366 tuple (inside) attribute of the PER reply. 2368 8.4.3. Processing on Network Address Translators 2370 If the middlebox is configured as a NAT, then it tries to configure 2371 the requested NAT binding, i.e., enabling the already reserved 2372 binding. The already reserved NAT binding from the PRR request is 2373 now enabled in the middlebox. 2375 If the enable configuration was successful, the middlebox replaces 2376 the policy reserve rule referenced by the policy rule identifier 2377 attribute in the PEA request message by a new policy enable rule. 2378 The policy enable rule re-uses the policy rule identifier of the 2379 replaced policy reserve rule. The state of the policy rule 2380 identifier changes from RESERVED to ENABLED. The policy reserve rule 2381 is member of the same group as the replaced policy reserve rule was. 2383 Then the middlebox generates a positive PER reply and sets the 2384 attributes as specified below. 2386 The reserved outside address tuple is reported as address tuple 2387 (outside) attribute of the PER reply. The reserved inside address 2388 tuple is reported as address tuple (inside) attribute of the PER 2389 reply. Both reserved outside and inside address tuples are taken 2390 from the reserve policy rule generated during the PRR transaction. 2392 8.5. Processing PLC Requests 2394 When a middlebox receives a PLC request message, it first checks if 2395 the authenticated agent is authorized for requesting policy rule 2396 lifetime changes. If not, it returns a negative reply message of 2397 type 'agent not authorized for this transaction' (0x0341). 2399 Then the middlebox checks the policy rule identifier attribute 2400 contained in the PLC message. If no policy rule with this identifier 2401 exists, then the middlebox returns a negative reply message of type 2402 'specified policy rule does not exist' (0x0343). 2404 If a policy rule with this identifier exists, but the authenticated 2405 agent is not authorized for changing the lifetime of this policy 2406 rule, then the middlebox returns a negative reply message of type 2407 'agent not authorized for accessing this policy' (0x0345). 2409 Then the middlebox chooses a lifetime value for the new policy rule, 2410 which is greater than zero and less than or equal to the minimum of 2411 the requested value and the maximum lifetime specified by the 2412 middlebox capabilities attribute at session setup. Formally, the 2413 lifetime is chosen such that 2415 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2417 holds, where 'lt_granted' is the actual lifetime chosen by the 2418 middlebox, 'lt_requested' is the lifetime requested by the agent, and 2419 'lt_maximum' is the maximum lifetime specified during capability 2420 exchange at session setup. This procedure implies that the chosen 2421 lifetime is zero, if the requested lifetime is zero. 2423 If the chosen lifetime is greater than zero, the middlebox changes 2424 the lifetime of the policy rule to the chosen value and generates a 2425 PLC reply message. The chosen lifetime is reported in the lifetime 2426 attribute of the message. 2428 If otherwise the chosen lifetime is zero, then the middlebox 2429 terminates the policy rule changes the PID state from ENABLED or 2430 RESERVED, respectively, to UNUSED. 2432 The middlebox generates a PRD reply message and sends it to the 2433 requesting agent. If there are further sessions in state OPEN with 2434 authenticated agents authorized to access the policy rule, then to 2435 each of these agents a corresponding ARE notification with lifetime 2436 set to zero is sent. 2438 8.6. Processing PRS Requests 2440 When a middlebox receives a PRS request message, it first checks if 2441 the authenticated agent is authorized for receiving policy status 2442 information. If not, it returns a negative reply message of type 2443 'agent not authorized for this transaction' (0x0341). 2445 Then the middlebox checks the policy rule identifier attribute 2446 contained in the PRS message. If no policy rule with this identifier 2447 exists in state RESERVED or ENABLED, then the middlebox returns a 2448 negative reply message of type 'specified policy rule does not exist' 2449 (0x0343). 2451 If a policy rule with this identifier exists, but the authenticated 2452 agent is not authorized receiving status information for this policy 2453 rule, then the middlebox returns a negative reply message of type 2454 'agent not authorized for accessing this policy' (0x0345). 2456 If the checks describes above are passed, the middlebox accepts the 2457 requests and generates a reply. If the policy rule for which status 2458 information is requested is in state RESERVED, then a PRS reply is 2459 generated and sent to the agent. If otherwise the policy rule is in 2460 state ENABLED, then a PES reply is generated and sent to the agent. 2461 For policy disable rules a PDS reply is generated and sent to the 2462 agent. 2464 In both message formats, the lifetime attribute reports the current 2465 remaining lifetime of the policy rule, and the owner attribute 2466 reports the owner of the policy rule for which status information is 2467 requested. 2469 The PRS reply message format is identical to the PRR reply message 2470 format except of an appended owner attribute. In the PRS reply, the 2471 attributes which are common with the PRR reply - except for the 2472 lifetime attribute - have exactly the same values as the 2473 corresponding attributes of the the PRR reply that was sent as part 2474 of the PRR transaction that established the policy reserve rule. 2476 In the PES reply message, the PER parameter set attribute, the 2477 address tuple (internal) attribute, and the address tuple (external) 2478 attribute have exactly the same values as the corresponding 2479 attributes of the PER or PEA request that were sent as part of the 2480 corresponding transaction that established the policy enable rule. 2482 In the PES reply message, the policy rule identifier attribute, the 2483 group identifier attribute, the address tuple (inside) attribute, and 2484 the address tuple (outside) attribute have exactly the same values as 2485 the corresponding attributes of the PER reply that was sent as part 2486 of the PER or PEA transaction that established the policy enable 2487 rule. 2489 In the PDS reply message, the policy rule identifier attribute, the 2490 address tuple (internal) attribute, and the address tuple (external) 2491 attribute have exactly the same values as the corresponding 2492 attributes of the PDR request message. 2494 This transaction does not change the state of any policy rule. 2496 8.7. Processing PRL Requests 2498 When a middlebox receives a PRL request message, it first checks if 2499 the authenticated agent is authorized for receiving policy 2500 information. If not, it returns a negative reply message of type 2501 'agent not authorized for this transaction' (0x0341). 2503 Then the middlebox generates a PRL reply message. For each policy 2504 rule at the middlebox in state RESERVED or ENABLED, which the 2505 authenticated agent can access, a policy rule identifier attribute is 2506 generated and added to the PRL reply message before the message is 2507 sent to the agent. A negative reply message of type 'reply message 2508 too big' (0x0313) is generated, if the number of policy rule 2509 attributes to be returned exceeds the maximum transport unit size of 2510 the underlying network connection or the maximum length of a SIMCO 2511 message. The total size of a SIMCO message is limited to 65,536 in 2512 total (see Section 4.2 for the SIMCO header). 2514 This transaction does not change the state of any policy rule. 2516 8.8. Processing PDR requests 2518 Processing of PDR requests is structured into five sub-sections: The 2519 first one describes the general extension of the MIDCOM protocol 2520 semantics by PDR. The second sub-section describes the initial 2521 checks that are performed in any case. The third sub-section 2522 describes the processing of PDR requests on pure firewalls, the 2523 fourth one describes processing on devices with NATs and the fifth 2524 sub-section describes processing of devices with combined firewall 2525 and NAT functions. 2527 8.8.1. Extending the MIDCOM semantics 2529 The Policy Disable Rule (PDR) extends the MIDCOM protocol semantics 2530 [RFC3989] by another policy rule type. The PDR is intended to be 2531 used for dynamically blocking unwanted traffic, particularly in case 2532 of an attack, for example a distributed denial of service attack. 2534 PDR requests follow the same ownership concept as all other 2535 transactions do (see [RFC3989], section 2.1.5). However, PDR 2536 prioritization over PERs is independent of ownership. A PDR always 2537 overrules a conflicting PER, even if the respective owners are 2538 different. Typically, only a highly privileged agent will be allowed 2539 to issue PDR requests. 2541 A PDR rule and PER rule conflict with each other, if their address 2542 tuples overlap, such that there exists at least one IP packet that 2543 matches address tuple A0 of both rules in the internal network and 2544 that matches address tuple A3 of both rules in the external network. 2545 Note that the packet may be translated from the internal to external 2546 network or vice versa. 2548 Lets assume, for instance, a policy enable rule (PER) enabling all 2549 traffic from any external host using any UDP port to a certain UDP 2550 port of a certain internal host: 2552 PER A3={ any external IP address, UDP, any port } 2553 PER A0={ internal IP address 10.1.8.3, UDP, port 12345 } 2555 Then this conflicts with a policy disable rule (PDR) blocking all UDP 2556 traffic from a potentially attacking host: 2558 PDR A3={ external IP address 192.0.2.100, UDP, any port } 2559 PDR A0={ any internal IP address, UDP, any port } 2561 If a new PDR is established, then all conflicting PERS are terminated 2562 immediately. A new PER can only be established, if it does not 2563 conflict with any already existing PDR. 2565 8.8.2. Initial Checks 2567 When a middlebox receives a PDR request message, it first checks if 2568 the authenticated agent is authorized for requesting middlebox 2569 configurations for disabling communication. If not, it returns a 2570 negative reply message of type 'agent not authorized for this 2571 transaction' (0x0341). 2573 Then the middlebox checks the contained address tuple attributes. 2575 If the first one does not have the location parameter field set to 2576 'internal' (0x00) or if the second one does not have the location 2577 parameter field set to 'external' (0x03), then the middlebox returns 2578 a negative reply message of type 'inconsistent request' (0x034B). 2580 If the transport protocol parameter field does not have the same 2581 value in both address tuple attributes, then the middlebox returns a 2582 negative reply message of type 'inconsistent request' (0x034B). 2584 If both address tuple attributes contain a port range parameter field 2585 and if both port range parameter fields have values not equal to 2586 0xFFFF and if the values of both port range parameter fields are 2587 different, then the middlebox returns a negative reply message of 2588 type 'inconsistent request' (0x034B). 2590 Then the agent checks if wildcarding is requested and if the 2591 requested wildcarding is supported by the middlebox. Wildcarding 2592 support may be different for internal address tuples and external 2593 address tuples. The following parameter fields of the address tuple 2594 attribute can indicate wildcarding: 2596 - the first parameter field 2597 If it is set to 'protocols only' (0x1), then IP addresses and 2598 port numbers are completely wildcarded. 2600 - the transport protocol field 2601 If it is set to 0x00, then the transport protocol is completely 2602 wildcarded. Please note that a completely wildcarded transport 2603 protocol might still support only a limited set of transport 2604 protocols according to the capabilities of the middlebox. For 2605 example a typical NAT implementation may apply transport 2606 wildcarding to UDP and TCP transport only. Wildcarding the 2607 transport protocol implies wildcarding of port numbers. If this 2608 field is set to 0x00, then the values of the port number field 2609 and the port range field are irrelevant. 2611 - the prefix length field 2612 If the IP version number field indicates IPv4 and the value of 2613 this field is less than to 0x20, then IP addresses are 2614 wildcarding according to this prefix length. If the IP version 2615 number field indicates IPv6 and the value of this field is less 2616 than to 0x80, then IP addresses are wildcarding according to 2617 this prefix length. If the first parameter filed is set to 2618 'protocols only' (0x1), then the value of the prefix length 2619 field is irrelevant. 2621 - the port number field 2622 If it is set to zero, then port numbers are completely 2623 wildcarded. In this case, the value of the port range field is 2624 irrelevant. 2626 If any of these kinds of wildcarding is used and if this is in 2627 conflict with wildcarding support for internal or external addresses 2628 of the middlebox, then the middlebox returns a negative reply message 2629 of type 'requested wildcarding not supported' (0x034C). 2631 Please note that the port range field cannot be used for wildcarding. 2632 If it is set to a value greater than one, then middlebox 2633 configuration is requested for all port numbers in the interval 2634 starting with the specified port number and containing as many 2635 consecutive port numbers as specified by the parameter. 2637 The specified policy disable rule is activated and the middlebox will 2638 terminate any conflicting policy enable rule immediately. Conflicts 2639 are defined in Section 8.8.1. Agents with open session that have 2640 access to the policy rules to be terminated are notified via the ARE 2641 notification. 2643 The middlebox will reject all requests for new policy enable rules 2644 that conflict with the just established PDR as long as the PDR is not 2645 terminated. In such a case, a negative 'conflict with existing rule' 2646 (0x0350) reply will be generated. 2648 After checking the address tuple attributes, the middlebox chooses a 2649 lifetime value for the new policy rule to be created, which is 2650 greater than or equal to zero and less than or equal to the minimum 2651 of the requested value and the maximum lifetime specified by the 2652 middlebox capabilities attribute at session setup. Formally, the 2653 lifetime is chosen such that 2655 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2657 holds, where 'lt_granted' is the actual lifetime chosen by the 2658 middlebox, 'lt_requested' is the lifetime requested by the agent, and 2659 'lt_maximum' is the maximum lifetime specified during capability 2660 exchange at session setup. 2662 If there are further sessions in state OPEN with authenticated agents 2663 authorized to access the policy rule, then to each of these agents a 2664 corresponding ARE notification with lifetime set to lt_granted is 2665 sent. 2667 If the chosen lifetime is zero, the middlebox sends a negative reply 2668 of type 'middlebox configuration failed' (0x034A) to the agent. 2670 8.8.3. Processing on Pure Firewalls 2672 If the middlebox is acting as a pure firewall, then it tries to 2673 configure the requested disable rule, i.e., configuring a blocking 2674 rule at the firewall. The disable rule is configured such that 2675 communication between the specified internal and external address 2676 tuples is blocked with covering the specified wildcarding. If the 2677 configuration fails, for example because the blocking rule would 2678 conflict with high-level firewall policies, then the middlebox 2679 returns a negative reply message of type 'middlebox configuration 2680 failed' (0x034A). 2682 If the configuration was successful, the middlebox establishes a new 2683 policy disable rule and assigns to it a policy rule identifier in 2684 state ENABLED. It generates a positive PDR reply and sets the 2685 attributes as specified below. 2687 The identifier chosen for the new policy rule is reported in the 2688 policy rule identifier attribute of the PDR reply. 2690 The chosen lifetime is reported in the lifetime attribute of the PDR 2691 reply. 2693 8.8.4. Processing on Network Address Translators 2695 If the middlebox is configured as a NAT, then it tries to block the 2696 specified address tuple in the NAT. The mechanisms used for this 2697 depend on the implementation and capabilities of the NAT. 2699 Should in either NAT case the configuration fail, a negative reply 2700 'middlebox configuration failed' (0x034A) is returned. 2702 If the configuration was successful, the middlebox establishes a new 2703 policy disable rule and assigns to it a policy rule identifier in 2704 state ENABLED. It generates a positive PDR reply and sets the 2705 attributes as specified below. 2707 The identifier chosen for the new policy rule is reported in the 2708 policy rule identifier attribute of the PDR reply. 2710 The chosen lifetime is reported in the lifetime attribute of the PDR 2711 reply. 2713 8.8.5. Processing on combined Firewalls and NATs 2715 Middleboxes that are combinations of firewall and NAT are configured 2716 in such a way that the firewall is first configured with the blocking 2717 rule and afterwards the NAT is configured to block the address tuple. 2718 This aspect of middlebox operation may be irrelevant to SIMCO, since 2719 some NATs already do firewall configuration on their own. 2721 8.9. Generating ARE Notifications 2723 At any time, the middlebox may terminate a policy rule by deleting 2724 the configuration of the rule and by changing the corresponding PID 2725 state from ENABLED or from RESERVED, respectively, to UNUSED. 2727 For each session in state OPEN with authenticated agents authorized 2728 to access the policy rule, the middlebox generates a corresponding 2729 ARE notification with lifetime attribute set to zero and sends it to 2730 the respective agent. The identifier of the terminated policy rule 2731 is reported in the policy rule identifier attribute of the ARE 2732 notification. 2734 After sending the notification, the middlebox will consider the 2735 policy rule to be non-existent. It will not process any further 2736 transaction on this policy rule. 2738 The middlebox generates in the case of PRR, PER, PEA, and PLC 2739 (reserving and enabling policy rules, and changes of the lifetime) 2740 for each session in state OPEN with authenticated agents authorized 2741 to access the policy rule other then the requesting agent an ARE 2742 notification after processing the request. Through this ARE 2743 notification all other agents are kept synchronized with the latest 2744 state of the policy rules. 2746 9. Security Considerations 2748 9.1. Possible Threats to SIMCO 2750 Middleboxes, such as firewalls and NATs, are usually operated for 2751 improving the network security and for extending the IP address space 2752 (note that stand-alone NATs are not considered to improve security, 2753 see [RFC2663]). The configuration of middleboxes from an external 2754 entity looks quite counterproductive on the first glimpse, since an 2755 attacker using this can possibly configure the middlebox in such way 2756 that no filtering is applied anymore or that NAT bindings are 2757 configured for malicious use. So the middlebox is not performing the 2758 intended function anymore. Possible threats to SIMCO are: 2760 - Man in the middle 2761 A malicious host intercepts messages exchanged between SIMCO 2762 agent and middlebox and can change the content of the messages 2763 on the fly. This man in the middle attack would result in, from 2764 the agent's view, in a proper middlebox configuration, but the 2765 middlebox would be configured not accordingly. The man in the 2766 middlebox could open pin holes that compromise the protected 2767 network's security. 2769 - Changing content 2770 The message content could be changed in such a way, that not the 2771 requested policy rule configuration is configured in the 2772 middlebox, but any other unwanted configuration. That way, an 2773 attacker can open the firewall for his own traffic. 2775 - Replaying 2776 Already sent messages could be re-sent in order to configure the 2777 middlebox in such way that hosts could configure policy rules 2778 without the permission of a application level gateway or system 2779 administrator. 2781 - Wiretapping 2782 An already configured policy rule could be re-used by other 2783 hosts, if the policy rule is configure with a too broad 2784 wildcarding (see below). These hosts could send unwanted 2785 traffic. 2787 9.2. Securing SIMCO with IPsec 2789 The security considerations section identified several issues on 2790 security for SIMCO. SIMCO can rely on IPsec mechanisms, as defined 2791 in [RFC2402] and [RFC2406], for ensuring proper operations. 2793 When SIMCO relies on IPsec, it uses IPsec in transport mode with 2794 authentication header (AH) [RFC2402] and encapsulating security 2795 payload (ESP) [RFC2406], so that IP traffic between SIMCO agent and 2796 middlebox is protected. The authentication header is used for 2797 protecting the whole packet against content changes and replaying. 2798 The ESP header is used to prevent from wiretapping. 2800 At either side, agent or middlebox, the IP addresses of agent or 2801 middlebox, TCP as transport protocol and if possible the port numbers 2802 should be pre-configured. Only packets from the preconfigured 2803 address of the agents or middlebox should be accepted. 2805 The keys for authentication both SIMCO agent and middlebox are pre- 2806 configured at each side. For replay protection, the use of a key 2807 management system is recommended. For the Internet Key Exchange (IKE) 2808 protocol see [RFC2409]. 2810 10. IAB Considerations on UNSAF 2812 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a 2813 process at originating endpoints that attempt to determine or fix the 2814 address (and port) by which they are known to another endpoint. 2815 UNSAF proposals, such as STUN [RFC3489] are considered as a general 2816 class of workarounds for NAT traversal and as solutions for scenarios 2817 with no middlebox communication (MIDCOM). 2819 This document describes a protocol implementation of the MIDCOM 2820 semantics and thus is implementing a middlebox communication (MIDCOM) 2821 solution. MIDCOM is not intended as a short-term workaround, but 2822 more as a long-term solution for middlebox communication. In MIDCOM, 2823 endpoints are not involved in allocating, maintaining, and deleting 2824 addresses and ports at the middlebox. The full control of addresses 2825 and ports at the middlebox is located at the SIMCO server. 2827 Therefore, this document addresses the UNSAF considerations in 2828 [RFC3424] by proposing a long-term alternative solution. 2830 11. Acknowledgments 2832 We would like to thank Sebastian Kiesel and Andreas Mueller for their 2833 valuable contributions. 2835 12. References 2837 [RFC791] Postel, J., "INTERNET PROTOCOL", RFC 791, September 1981 2839 [RFC1519] Fuller, V., et al, "Classless Inter-Domain Routing (CIDR)", 2840 RFC 1519, September 1993 2842 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 2843 (IPv6) Specification", RFC 2460, December 1998 2845 [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2846 2402, November 1998 2848 [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security 2849 Payload (ESP)", RFC 2406, November 1998 2851 [RFC2409] Harkins, D., and D. Carrel, "The Internet Key Exchange 2852 (IKE)", RFC 2409, November 1998 2854 [RFC2663] Srisuresh, P., Holdrege, M., "IP Network Address Translator 2855 (NAT) Terminology and Considerations", RFC 2663, August 1999 2857 [RFC3234] Carpenter, B., Brim, S., "Middleboxes: Taxonomy and Issues", 2858 RFC 3234, February 2002 2860 [RFC3303] Srisuresh, P., et al, "Middlebox communication architecture 2861 and framework", RFC 3303, August 2002 2863 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2864 Address Fixing (UNSAF) Across Network Address Translation", 2865 RFC 3424, November 2002. 2867 [RFC3513] Hinden, R., Deering, S., "Internet Protocol Version 6 (IPv6) 2868 Addressing Architecture", RFC 3513, April 2003 2870 [RFC3989] Stiemerling, M., Quittek, J., Taylor, T., "MIDCOM protocol 2871 semantics", RFC 3989, February 2005 2873 13. Authors' Addresses 2875 Martin Stiemerling 2876 NEC Europe Ltd. 2877 Network Laboratories Europe 2878 Kurfuersten-Anlage 36 2879 69115 Heidelberg 2880 Germany 2882 Phone: +49 6221 90511-13 2883 Email: stiemerling@netlab.nec.de 2885 Juergen Quittek 2886 NEC Europe Ltd. 2887 Network Laboratories Europe 2888 Kurfuersten-Anlage 36 2889 69115 Heidelberg 2890 Germany 2892 Phone: +49 6221 90511-15 2893 Email: quittek@netlab.nec.de 2895 Cristian Cadar 2896 Germany 2898 14. Intellectual Property Statement 2900 The IETF takes no position regarding the validity or scope of any 2901 Intellectual Property Rights or other rights that might be claimed to 2902 pertain to the implementation or use of the technology described in 2903 this document or the extent to which any license under such rights 2904 might or might not be available; nor does it represent that it has 2905 made any independent effort to identify any such rights. Information 2906 on the procedures with respect to rights in RFC documents can be 2907 found in BCP 78 and BCP 79. 2909 Copies of IPR disclosures made to the IETF Secretariat and any 2910 assurances of licenses to be made available, or the result of an 2911 attempt made to obtain a general license or permission for the use of 2912 such proprietary rights by implementers or users of this 2913 specification can be obtained from the IETF on-line IPR repository at 2914 http://www.ietf.org/ipr. 2916 The IETF invites any interested party to bring to its attention any 2917 copyrights, patents or patent applications, or other proprietary 2918 rights that may cover technology that may be required to implement 2919 this standard. Please address the information to the IETF at ietf- 2920 ipr@ietf.org. 2922 15. Disclaimer of Validity 2924 This document and the information contained herein are provided on an 2925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2927 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2928 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2929 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2932 16. Full Copyright Statement 2934 Copyright (C) The Internet Society (2005). This document is subject 2935 to the rights, licenses and restrictions contained in BCP 78, and 2936 except as set forth therein, the authors retain all their rights. 2938 Acknowledgment 2940 Funding for the RFC Editor function is currently provided by the 2941 Internet Society.