idnits 2.17.1 draft-brim-midcom-inandout-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 is 1 instance of too long lines in the document, the longest one being 29 characters in excess of 72. == There are 2 instances 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (August 2001) is 8283 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) == Outdated reference: A later version (-07) exists of draft-ietf-midcom-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-framework (ref. '1') == Outdated reference: A later version (-05) exists of draft-ietf-midcom-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-requirements (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Brim 3 Internet-Draft A. Simu 4 Expires: January 30, 2002 Cisco Systems, Inc. 5 August 2001 7 Midcom Agents and Topology 8 draft-brim-midcom-inandout-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 30, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 A midcom agent does not know whether to ask for a ruleset to be 40 installed in a middlebox or not. Even when it does ask, in some 41 situations the middlebox does not know how to apply the ruleset. 42 This document tries to solve these problems without adding an 43 overwhelming amount of complexity to every agent and middlebox. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4. The Simplest Scenario . . . . . . . . . . . . . . . . . . . 4 51 5. Overlapping Address Spaces . . . . . . . . . . . . . . . . . 5 52 5.1 Should a Request Be Sent? . . . . . . . . . . . . . . . . . 5 53 5.2 Inside or Outside? . . . . . . . . . . . . . . . . . . . . . 7 54 5.3 Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Agent on the Outside . . . . . . . . . . . . . . . . . . . . 8 56 7. More on Rulesets . . . . . . . . . . . . . . . . . . . . . . 8 57 8. Concatenated Addressing Realms . . . . . . . . . . . . . . . 9 58 9. Multiple Overlapping Address Spaces . . . . . . . . . . . . 10 59 10. Middleboxes and Discovery . . . . . . . . . . . . . . . . . 10 60 10.1 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 10.2 Probing the Target Address . . . . . . . . . . . . . . . . . 11 62 10.3 Server Location Protocol . . . . . . . . . . . . . . . . . . 11 63 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 12. Security Considerations . . . . . . . . . . . . . . . . . . 13 65 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 The IETF Midcom Working Group is defining a protocol (or extensions 72 to one) by which an agent with application intelligence can request 73 middleboxes to install specific sets of rules for packet matching and 74 treatment [1][2]. The middleboxes of particular interest are NATs 75 and firewalls. The goal is to make it possible to separate 76 application intelligence from the actual handling of packets. The 77 Midcom Working Group has encountered a problem in doing this 78 separation -- any topology knowledge the middlebox might have, and 79 any information regarding the security of the networks attached to 80 its interfaces, is not directly available to the agent. The agent 81 apparently needs this information to make decisions about when to 82 make requests of middleboxes. This information could be made 83 available but a brute force approach would make both functions more 84 complex than they are now. 86 What is the minimum amount of information that needs to be given to 87 an agent? What approach minimizes overall system complexity? 89 2. Terminology 91 All terminology is as in the Midcom Framework [1] with the following 92 additions: 94 Addressing Realm: A contiguous part of the Internet in which all used 95 IP addresses are unique. 97 Inside: In the same addressing realm as the entity being discussed. 99 Outside: In a different addressing realm from the entity being 100 discussed. 102 Ruleset: A set of rules for middlebox packet processing which are 103 installed and removed as a unit. In particular a ruleset includes 104 at least one "filtering" or "matching" rule (e.g. any packet 105 destined for 192.168.100.1 port 42) and at least one "action" rule 106 (e.g. "let it through", "let it through with source address 107 translation to 10.0.0.25", or "discard it"). 109 Target Address: A source or destination IP address or address range 110 in a rule. 112 Informant Address: The address of the packet originator from which a 113 target address was learned by the midcom agent. The mechanism by 114 which the target address is conveyed from the informant to the 115 agent is not relevant. The mechanism could be, for example, 116 static configuration, a DNS reply or an application protocol 117 control packet. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [3]. 123 3. The Problem 125 In a network with a current NAT or firewall middlebox, the middlebox 126 sits between an "inside" area and one or more "outside" areas. The 127 middlebox applies rules to packets passing between the inside and 128 outside areas (including the possibility of dropping them). The 129 middlebox is configured to know whether a particular interface is 130 connected to an inside or outside area. The middlebox also knows the 131 egress interface for any packet it is supposed to forward -- if it 132 didn't, the network administrator would have a problem and would 133 arrange for it to have that information, either through configuration 134 or through having the middlebox participate in routing in some way. 136 However, the midcom agent may be physically separate from the 137 middlebox. There are two problems with using the midcom framework as 138 it is currently conceived. First a midcom agent will ask a middlebox 139 to install rules for packets which the agent doesn't know for sure 140 will ever pass through the middlebox in the first place. Second, it 141 doesn't know how to tell the middlebox which interfaces on the 142 outside of the middlebox should carry those packets. Proposed 143 solutions range from hand-configuration to drastically reducing the 144 Midcom Working Group's goals. 146 4. The Simplest Scenario 148 Consider a very simple scenario to start. Suppose a single agent is 149 controlling a single middlebox connecting two addressing realms, and 150 the two address spaces do not overlap. 152 The agent's client, an end system, wishes to initiate communication. 153 If the packets are going to pass through the middlebox, a ruleset 154 needs to be installed in the middlebox allowing them to do so. With 155 current NATs and firewall middleboxes, application intelligence would 156 be yet another function co-resident with the middlebox's NAT and/or 157 firewall ones. Having all these functions, the middlebox would know 158 what to do with any packet it received on any interface, and would 159 not have to install any rules before the packets arrived. With 160 Midcom, and separation of application intelligence from the middlebox 161 functions, decision has to be made whether to install a ruleset for a 162 particular packet before the packet arrives at the middlebox. 164 What if the two endpoints are both on the same side of the middlebox? 165 In this particular case, since the address spaces do not overlap, no 166 great harm is done by installing a ruleset, even if the communication 167 it allegedly supports never passes through it. The only harm would 168 be useless state information in the middlebox -- a large number of 169 useless rulesets might block the installation of other, actually 170 useful, rulesets. 172 In this simple case, with moderate use, it is probably all right to 173 use the mechanisms of the midcom protocol as currently conceived of 174 in the Midcom Framework [1] -- no new capabilities are required. 175 Heavy use does lead to the risk of exhausting middlebox resources 176 uselessly, and a new approach is required. 178 5. Overlapping Address Spaces 180 Consider a scenario like the one above except let the inside and 181 outside realms have overlapping addresses. In order for 182 communication to happen across the middlebox, both the inside and the 183 outside endpoints need to be given non-overlapping addresses by the 184 middlebox -- a classic chicken-and-egg problem. 186 This is a "Twice NAT" scenario [4]. One mechanism for dealing with 187 this, if necessary, is for an agent (or an endpoint) to request a 188 globally unique address from its local middlebox, so that when others 189 try to find that endpoint they will receive a useful address in 190 response. Another mechanism is for a middlebox or an agent to 191 monitor responses to DNS or other higher-layer requests, so that when 192 an address for an endpoint or agent is being looked for, rulesets for 193 address translation for the address being acquired can be installed 194 in its local middlebox. 196 If a NAT middlebox is monitoring DNS itself, it can just install its 197 own ruleset. If a Midcom agent is doing the monitoring, then after 198 it receives the response containing the target address it needs to 199 send a request to the middlebox to have a ruleset installed for it. 200 It uses the midcom protocol to do so. However, unlike the simple 201 case in Section 4, there are problems here. The inside and outside 202 address spaces overlap. The target address, for which a ruleset is 203 being requested, might be valid in either realm. The middlebox has 204 no way of knowing which addressing realm the agent is referring to. 205 Also, unlike the previous case, in this case an unnecessary ruleset 206 will be a security problem. We need to be sure that packets can only 207 pass through the middlebox when appropriate. 209 5.1 Should a Request Be Sent? 211 Several possible solutions for the problem of avoiding unnecessary 212 rulesets have been proposed in the Midcom Working Group, including: 214 o The agent could listen in on the domain's routing protocol and 215 only make a request of the middlebox when traffic would actually 216 pass through the middlebox. Because of this the middlebox would 217 assume that any address which was valid both inside and outside 218 would refer to an outside address. First, this would add much 219 more complexity to an agent than was intended by the Midcom 220 concept. An agent should be able to be a small bit of software, 221 perhaps resident in the same device as the middlebox function, or 222 perhaps distributed with an application. Second, the knowledge 223 that could be gained this way would be limited. The requirement 224 in the general case is to learn whether a particular destination 225 address is inside or outside from the point of view of a 226 middlebox. A distance vector routing protocol would not carry 227 this information at all, only the next hop to reach that address 228 from the agent (which could be far from the middlebox). Even with 229 a link state protocol, area boundaries abstract routing 230 information. 232 o The agent could query the middlebox for topology information 233 available at the middlebox. This would require the middlebox to 234 be able to dump a list of all network-layer prefixes on one side 235 of it -- preferably the "inside". The agent would then avoid 236 asking for rulesets for any destination covered by one of those 237 prefixes. One problem with this approach is that routing might 238 change with a network reconfiguration, but we could extend the 239 protocol so that the middlebox could instruct the agent to refresh 240 any topology information it might have. However, this approach 241 would not reduce the complexity of the system at all -- it 242 requires enough complexity at both ends of the midcom protocol 243 that midcom as a whole would probably never be accepted by users. 244 Finally, it adds a security issue because it requires the 245 middlebox to prefer outside addresses to inside ones at all times. 247 o The agent could use application-layer intelligence to determine if 248 an endpoint is inside or outside. For example, a SIP proxy could 249 parse the identifier of the callee to determine if it is within 250 its trust boundaries, or keep track of which peers were "inside" 251 and "outside" the trust boundary itself. This is a treacherous 252 layer violation and is not robust. It may require constant 253 monitoring to be sure that network layer configuration is matched 254 in agent configuration. It may require a globally unique 255 namespace for all administrative domains, something we don't have 256 or need to have in the Internet today. We don't know how this 257 layer violation will constrain our flexibility in the future. The 258 application trust boundary need not correspond to the middlebox. 259 Application entities can move around and register at IP addresses 260 on different sides of the middlebox at unknown times. Finally, 261 there is the required preference of outside addresses over inside 262 ones. 264 In reality the agent only needs to know topology information with 265 reference to the middlebox for one particular ruleset, for one 266 particular time. 268 The simplest approach is to have the agent not care whether its 269 targets are inside or outside, and to always ask for a ruleset but 270 allow for the middlebox to reply with two different kinds of 271 "success" messages: first that the communication can go ahead because 272 the ruleset is acceptable, and second that the communication can go 273 ahead because from the point of view of the middlebox such a ruleset 274 is unnecessary. This is a base for proceeding, but in itself it is 275 not enough. 277 5.2 Inside or Outside? 279 Just because the agent does not have to care if an address (or 280 address range) is inside or outside, the middlebox still needs to 281 know. The agent does not need to make that decision, but does hold 282 information the middlebox needs to do so. It acquired this 283 information when it acquired the target address. It must pass that 284 information to the middlebox. 286 The agent acquired its target addresses somehow. A target address 287 may be statically configured in the agent, or the agent may acquire 288 it through some other protocol (including DNS). In all cases, when 289 it sends a target address to the middlebox as part of a rule, the way 290 to make sure the middlebox has the proper context for interpreting 291 that address is for the agent to include, with both source and 292 destination target addresses, the "informant" address -- the address 293 of the entity from which it acquired that target address. The 294 "informant" address is locally unique in the address space shared by 295 the agent and middlebox, and thus provides an absolutely sure way for 296 the middlebox to know whether to interpret the target address in 297 "inside" or "outside" context. 299 If the target address was learned from an informant in another 300 addressing realm on the other side of the middlebox, the informant's 301 remote address will have been translated into a locally unique 302 address. If the target address was learned from a target or an 303 informant in the same addressing realm, the informant address could 304 be the same as the target address, or perhaps be that of its local 305 DNS server, or agent. If the target address is statically 306 configured, the agent could list itself as the informant (note this 307 would make it impossible for an "outside" address to be statically 308 configured, although a statically configured locally unique 309 translation of one could be). As a default rule of last resort, to 310 close off security problems, the middlebox can give precedence to 311 inside addresses. 313 Thus, in most cases the informant address is all the middlebox needs 314 to determine the addressing realm in which the target address is to 315 be interpreted. 317 5.3 Wildcards 319 Sometimes an agent will want to install a matching rule for a source 320 or destination range of addresses, for example in order to allow 321 calls to come in to a server. Often any caller is acceptable and 322 "inside" and "outside" do not matter. However, there will certainly 323 be cases where an agent wants a server to be able to accept calls 324 from a range of addresses only as long as they are "inside". We want 325 to allow this restriction, and even default to it, but not require 326 it. To handle this case, we add one more attribute to each of the 327 addresses specified in matching rules: an "outside okay" flag, which 328 says that an outside address is allowable, and that if an address is 329 valid both inside and outside the middlebox, the outside should be 330 chosen. 332 6. Agent on the Outside 334 Consider the case where the agent is in a public realm (for example 335 an ISP) and the two endpoints are in the same private realm. The 336 same principles hold and no new mechanisms are necessary. The agent 337 will have acquired the target addresses from an informant. The 338 target addresses may only be meaningful in the informants' addressing 339 realms, but the address for the informant will be unique and 340 meaningful in the addressing realm shared by the agent and the 341 middlebox. When the agent sends a ruleset request to the middlebox, 342 specifying the target addresses and informant addresses, the 343 informant addresses will allow the middlebox to determine that both 344 the addresses are "outside", and it will respond that no ruleset 345 installation is necessary. 347 7. More on Rulesets 349 Because an agent usually does not know if a target address is inside 350 or outside when it first passes it to the middlebox, rules cannot 351 generally be phrased in terms of inside and outside addresses -- only 352 whether an outside address is acceptable. Because directionality is 353 important (for example, ports may differ), rules must be phrased in 354 terms of source and destination. 356 There was a proposal in the Midcom Working Group that the midcom 357 protocol should include actual interfaces as attributes for addresses 358 in matching rules. Besides the fact that it is extremely complex for 359 the agent to able to keep track of the middlebox's interfaces and 360 what they are connected to, let alone specify them in a way that is 361 mutually understandable, it is not necessary. If the agent includes 362 the addresses of its informants and an "outside okay" flag, it tells 363 the middlebox all it needs to know how to reach the target addresses 364 and to determine if installing a ruleset is necessary. 366 8. Concatenated Addressing Realms 368 There are several scenarios in which more than two addressing realms 369 are involved. 371 Suppose an agent is in one addressing realm and the two endpoints are 372 reachable through two different middleboxes connected to that realm. 373 The agent needs to install a ruleset in each middlebox. In this case 374 the mechanism described above works well. Informant addresses, as 375 received at the agent, are always unique and meaningful in the 376 addressing realm of the agent. The agent sends the target addresses 377 and informant addresses to each middlebox. At each middlebox one 378 informant address will be "outside", and the associated target 379 address will be interpreted as such, while the other will appear to 380 be on the inside (the same side as the agent). The ruleset will be 381 installed. 383 The "informant address" technique will not work if the target 384 addresses provided by informants are not meaningful to the relevant 385 middleboxes -- for example, if an endpoint is more than one 386 addressing realm away from the midcom agent and the informant 387 provides an address which is only meaningful in the endpoint's local 388 addressing realm. In order for an agent to establish connectivity 389 between two endpoints, both of them need to be represented by IP 390 addresses which are unique within the space in which they will be 391 used. Fortunately it looks like the implementations and strategies 392 proposed so far do follow this rule. A DNS server representing 393 endpoints in a NATted addressing realm will respond with global 394 addresses, and an agent can acquire a global (or at least non-local) 395 address for its client in advance with the help of the middlebox and 396 the midcom protocol as described here. 398 Similarly, the "informant address" technique will not work if the 399 agent is trying to control a middlebox through an intervening NAT. 400 The agent and middlebox must share an addressing realm in order for 401 the midcom protocol to be able to carry addresses as data 402 meaningfully. Situations where it would be appropriate to run the 403 midcom protocol through a NAT might not exist at all. Those networks 404 would be less secure and more difficult to manage. If such 405 situations did exist, an explicit fix would be to require what agents 406 seem to be inclined to do anyway, which is to acquire a global 407 address for any client before it begins communicating. In the worst 408 case, if nothing else is possible, a subsidiary controller can be 409 installed in the address realm on the other side of the NAT. 411 Given that these situations are unlikely, and that there are 412 workarounds for both of them, elaborating the midcom protocol to 413 provide general support for unlikely and probably undesirable 414 situations is not worth the complexity it would require. 416 9. Multiple Overlapping Address Spaces 418 There is a situation which is theoretically possible, but which 419 current NATs don't handle. It may become possible in the future. 420 Assume there is only one middlebox NAT function, but let it interface 421 between more than two overlapping address spaces. This could be made 422 possible using the "informant address" and "outside okay" mechanisms. 424 10. Middleboxes and Discovery 426 The problem of finding the right middlebox to make requests of 427 overlaps somewhat with how those requests are made, so we discuss the 428 discovery problem briefly. 430 Middlebox discovery is important in order to find a middlebox at all, 431 to find a middlebox which is appropriate for the ruleset the agent 432 wants to install, and to find a middlebox which can handle the 433 expected load. Draft-lear-middlebox-discovery-requirements-00.txt 434 [5] lists some requirements. One of those requirements was that no 435 endpoint or agent should be required to participate in routing, which 436 the scheme proposed here satisfies. 438 10.1 Anycast 440 It might be possible to use anycast and avoid having any explicit 441 discovery mechanism at all -- the agent would simply launch queries 442 at an anycast address appropriate for middleboxes of a particular 443 type. 445 However, anycast literally finds any target. The only way to 446 discriminate between middleboxes using anycast would be to use 447 different addresses. It's very likely that we will want to be able 448 to discriminate between middleboxes much more flexibly than just by 449 IP address. For example some middleboxes might be connected to some 450 outside realms while others were connected to others. 452 Also, anycast is intended for one-time or at least short duration 453 interactions, since if routing changes the destination found by an 454 anycast packet may change. This would be a problem for any 455 association which has synchronized state. The midcom protocol 456 already has a long-lasting association -- 457 authentication/authorization and capability negotiation are done for 458 the middlebox to start with, and it is expected that 459 authentication/authorization for each request after that will depend 460 on that initial exchange. 462 10.2 Probing the Target Address 464 Tunnel Endpoint Discovery (TED) [6] is for finding IKE 465 intermediaries. Its approach could possibly be reused. TED sends a 466 special probe packet toward the target address, which is actually 467 intended for any appropriate intermediary. If an authorized 468 intermediary notices the packet it intercepts it and responds. A 469 similar probe could be used to discover middleboxes. 471 If there were multiple disjoint connections between the agent's 472 domain and the outside world, this would ensure that the agent 473 established an association with the appropriate middlebox for that 474 particular needed ruleset. 476 The problem with using special probes like this is the very basic 477 issue that the agent should not have to know if a target address is 478 inside or outside the middlebox. If the agent launches a probe 479 toward an address which is on the same side of the middlebox, it will 480 get no response. What has it learned then? TED is a different case, 481 in that discovery of a tunnel endpoint is required for the service to 482 be provided at all. 484 10.3 Server Location Protocol 486 If middlebox discovery used SLP, a request for a middlebox "service" 487 could be given detailed attributes, including the entire ruleset 488 needed. A domain could create its own policies for deciding which 489 middlebox a particular agent should use for a particular ruleset, and 490 change them arbitrarily. In particular this arbitrariness would 491 allow complex topologies, middleboxes with differing capabilities -- 492 in series as well as in parallel -- and spontaneous changes in 493 administrative relationships. Different outside domains could be 494 reached via different middleboxes at different times of the day and 495 so on. 497 SLP uses multicast, which some may think is a problem. However in 498 simple situations discovery is not necessary, as demonstrated above 499 for simple scenarios, and in complex situations unicast SLP can be 500 used. 502 Thus, SLP might be useful for middlebox discovery. The mechanisms 503 proposed in this document do not have any architectural conflict with 504 using SLP. 506 The mechanisms proposed in this document do lead the agent to ask an 507 SLS about every ruleset request. There are a number of possible 508 means to cut back on SLP activity and to reduce the potential scaling 509 problem. For example, the ability to ask SLP about ranges, the 510 ability of the SLP responses to include ranges and TTLs, and the 511 possibility of information being "pushed". If SLP is actually 512 selected as a base for middlebox discovery, and the rate of SLP 513 activity is seen as a problem, we could explore ways to make this 514 approach scale. 516 11. Summary 518 The problem is that an agent does not know whether to ask for a 519 ruleset to be installed or not. 521 To solve this problem without adding an overwhelming amount of 522 complexity to every agent and middlebox: 524 o The agent queries the middlebox about every possible ruleset. The 525 agent does not have to know if packets for a particular 526 association would pass through a middlebox or not. 528 o In a query the agent says what the two endpoint addresses are that 529 it will need to be able to establish an association between 530 (wildcards are allowed). Each specific address or address range 531 has associated with it an "outside okay" attribute and the address 532 of the "informant" from which the agent learned that address. An 533 informant address could be the address of the agent itself, for 534 example in the case of static configuration, the address of some 535 other helper, or the address of one of the endpoints. 537 o The middlebox has a new type of reply to such queries, which is 538 that the query has succeeded through no rules being necessary 539 (since that association will not pass through the middlebox). 541 This scheme adds no extra management burden, either locally or 542 globally, nor does it add any of the concomitant security risk that 543 extra configuration brings in a dynamic network environment. It does 544 not threaten Internet scalability or robustness. It does not create 545 new layer violations. It adds three simple pieces of information to 546 the coalescing midcom protocol. 548 Middlebox discovery is still a poorly explored area, but this scheme 549 appears to work with middlebox discovery mechanisms at least as well 550 as any other proposal. 552 There are restrictions on the applicability of this approach, but the 553 cost of creating a protocol to cover the unusual scenarios which this 554 approach does not is not worth paying. 556 There are several loose ends to be explored, but none that call the 557 basic protocol mechanisms into question. 559 12. Security Considerations 561 The topology knowledge which a middlebox uses to make decisions about 562 whether to install a ruleset or not is no more secure than the source 563 of that knowledge, which is either configuration or routing 564 protocols. 566 The transfer of specific knowledge between the middlebox and the 567 midcom agent is only as secure as the midcom protocol. There are 568 requirements for mutual authentication of middlebox and agent. 569 However, the protocol has not yet been specified or implemented and 570 cannot be analyzed for security problems. 572 The middlebox may be misled into opening up trust boundaries if 573 "inside" versus "outside" is not explicitly indicated, or if an agent 574 gets confused over the origin from which it learned a particular 575 address. 577 References 579 [1] Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan, 580 "Middlebox Communication Architecture and framework", Internet 581 Draft draft-ietf-midcom-framework-03.txt, July 2001. 583 [2] Swale, R., Mart, P. and P. Sijben, "Middlebox Control (MIDCOM) 584 Protocol Architecture and Requirements", Internet Draft draft- 585 ietf-midcom-requirements-02.txt, July 2001. 587 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 588 Levels", BCP 14, RFC 2119, March 1997. 590 [4] Srisuresh, P. and M. Holdredge, "IP Network Address Translator 591 (NAT) Terminology and Considerations", RFC 2663, August 1999. 593 [5] Lear, E., "Requirements for Discovering Middleboxes", Internet 594 Draft draft-lear-middlebox-discovery-requirements-00.txt, April 595 2001. 597 [6] "Tunnel Endpoint Discovery Enhancement", February 2001, 598 599 . 601 Authors' Addresses 603 Scott Brim 604 Cisco Systems, Inc. 605 146 Honness Lane 606 Ithaca, NY 14850 607 USA 609 EMail: sbrim@cisco.com 611 Adina Simu 612 Cisco Systems, Inc. 613 170 West Tasman Drive 614 San Jose, CA 95134 615 USA 617 EMail: asimu@cisco.com 619 Full Copyright Statement 621 Copyright (C) The Internet Society (2001). All Rights Reserved. 623 This document and translations of it may be copied and furnished to 624 others, and derivative works that comment on or otherwise explain it 625 or assist in its implementation may be prepared, copied, published 626 and distributed, in whole or in part, without restriction of any 627 kind, provided that the above copyright notice and this paragraph are 628 included on all such copies and derivative works. However, this 629 document itself may not be modified in any way, such as by removing 630 the copyright notice or references to the Internet Society or other 631 Internet organizations, except as needed for the purpose of 632 developing Internet standards in which case the procedures for 633 copyrights defined in the Internet Standards process must be 634 followed, or as required to translate it into languages other than 635 English. 637 The limited permissions granted above are perpetual and will not be 638 revoked by the Internet Society or its successors or assigns. 640 This document and the information contained herein is provided on an 641 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 642 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 643 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 644 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 645 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Acknowledgement 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.