idnits 2.17.1 draft-floyd-pushback-messages-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '...ing pushback. It MUST be unique among ...' RFC 2119 keyword, line 132: '...ssion. A router MAY use its different...' RFC 2119 keyword, line 136: '... realm, then it MUST be altered upon ...' RFC 2119 keyword, line 290: '...quest upstream, the router MUST insert...' RFC 2119 keyword, line 295: '... MUST be checked to see whether they...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'MB01' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sally Floyd/ACIRI 2 INTERNET DRAFT Steve Bellovin/AT&T 3 draft-floyd-pushback-messages-00.txt John Ioannidis/AT&T 4 Kireeti Kompella/Juniper 5 Ratul Mahajan/UW 6 Vern Paxson/ACIRI 7 July, 2001 8 Expires: January, 2002 10 Pushback Messages for Controlling Aggregates in the Network 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 34 1. Introduction 36 Pushback [MB01] is designed to detect and control high bandwidth 37 aggregates in the network. An aggregate is a collection of packets 38 with a common property. For instance, with the destination prefix as 39 the common property, all packets with a matching prefix define an 40 aggregate. During a time of severe congestion from a flash crowd or 41 from a denial of service (DoS) attack, a router might enforce a rate- 42 limit on the traffic aggregate responsible for the congestion. In 43 addition, the congested router could ask adjacent upstream routers to 44 limit the amount of traffic they send for that aggregate. This 45 upstream rate-limiting is called pushback and can be recursively 46 propagated to routers further upstream. It serves to spatially 47 isolate the traffic aggregate so that other traffic sharing the same 48 downstream links is not impaired by the aggregate. 50 By imposing only a rate limit, rather than a complete blockage, of 51 the aggregate, pushback aims to minimize "collateral damage" suffered 52 by the non-hostile traffic matching the aggregate during a DoS 53 attack. In general, the hope is that during a DoS attack, pushback 54 will propagate sufficiently far in the network so that non-hostile 55 traffic fits within the rate limit imposed on its specific path to 56 the destination, and accordingly does not have its performance 57 limited. 59 This document specifies messages passed between cooperating routers. 60 It does not address procedures in routers for identifying aggregates 61 to be rate-limited, or for determining the rate-limits for those 62 identified aggregates. The goal is to specify an experimental 63 standard for pushback messages so that we can learn from the 64 experimental use of pushback. We expect that the specifications for 65 pushback messages will evolve over time, as we gain more experience 66 with their use. 68 There are two main pushback messages - REQUEST and STATUS. Pushback 69 REQUEST messages are sent to upstream routers asking them to rate- 70 limit the aggregate. Such a request for rate-limiting is only 71 advisory; the upstream router is not compelled to follow the request. 72 As part of rate-limiting on behalf of the downstream router, the 73 upstream router sends periodic STATUS messages to the downstream 74 router. The STATUS messages report the arrival rate for that 75 aggregate at the upstream router, and enable the congested router to 76 take decisions regarding the continuance of pushback. In addition to 77 REQUEST and STATUS messages, REFRESH messages reinforce the soft- 78 state rate-limiting, and CANCEL messages terminate it. 80 Pushback messages can be used in two ways. In one pushback type, 81 pushback messages are used to request upstream rate-limiting for the 82 specified aggregate. In a second pushback type (DUMMY_PROP), 83 pushback messages are used simply to get information about the 84 arrival rates of an aggregate at upstream routers. 86 A pushback in progress can be visualized as a tree (or, with 87 multipath routing, possibly a graph), where the congested router 88 initiating the pushback is the root. The parent of a router in the 89 tree is the downstream router from which it got the pushback REQUEST. 90 Routers that do not propagate pushback further are leaves of the 91 tree. 93 The following sections specify the format for pushback messages and 94 the timing of REFRESH and STATUS messages. This document also 95 specifies the procedures for propagating pushback REQUEST and REFRESH 96 messages further upstream, and for merging the resulting STATUS 97 messages from upstream routers. 99 2. The Common Header 101 All pushback messages have the following fields prepended in the 102 header. 104 0 1 2 3 105 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Version |AdF| Msg Type | Rate-Limiting Session ID | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Pushback Initiating Router's IP Address | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Sender's IP Address | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 The first field specifies the version of the pushback protocol the 115 sender speaks. The protocol described in this document is Version=0. 117 "AdF" specifies the type of address family used. Currently defined 118 values are IPv4=0 and IPv6=1. Other values are reserved for future 119 definition. 121 The message type is one of REQUEST (= 0), REFRESH (= 1), STATUS (= 122 2), or CANCEL (= 3). The fields following the common header are 123 dependent on the type of the message. 125 The Rate-limiting Session ID (RLSID) is generated by the congested 126 router initiating pushback. It MUST be unique among all current rate- 127 limiting sessions initiated by this router. The RLSID combined with 128 the IP address of the congested router defines a pushback session 129 over the whole network. A router receives both these fields from the 130 downstream router requesting pushback. These fields enable the 131 routers to map incoming messages to the appropriate rate-limiting 132 session. A router MAY use its different addresses when initiating 133 different pushback sessions. 135 Note that if the router's address reflects a private addressing 136 realm, then it MUST be altered upon crossing into a different 137 addressing realm. Ideally this transformation uses a new address 138 unique to the router; if not available, then the address of the 139 router propagating pushback (by sending the message) into the 140 different realm is used. 142 The sender's IP address has been included in the pushback message, 143 making message interpretation independent of the IP source address 144 field. This eliminates any confusion regarding which interface's 145 address is included in that field (that is, whether it is the IP 146 address of the message-sending interface, or of some other interface 147 at the router). It also helps when pushback messages traverse 148 between routers that are not directly connected. If a sender sends 149 pushback messages to two peers in two different addressing realms, so 150 that the sender doesn't have a unique address to send to both peers, 151 then the sender will use different values for the sender's IP address 152 in the two messages. 154 Both the IP addresses will be 128 bit fields for IPv6. 156 2. The Pushback REQUEST Message 158 Pushback requests (type REQUEST=0) are sent upstream when a router 159 wants the aggregate to be rate-limited upstream. The fields in a 160 pushback REQUEST, in addition to the common header, are shown below. 162 0 1 2 3 163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | PType |SRMode | Max Depth | Depth in Tree | Reserved | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Bandwidth Limit | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Expiration Time | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Status Frequency | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 | Congestion Signature | 175 ............................................... 176 ............................................... 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 "PType" denotes the type of pushback and determines the upstream 181 router's behavior in various ways. PType=0 (HI_DROP_PROP) requests 182 the upstream router to propagate pushback if the restricted aggregate 183 suffers a high drop rate due to the restriction. (This is the usual 184 mode of pushback.) 186 PType=1 (ALWAYS_PROP) requests that the upstream router propagate 187 pushback irrespective of the drop rate experienced by the aggregate. 188 It would typically be used when the aggregate is known with high 189 confidence to be malicious. 191 PType=2 (DUMMY_PROP) indicates no actual rate-limiting should take 192 place---the downstream router is just interested in the arrival rate 193 estimate of this aggregate. The extent of propagation of these 194 pushback messages is controlled by the congested router using "Max 195 Depth" (explained below) to determine the arrival rate of an 196 aggregate several hops upstream. 198 Other values of PType are reserved for future definition. 200 The pushback requester can specify the mode in which it wants 201 feedback with the "SRMode" (Status Reporting Mode) field. SRMode=0 202 (COMPACT) specifies the feedback should be just the total arrival- 203 rate estimate of the aggregate. SRMode=1 (CLOSEST) specifies the 204 feedback should include per-router feedback for upstream routers, and 205 if there is not room for all of them, then those closest (lowest hop 206 count) should be preferred. SRMode=2 (FURTHEST) is similar to 207 CLOSEST, but prefers routers further away from the congested router. 208 SRMode=3 (SAMPLE) specifies that instead a pseudo-random subset of 209 the upstream routers should be included. These last two modes 210 facilitate different forms of mapping to aid with tracing back the 211 attack sources. Other values are reserved for future definition. 213 Using "Max Depth" the congested router can control the maximum number 214 of hops pushback will propagate to. The special value of 255 215 indicates unrestricted propagation; 254 indicates that pushback 216 should be propagated up to, but not across, the AS boundary. 218 The depth in the tree is the distance of the requesting node from the 219 root of the pushback tree. The depth of the root is zero, and a 220 child's depth is one more than the depth of its parent. Depth 221 information is useful in setting timers for sending feedback. If a 222 router receives overlapping pushback requests from multiple peers, 223 its depth is one more than the minimum depth of its parents. 225 The bandwidth limit is a single precision (32-bit) floating point 226 number in IEEE format, as described in [SPG97]. It expresses the 227 rate in bytes per second. It is only a requested upper bound for the 228 bandwidth to be given to the aggregate. If congested, the upstream 229 router could send less than that upper bound. In addition, the 230 upstream router is not *required* to observe the requested bound. 232 The expiration time is the time period after which the pushback 233 request expires if no REFRESH messages arrive. The status frequency 234 gives the time after which the upstream routers should send STATUS 235 messages downstream. Both the times are specified in milliseconds, 236 and represented using 32-bit integers in network byte order. 238 2.0.1 The Congestion Signature 240 The congestion signature is the description of the aggregate that is 241 to be rate-limited. Its specification is a major open question. As 242 an example, the attack signature might consist of the destination 243 prefix(es) characterizing the aggregate. At the other extreme, we 244 could allow arbitrary ACLs of fields in the packet header. For this 245 first experimental use of pushback, we will limit the congestion 246 signature to depend only on the source and destination IP addresses 247 in the packet header. This excludes the use of aggregates defined by 248 the protocol field in the IP header and the port numbers in the 249 transport header; an example is an aggregate consisting of all DNS 250 traffic. 252 Congestion signatures are specified as TLVs (type-length-value): 254 0 1 2 3 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type | Length | Value .... | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 ............................................... 260 .....................Value..................... 261 ............................................... 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | .... Value and final Padding .... | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 The Length field includes the Type and Length fields, as well as the 267 length of the Value and any Padding. 269 Values are padded up to 32-bit alignment. If, after doing so, more 270 data remains in the datagram, then it's interpreted as another TLV. 272 Type=0 (SRC_PREFIX) indicates a source address prefix. Its Length is 273 4 bytes plus the length of an address in the format specified by AdF 274 above. The first octet of Value (bits 16 through 23 in the first 275 line of the above figure) are reserved. The second octet gives the 276 prefix length, in the range 1-32 (IPv4) or 1-128 (IPv6). Other 277 values are reserved. 279 Type=1 (DST_PREFIX) is the same but for destination address prefix. 281 When all prefixes in the list are of the same type, the congestion 282 signature describes packets that have the corresponding field (source 283 or destination) matching one of the prefixes in the list. In 284 presence of both source and destination prefixes, packets belonging 285 to the aggregate are those destined for one of the destination 286 prefixes *and* coming from one of the source prefixes. 288 2.1 Propagating a Pushback REQUEST Message 290 When propagating a pushback request upstream, the router MUST insert 291 the correct depth information, which is one more than the depth of 292 its parent(s). 294 In addition, the destination prefixes in the congestion signature 295 MUST be checked to see whether they have to be *narrowed*, to 296 restrict the rate-limiting only to traffic headed for the downstream 297 router that requested pushback, as follows. Suppose the congested 298 router X identifies a certain aggregate A with destination prefix 299 128.95/16. X will ask its upstream router Y (among others) to rate- 300 limit traffic from aggregate A (128.95/16). However, Y cannot use 301 the same specification directly because while Y could be forwarding 302 128.95.1/24 to X, it might not be forwarding the rest of 128.95/16 to 303 X. If Y (and routers upstream of Y) started rate-limiting all of 304 128.95/16, the network would drop traffic which would not have 305 reached the congested router X. 307 To avoid this unnecessary packet-dropping, it is important that Y 308 look at its routing table to find prefixes within 128.95/16 that are 309 forwarded to X. Y has to check all extensions of the given prefix in 310 the routing table. 312 The issue of narrowing the congestion signature occurs when a 313 pushback request is propagated upstream by a router (thus becoming a 314 non-leaf in the tree), or when the pushback request is passed from 315 the output interface to an input interface at a router. The above 316 algorithm for narrowing the congestion signature works only for 317 congestion signatures with a destination address component in them. 318 It cannot be applied to other signatures, pure source-based ones, for 319 instance. We do not deal with the issue of narrowing non- 320 destination-based signatures in this document except noting that it 321 can be done given the right routing information at the upstream 322 router. 324 A router could receive requests from different downstream routers 325 with overlapping congestion signatures. Future work might address 326 the possibility of merging two different rate-limiting sessions in 327 this case. 329 2.2 Pushback REFRESH Messages 331 Pushback REFRESH messages are initiated by the congested router that 332 started the pushback, if it wants the pushback to continue. For 333 uninterrupted rate-limiting, these messages should be generated 334 before the rate-limiting expires at the upstream routers 336 The REFRESH message is identical to the REQUEST message, so that if 337 the upstream router has crashed in the meanwhile, the state can be 338 reestablished. However, the message type is set to REFRESH so that, 339 if state already exists, it is matched against the RLSID and router 340 address fields so that the receiving router does not have to go 341 through the process of setting up state from scratch. 343 REFRESH messages can change any field specified earlier in the 344 pushback REQUEST. On receiving the pushback REFRESH message the 345 upstream routers update the expiration time for the rate-limit 346 session and the limit imposed on the aggregate, and set the timer for 347 the STATUS message. Non-leaf routers in the pushback tree SHOULD 348 send REFRESH messages further upstream after dividing the rate limit 349 among upstream neighbors. If the aggregate specification has 350 changed, the router MUST check if the new aggregate needs to be 351 narrowed, using the process described above, before propagating the 352 pushback REFRESH. 354 2.3 Pushback CANCEL Messages 356 The pushback CANCEL message is sent upstream to stop rate-limiting 357 the aggregate. It SHOULD be propagated upstream by routers that have 358 propagated pushback requests (non-leaf routers in the pushback tree). 360 The CANCEL message has no fields beyond those present in the common 361 header. 363 3. Pushback STATUS Messages 365 Upstream routers that receive a pushback REQUEST send pushback STATUS 366 messages to the router from whom they got their REQUEST. The 367 additional fields in the STATUS message are: 369 0 1 2 3 370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Arrival Rate Estimate | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | SRMode| Rsrvd | Height | NumElem | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | | 378 | | 379 ............................................... 380 ................................................ 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 The arrival rate estimate is a single precision floating-point number 385 in IEEE format, as described in [SPG97]. It expresses the arrival 386 rate of the aggregate in bytes per second if there was no rate- 387 limiting upstream of the STATUS sender. The arrival rate for the 388 first STATUS message is computed over the interval since the receipt 389 of the pushback REQUEST. For the subsequent messages, it is computed 390 over the interval since the last STATUS message. 392 The SRMode field specifies the mode in which status is reported. It 393 is the same as that in the pushback REQUEST message. The supported 394 modes and their semantics are described in Section 2. 396 "Height" denotes the height of the sender in the pushback tree. It is 397 zero for leaf nodes, and one more than the maximum height among 398 children for non-leaf nodes. This field tells the receiver how far 399 pushback has propagated upstream of it. 401 For status modes that return a list of routers, NumElem gives the 402 number of listed routers. Then, for each router 404 * Router ID gives an address identifying the router 405 * Router Info gives information associated with the router. 406 Currently, this consists of: 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |S| Reserved | Depth in Tree | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 S is a bit that if set means that the entry is Stale, meaning that no 415 new STATUS message has been received from the router since the last 416 time the sending router sent a STATUS message. 418 Depth in Tree reflects the depth of the router in the pushback tree. 420 3.1 Aggregating STATUS Messages 422 A parent node uses the STATUS messages from its children to construct 423 the STATUS message it sends downstream. The merger technique used 424 depends on the mode of the STATUS message. In COMPACT mode, the 425 parent node adds the arrival rate estimates received from the 426 children and its estimate from upstream routers that were not sent 427 pushback messages. In other modes, the lists obtained from the 428 various children are merged, and appended with the parent node's own 429 estimate, as indicated in the previous section. The height is one 430 more than the maximum height recieved from the children. 432 3.2 Timing of STATUS Messages 434 The status frequency specified in the pushback REQUEST and REFRESH 435 messages is the rate at which the originating router would like to 436 receive status reports. Since the upstream routers are at different 437 distances from the root, the timer values they set have to be 438 different. In particular, routers further away from the root should 439 set smaller timer values because they get messages late and their 440 STATUS messages take time getting to the root node. 442 On receiving a REQUEST or REFRESH message, the routers set a timer to 443 send the STATUS message. The value of this timer is the status 444 frequency minus the _depth_ * _k_, where _depth_ is the router's 445 depth in the pushback tree, and _k_ is a constant that signifies the 446 maximum round trip time for a message over a pushback tree edge 447 (including message processing time). _k_ should be configured to 448 some comfortable upper bound like 100 ms (it is same for all the 449 routers in the pushback tree). For satellite hops or other links 450 with round-trip times greater than the configured value _k_, the 451 consequences will simply be stale STATUS messages. 453 Setting timers in this fashion means that parents are likely to 454 obtain fresh STATUS messages from their children before their own 455 STATUS message timer goes off. This in turn means that fresh STATUS 456 messages are sent further downstream after aggregation. If a parent 457 router's timer fires before it has received STATUS message from one 458 of its children, it MUST send its own STATUS message downstream using 459 the last value received from this child or its own estimate, and, if 460 including an individual rate report for this child, marking it with 461 S=1 to indicate it is Stale. 463 The status timer is set again immediately after sending the STATUS 464 messages downstream. The value of the timer is the same for all the 465 routers in this case, and is equal to the status frequency, since the 466 required offset has already been achieved. If a router receives a 467 REFRESH message before its status timer expires, new timers are set 468 as described above. 470 A small jitter can be applied to status timers so that the downstream 471 router recieves STATUS messages from its children at different times. 473 In some cases, the original sender of the pushback REQUEST might want 474 some variation in the status timers to provide some degree of 475 protection against gaming adversaries that try to time their bursts 476 to avoid detection. This variation could be achieved by the original 477 sender by making changes to the Status Frequency specified in the 478 pushback REFRESH messages. 480 4. Authentication for Pushback Messages 482 Pushback messages require some form of authentication, even if the 483 pushback messages are between adjacent routers. However, this 484 document currently does not specify the form of authentication to be 485 used. 487 5. Messages between Routers and Local Agents 489 Some routers might send packet headers from a sample of the traffic 490 to an agent for outboard processing, and receive control messages 491 back from the agent about identified aggregates to be rate-limited. 492 The router and local agent will also exchange control messages, for 493 example, to control the sampling at the router. The formats for 494 these messages will probably be addressed in a separate document. 496 Because this is a purely local conversation between a router and an 497 attached local agent, it is not necessary that a router and its 498 attached local agent follow the protocol suggested in that document. 500 6. Messages exchanged with the NOC 502 In some cases the NOC (Network Operations Center) will want to have 503 final approval before an aggregate is rate-limited. Thus, one 504 category of pushback messages will be the messages exchanged with the 505 NOC. This draft currently does not specify these messages. 507 Conclusions 509 Acknowledgements 511 There is a list of people who can be either co-authors, or can be 512 acknowledged in this section. So far, this list includes the 513 following. The pushback authors: Ratul Mahajan, Steven M. Bellovin, 514 Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker. From 515 Juniper: Kireeti Kompella. From Cisco: Barbara Fraser, David Meyer. 516 Other: Randy Bush. 518 References 520 [MB01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John 521 Ioannidis, Vern Paxson, and Scott Shenker, Controlling High Bandwidth 522 Aggregates in the Network, February 2001. URL: 523 "http://www.aciri.org/pushback/". 525 [SPG97] S. Shenker, C. Partridge, R. Guerin. Specification of 526 Guaranteed Quality of Service. RFC 2212. September 1997. 528 Security Considerations 530 We will eventually address the potential DoS features and security 531 vulnerabilities of pushback in detail here. 533 IANA Considerations 535 AUTHORS' ADDRESSES 537 Sally Floyd 538 Phone: +1 510 666 2989 539 ACIRI 540 Email: floyd@aciri.org 541 URL: http://www.aciri.org/floyd/ 542 Steve Bellovin 543 Phone: +1.973.360.8656 544 AT&T Labs - Research 545 Email: smb@research.att.com 547 John Ioannidis 548 Phone: +1.973.360.7012 549 AT&T Labs - Research 550 Email: ji@research.att.com 552 Kireeti Kompella 553 Juniper Networks 554 1994 N. Mathilda Ave 555 Sunnyvale, CA 94089 556 Email: kireeti@juniper.net 558 Ratul Mahajan 559 Phone: +1 206 616 1853 560 Univerity of Washington 561 Email: ratul@cs.washington.edu 562 URL: http://www.cs.washington.edu/homes/ratul/ 564 Vern Paxson 565 Phone: +1 510 666 2882 566 ACIRI 567 Email: vern@aciri.org 568 URL: http://www.aciri.org/vern/ 570 This draft was created in July 2001. 571 It expires January 2002.