idnits 2.17.00 (12 Aug 2021) /tmp/idnits12731/draft-iab-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 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. ** 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 240: '... This section SHOULD NOT contain det...' RFC 2119 keyword, line 242: '...s and XML schema SHOULD NOT be shown. ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 166 has weird spacing: '...request it pr...' -- 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) == Missing Reference: 'SYNFLOOD' is mentioned on line 630, but not defined ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: draft-ietf-dccp-ccid2 has been published as RFC 4341 == Outdated reference: draft-ietf-dccp-ccid3 has been published as RFC 4342 == Outdated reference: draft-ietf-dccp-spec has been published as RFC 4340 ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1510 (ref. 'KERBEROS') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 2518 (ref. 'WEBDAV') (Obsoleted by RFC 4918) Summary: 19 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 E. Rescorla 2 RTFM, Inc. 3 INTERNET-DRAFT IAB 4 draft-iab-model-01.txt May 2004 (Expires November 2004) 6 Writing Protocol Models 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 The IETF process depends on peer review. However, IETF documents are 30 generally written to be useful for implementors, not for reviewers. 31 In particular, while great care is generally taken to provide a com- 32 plete description of the state machines and bits on the wire, this 33 level of detail tends to get in the way of initial understanding. 34 This document describes an approach for providing protocol "models" 35 that allow reviewers to quickly grasp the essence of a system. 37 1. Introduction 39 The IETF process depends on peer review. However, in many cases, the 40 documents submitted for publication are extremely difficult to 41 review. Since reviewers have only limited amounts of time, this leads 42 to extremely long review times, inadequate reviews, or both. In my 43 view, a large part of the problem is that most documents fail to pre- 44 sent an architectural model for how the protocol operated, opting 45 instead to siply describe the protocol and let the reviewer figure it 46 out. 48 This is acceptable when documenting a protocol for implementors, 49 because they need to understand the protocol in any case, but dramat- 50 ically increases the strain on reviewers. Reviewers necessarily need 51 to get the big picture of the system and then focus on particular 52 points. They simply do not have time to give the entire document the 53 attention an implementor would. 55 One way to reduce this load is to present the reviewer with a 56 MODEL--a short description of the system in overview form. This pro- 57 vides the reviewer with the context to identify the important or dif- 58 ficult pieces of the system and focus on them for review. As a side 59 benefit, if the model is done first, it can be serve as an aid to the 60 detailed protocol design and a focus for early review prior to proto- 61 col completion. The intention is that the model would either be the 62 first section of the protocol document or be a separate document pro- 63 vided with the protocol. 65 2. The Purpose of a Protocol Model 67 A protocol model needs to answer three basic questions: 69 1. What problem is the protocol trying to achieve? 70 2. What messages are being transmitted and what do they 71 mean? 72 3. What are the important but un-obvious features of the 73 protocol? 75 The basic idea is to provide enough information that the reader could 76 design a protocol which was roughly isomorphic to the protocol being 77 described. This doesn't, of course, mean that the protocol would be 78 identical, but merely that it would share most important features. 79 For instance, the decision to use a KDC-based authentication model is 80 an essential feature of Kerberos [KERBEROS]. By constrast, the use of 81 ASN.1 is a simple implementation decision. S-expressions--or XML, had 82 it existed at the time--would have served equally well. 84 3. Basic Principles 86 In this section we discuss basic principles that should guide your 87 presentation. 89 3.1. Less is more 91 Humans are only capable of keeping a very small number of pieces of 92 information in their head at once. Since we're interested in ensuring 93 that people get the big picture, we therefore have to dispense with a 94 lot of detail. That's good, not bad. The simpler you can make things 95 the better. 97 3.2. Abstraction is good 99 A key technique for representing complex systems is to try to 100 abstract away pieces. For instance, maps are better than photographs 101 for finding out where you want to go because they provide an 102 abstract, stylized, view of the information you're interested in. 103 Don't be afraid to compress multiple protocol elements into a single 104 abstract piece for pedagogical purposes. 106 3.3. A few well-chosen detail sometimes helps 108 The converse of the the previous principle is that sometimes details 109 help to bring a description into focus. Many people work better when 110 given examples. Thus, it's often a good approach to talk about the 111 material in the abstract and then provide a concrete description of 112 one specific piece to bring it into focus. Authors should focus on 113 the normal path. Error cases and corner cases should only be dis- 114 cussed where they help illustrate some important point. 116 4. Writing Protocol Models 118 Our experience indicates that it's easiest to grasp protocol models 119 when they're presented in visual form. We recommend a presentation 120 format that is centered around a few key diagrams with explanatory 121 text for each. These diagrams should be simple and typically consist 122 of "boxes and arrows"--boxes representing the major components, 123 arrows representing their relationships and labels indicating impor- 124 tant features. 126 We recommend a presentation structured in three parts to match the 127 three questions mentioned in the previous sections. Each part should 128 contain 1-3 diagrams intended to illustrate the relevant points. 130 4.1. Describe the problem you're trying to solve 132 First, figure out what you are trying to do (this is good 133 advice under most circumstances, and it is especially apropos here. 134 --NNTP Installation Guide 136 The absolutely most critical task that a protocol model must perform 137 is to explain what the protocol is trying to achieve. This provides 138 crucial context for understanding how the protocol works and whether 139 it meets its goals. Given the desired goals, in most cases an experi- 140 enced reviewer will have an idea of how they would approach the prob- 141 lem and be able to compare that to the approach taken by the protocol 142 under review. 144 The "Problem" section of the model should start out with a short 145 statement of the environments in which the protocol is expected to be 146 used. This section should describe the relevant entities and the 147 likely scenarios under which they participate in the protocol. The 148 Problem section should feature a diagram showing the major communi- 149 cating parties and their inter-relationships. It is particularly 150 important to lay out the trust relationships between the various par- 151 ties as these are often un-obvious. 153 4.1.1. Example: STUN (RFC 3489) 155 Network Address Translation (NAT) makes it difficult to run a number 156 of classes of service from behind the NAT gateway. This is a particu- 157 lar problem when protocols need to advertise address/port pairs as 158 part of the application layer protocol. Although the NAT can be con- 159 figured to accept data destined for that port, address translation 160 means that the address that the application knows about is not the 161 same as the one that it is reachable on. 163 Consider the scenario represented in the figure below. A SIP client 164 is initiating a session with a SIP server in which it wants the SIP 165 server to send it some media. In its Session Description Protocol 166 (SDP) [SDP] request it provides the IP and port on which it is lis- 167 tening. However, unbeknownst to the client, a NAT is in the way. It 168 translates the IP address in the header, but unless it is SIP aware, 169 it doesn't change the address in the request. The result is that the 170 media goes into a black hole. 172 +-----------+ 173 | SIP | 174 | Server | 175 | | 176 +-----------+ 177 ^ 178 | [FROM: 198.203.2.1:8954] 179 | [MSG: SEND MEDIA TO 10.0.10.5:6791] 180 | 181 | 182 +-----------+ 183 | | 184 | NAT | 185 --------------+ Gateway +---------------- 186 | | 187 +-----------+ 188 ^ 189 | [FROM: 10.0.10.5:6791] 190 | [MSG: SEND MEDIA TO 10.0.10.5:6791] 191 | 192 10.0.10.5 193 +-----------+ 194 | SIP | 195 | Client | 196 | | 197 +-----------+ 199 The purpose of STUN [STUN] is to allow clients to detect this situation 200 and determine the address mapping. They can then place the appropriate 201 address in their application-level messages. This is done by making use 202 of an external STUN server. That server is able to determine the trans- 203 lated address and tell the STUN client, as shown below. 205 +-----------+ 206 | STUN | 207 | Server | 208 | | 209 +-----------+ 210 ^ | 211 [IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954] 212 [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] 213 | v 214 +-----------+ 215 | | 216 | NAT | 217 --------------+ Gateway +---------------- 218 | | 219 +-----------+ 220 ^ | 221 [IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791] 222 [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] 223 | v 224 10.0.10.5 225 +-----------+ 226 | SIP | 227 | Client | 228 | | 229 +-----------+ 231 4.2. Describe the protocol in broad overview 233 Once you've described the problem, the next task is to describe the 234 protocol in broad overview. This means showing, either in "ladder 235 diagram" or "boxes and arrows" form, the protocol messages that flow 236 between the various networking agents. This diagram should be accom- 237 pied with explanatory text that describes the purpose of each message 238 and the MAJOR data elements. 240 This section SHOULD NOT contain detailed descriptions of the protocol 241 messages or of each data element. In particular, bit diagrams, ASN.1 242 modules and XML schema SHOULD NOT be shown. The purpose of this sec- 243 tion is explicitly not to provide a complete description of the pro- 244 tocol. Instead, it is to provide enough of a map so that a person 245 reading the full protocol document can see where each specific piece 246 fits. 248 4.3. State Machines 250 In certain cases, it may be helpful to provide a state machine 251 description of the behavior of network elements. However, such state 252 machines should be kept as minimal as possible. Remember that the 253 purpose is to promote high-level comprehension, not complete under- 254 standing. 256 4.4. Example: DCCP 258 Although DCCP [DCCP] is datagram oriented like UDP, it is stateful 259 like TCP. Connections go through the following phases: 260 1. Initiation 261 2. Feature negotiation 262 3. Data transfer 263 4. Termination 265 4.4.1. Initiation 267 As with TCP, the initiation phase of DCCP involves a three-way hand- 268 shake, shown in Figure 1. 269 Client Server 270 ------ ------ 271 DCCP-Request -> 272 [Ports, Service, 273 Features] 274 <- DCCP-Response 275 [Features, 276 Cookie] 277 DCCP-Ack -> 278 [Features, 279 Cookie] 281 FFiigguurree 11 DCCP 3-way handshake 283 In the DCCP-Request message, the client tells the server the name of 284 the service it wants to talk to and the ports it wants to communicate 285 on. Note that ports are not tightly bound to services the way they 286 are in TCP or UDP common practice. It also starts feature negotia- 287 tion. For pedagogical reasons, we will present feature negotiation 288 separately in the next section. However, realize that the early 289 phases of feature negotiation happen concurrently with initiation. 291 In the DCCP-Response message, the server tells the client that it is 292 willing to accept the connection and continues feature negotiation. 293 In order to prevent SYN-flood style DOS attacks, DCCP incorporates an 294 IKE-style cookie exchange. The server can provide the client with a 295 cookie that contains all the negotiation state. This cookie must be 296 echoed by the client in the DCCP-Ack, thus removing the need for the 297 server to keep state. 299 In the DCCP-Ack message, the client acknowledges the DCCP-Response 300 and returns the cookie to permit the server to compleye its side of 301 the connection. As indicated in Figure 1, this message may also 302 include feature negotiation messages. 304 4.4.2. Feature Negotiation 306 In DCCP, feature negotiation is performed by attaching options to 307 other DCCP packets. Thus feature negotiation can be piggybacked on 308 any other DCCP message. This allows feature negotiation during con- 309 nection initiation as well as feature renegotiation during data flow. 311 Somewhat unusually, DCCP features are one-sided. Thus, it's possible 312 to have a different congestion control regime for data sent from 313 client to server than from server to client. 315 Feature negotiation is done with three options: 317 1. Change 318 2. Prefer 319 3. Confirm 321 A Change message says to the peer "change this option setting on your 322 side". The peer can either respond with a Confirm, meaning "I've 323 changed it" or a Prefer, containing a list of other settings that the 324 peer would like. Multiple exchanges of Change and Prefer may occur as 325 the peers attempt so sort out what options they have in common. Some 326 sample exchanges (partly cribbed from the DCCP spec) follow: 328 Client Server 329 ------ ------ 330 Change(CC,2) -> 331 <- Confirm(CC,2) 333 In this exchange, the peers agree to set CC equal to 2. 335 Client Server 336 ------ ------ 337 Change(CC,3,4) -> 338 <- Prefer(CC,1,2,5) 339 Change(CC,5) -> 340 <- Confirm(CC,5) 342 In this exchange, the client requests CC values 3 and 4. Note that 343 the client can offer multiple values. The server doesn't like any of 344 these and offers 1, 2, and 5. The client chooses 5 and the server 345 agrees. 347 Since features are one-sided, if a party wants to change one of his 348 own options, he must ask the peer to issue a Change. This is done 349 using a Prefer, as shown below, where the client gets the server to 350 request that the client change the value of CC to 3. 352 Client Server 353 ------ ------ 354 Prefer(CC,3,4) -> 355 <- Change(CC,3) 356 Confirm(CC,3) -> 358 4.4.3. Data Transfer 360 Rather than have a single congestion control regime as in TCP, DCCP 361 offers a variety of negotiable congestion control regimes. The DCCP 362 documents describe two congestion control regimes: additive increase, 363 multiplicative decrease (CCID-2 [CCID2]) and TCP-friendly rate con- 364 trol (CCID-3 [CCID3]). CCID-2 is intended for applications which want 365 maximum throughput. CCID-3 is intended for real-time applications 366 which want smooth response to congestion. 368 4.4.3.1. CCID-2 370 CCID-2's congestion control is extremely similar to that of TCP. The 371 sender maintains a congestion window and sends packets until that 372 window is full. Packets are Acked by the receiver. Dropped packets 373 and ECN [ECN] are used to indicate congestion. The response to con- 374 gestion is to halve the congestion window. One subtle diference 375 between DCCP and TCP is that the Acks in DCCP must contain the 376 sequence numbers of all received packets (within a given window) not 377 just the highest sequence number as in TCP. 379 4.4.3.2. CCID-3 381 CCID-3 is an equation based form of rate control which is intended to 382 provide smoother response to congestion than CCID-2. The sender main- 383 tains a "transmit rate". The receiver sends ACK packets which also 384 contain information about the receiver's estimate of packet loss. The 385 sender uses this information to update its transmit rate. Although 386 CCID-3 behaves somewhat differently from TCP in its short term con- 387 gestion response, it is designed to operate fairly with TCP over the 388 long term. 390 4.4.4. Termination 392 Connection termination in DCCP is initiated by sending a Close mes- 393 sage. Either side can send a Close message. The peer then responds 394 with a Reset message, at which point the connection is closed. The 395 side that sent the Close message must quietly preserve the socket in 396 TIMEWAIT state for 2MSL. 398 Client Server 399 ------ ------ 400 Close -> 401 <- Reset 402 [Remains in TIMEWAIT] 404 Note that the server may wish to close the connection but not remain 405 in TIMEWAIT (e.g., due to a desire to minimize server-side state.) In 406 order to accomplish this, the server can elicit a Close from the 407 client by sending a CloseReq message and thus keeping the TIMEWAIT 408 state on the client. 410 5. Describe any important protocol features 412 The final section (if there is one) should contain an explanation of 413 any important protocol features which are not obvious from the previ- 414 ous sections. In the best case, all the important features of the 415 protocol would be obvious from the message flow. However, this isn't 416 always the case. This section is an opportunity for the author to 417 explicate those features. Authors should think carefully before writ- 418 ing this section. If there are no important points to be made they 419 should not populate this section. 421 Examples of the kind of feature that belongs in this section include: 422 high-level security considerations, congestion control information 423 and overviews of the algorithms that the network elements are 424 intended to follow. For instance, if you have a routing protocol you 425 might use this section to sketch out the algorithm that the router 426 uses to determine the appropriate routes from protocol messages. 428 5.1. Example: WebDAV COPY and MOVE 430 WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While 431 a MOVE can be thought of as a COPY followed by DELETE, COPY+DELETE 432 and MOVE aren't entirely equivalent. 434 The use of COPY+DELETE as a MOVE substitute is problematic because of 435 the creation of the intermediate file. Consider the case where the 436 user is approaching some quota boundary. A COPY+DELETE should be for- 437 bidden because it would temporarily exceed the quota. However, a 438 simple rename should work in this situation. 440 The second issue is permissions. The WebDAV permissions model allows 441 the server to grant users permission to rename files but not to cre- 442 ate new ones--this is unusual in ordinary filesystems but nothing 443 prevents it in WebDAV. This is clearly not possible if a client uses 444 COPY+DELETE to do a MOVE. 446 Finally, a COPY+DELETE does not produce the same logical result as 447 would be expected with a MOVE. Because COPY creates a new resource, 448 it is permitted (but not required) to use the time of new file cre- 449 ation as the creation date property. By contrast, the expectation for 450 move is that the renamed file will have the same properties as the 451 original. 453 6. Formatting Issues 455 The requirement that Internet-Drafts and RFCs be renderable in ASCII 456 is a significant obstacle when writing the sort of graphics-heavy 457 document being described here. Authors may find it more convenient to 458 do a separate protocol model document in Postscript or PDF and simply 459 make it available at review time--though an archival version would 460 certainly be handy. 462 7. A Complete Example: Internet Key Exchange (IKE) 464 7.1. Operating Environment 466 Internet key Exchange (IKE) [IKE] is a key establishment and parame- 467 ter negotiation protocol for Internet protocols. Its primary applica- 468 tion is for establishing security associations (SAs) [IPSEC] for 469 IPsec AH [AH] and ESP [ESP]. 471 +--------------------+ +--------------------+ 472 | | | | 473 | +------------+ | | +------------+ | 474 | | Key | | IKE | | Key | | 475 | | Management | <-+-----------------------+-> | Management | | 476 | | Process | | | | Process | | 477 | +------------+ | | +------------+ | 478 | ^ | | ^ | 479 | | | | | | 480 | v | | v | 481 | +------------+ | | +------------+ | 482 | | IPsec | | AH/ESP | | IPsec | | 483 | | Stack | <-+-----------------------+-> | Stack | | 484 | | | | | | | | 485 | +------------+ | | +------------+ | 486 | | | | 487 | | | | 488 | Initiator | | Responder | 489 +--------------------+ +--------------------+ 491 The general deployment model for IKE is shown in Figure 2. The IPsec 492 engines and IKE engines typically are separate modules. When a packet 493 needs to be processed (either sent or received) for which no security 494 association exists, the IPsec engine contacts the IKE engine and asks 495 it to establish an appropriate SA. The IKE engine contacts the appro- 496 priate peer and uses IKE to establish the SA. Once the IKE handshake 497 is finished it registers the SA with the IPsec engine. 499 In addition, IKE traffic between the peers can be used to refresh 500 keying material or adjust operating parameters such as algorithms. 502 7.1.1. Initiator and Responder 504 Although IPsec is basically symmetrical, IKE is not. The party who 505 sends the first message is called the INITIATOR. The other party is 506 called the RESPONDER. In the case of TCP connections the INITIATOR 507 will typically be the peer doing the active open (i.e. the client). 509 7.1.2. Perfect Forward Secrecy 511 One of the major concerns in IKE design was that traffic be protected 512 even if they keying material of the nodes was later compromised, pro- 513 vided that the session in question had terminated and so the session- 514 specific keying material was gone. This property is often called PER- 515 FECT FORWARD SECRECY (PFS) or BACK TRAFFIC PROTECTION. 517 7.1.3. Denial of Service Resistance 519 Since IKE allows arbitrary peers to initiate computationally expen- 520 sive cryptographic operations, it potentially allows resource con- 521 sumption denial of service attacks to be mounted against the IKE 522 engine. IKE includes countermeasures designed to minimize this risk. 524 7.1.4. Keying Assumptions 526 Because Security Associations are essentially symmetric, both sides 527 must in general be authenticated. Because IKE needs to be able to 528 establish SAs between a broad range of peers with various kinds of 529 prior relationships, IKE supports a very flexible keying model. Peers 530 can authenticate via shared keys, digital signatures (typically from 531 keys vouched for by certificates), or encryption keys. 533 7.1.5. Identity Protection 535 Although IKE requires the peers to authenticate to each other, it was 536 considered desirable by the working group to provide some identity 537 protection for the communicating peers. In particular, the peers 538 should be able to hide their identity from passive observers and one 539 peer should be able to require the author to authenticate before they 540 self-identity. In this case, the designers chose to make the party 541 who speaks first (the INITIATOR) identify first. 543 7.2. Protocol Overview 545 At a very high level, there are two kinds of IKE handshake: 546 (1) Those which establish an IKE security association. 547 (2) Those which establish an AH or ESP security association. 549 When two peers which have never communicated before need to establish 550 an AH/ESH SA, they must first establish an IKE SA. This allows them 551 to exchange an arbitrary amount of protected IKE traffic. They can 552 then use that SA to do a second handshake to establish SAs for AH and 553 ESP. This process is shown in schematic form below. The notation 554 E(SA,XXXX) is used to indicate that traffic is encrypted under a 555 given SA. 557 Initiator Responder 558 --------- --------- 560 Handshake MSG -> \ 561 <- Handshake MSG \ Establish IKE 562 / SA (IKEsa) 563 [...] / 565 E(IKEsa, Handshake MSG) -> \ Establish AH/ESP 566 <- E(IKEsa, Handshake MSG) / SA 568 IKE terminology is somewhat confusing, referring under different cir- 569 cumstances to "phases" and "modes". For maximal clarity we will refer 570 to the the Establishment of the IKE SA as "Stage 1" and the Estab- 571 lishment of AH/ESP SAs as "Stage 2". Note that it's quite possible 572 for there to be more than one Stage 2 handshake, once Stage 1 has 573 been finished. This might be useful if you wanted to establish multi- 574 ple AH/ESP SAs with different cryptographic properties. 576 The Stage 1 and Stage 2 handshakes are actually rather different, 577 because the Stage 2 handshake can of course assume that its traffic 578 is being protected with an IKE SA. Accordingly, we will first discuss 579 Stage 1 and then Stage 2. 581 7.2.1. Stage 1 583 There are a large number of variants of the IKE Stage 1 handshake, 584 necessitated by use of different authentication mechanisms. However, 585 broadly speaking they fall into one of two basic categories: MAIN 586 MODE, which provides identity protection and DoS resistance, and 587 AGGRESSIVE MODE, which does not. We will cover MAIN MODE first. 589 7.2.1.1. Main Mode 591 Main Mode is a six message (3 round trip) handshake which offers 592 identity protection and DoS resistance. An overview of the handshake 593 is below. 595 Initiator Responder 596 --------- --------- 597 CookieI, Algorithms -> \ Parameter 598 <- CookieR, Algorithms / Establishment 600 CookieR, 601 Nonce, Key Exchange -> 602 <- Nonce, Key Exchange\ Establish 603 / Shared key 605 E(IKEsa, Auth Data) -> 606 <- E(IKEsa, Auth data)\ Authenticate 607 / Peers 609 In the first round trip, the Initiator offers a set of algorithms and 610 parameters. The Responder picks out the single set that it likes and 611 responds with that set. It also provides CookieR, which will be used 612 to prevent DoS attacks. At this point, there is no secure association 613 but the peers have tentatively agreed upon parameters. These parame- 614 ters include a Diffie-Hellman group, which will be used in the second 615 round trip. 617 In the second round trip, the Initiator sends the key exchange infor- 618 mation. This generally consists of the Initiator's Diffie-Hellman 619 public share (Yi). He also supplies CookieR, which was provided by 620 the responder. The Responder replies with his own DH share (Yr). At 621 this point, both Initiator and Responder can compute the shared DH 622 key (ZZ). However, there has been no authentication and so they don't 623 know with any certainty that the connection hasn't been attacked. 624 Note that as long as the peers generate fresh DH shares for each 625 handshake than PFS will be provided. 627 Before we move on, let's take a look at the cookie exchange. The 628 basic anti-DoS measure used by IKE is to force the peer to demon- 629 strate that they can receive traffic from you. This foils blind 630 attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier 631 to track down attackers. The cookie exchange serves this role in IKE. 632 The Responder can verify that the Initiator supplied a valid CookieR 633 before doing the expensive DH key agreement. This does not totally 634 eliminate DoS attacks, since an attacker who was willing to reveal 635 his location could still consume server resources, but it does pro- 636 tect against a certain class of blind attack. 638 In the final round trip, the peers establish their identities. Since 639 they share an (unauthenticated) key, they can send their identities 640 encrypted, thus providing identity protection from eavesdroppers. The 641 exact method of proving identity depends on what form of credential 642 is being used (signing key, encryption key, shared secret, etc.), but 643 in general you can think of it as a signature over some subset of the 644 handshake messages. So, each side would supply its certificate and 645 then sign using the key associated with that certificate. If shared 646 keys are used, the authentication data would be a key id and a MAC. 647 Authentication using public key encryption follows similar principles 648 but is more complicated. Refer to the IKE document for more details. 650 At the end of the Main Mode handshake, the peers share: 651 (1) A set of algorithms for encryption of further IKE traffic. 652 (2) Traffic encryption and authentication keys. 653 (3) Mutual knowledge of the peer's identity. 655 7.2.1.2. Aggressive Mode 657 Although IKE Main Mode provides the required services, there was con- 658 cern that the large number of round trips required added excessive 659 latency. Accordingly, an Aggressive Mode was defined. Aggressive mode 660 packs more data into fewer messages and thus reduces latency. How- 661 ever, it does not provide protection against DoS or identity protec- 662 tion. 663 Initiator Responder 664 --------- --------- 665 Algorithms, Nonce, 666 Key Exchange, -> 667 <- Algorithms, Nonce, 668 Key Exchange, Auth Data 669 Auth Data -> 671 After the first round trip, the peers have all the required proper- 672 ties except that the Initiator has not authenticated to the Respon- 673 der. The third message closes the loop by authenticating the Initia- 674 tor. Note that since the authentication data is sent in the clear, no 675 identity protection is provided and since the Responder does the DH 676 key agreement without a round trip to the Initiator, there is no DoS 677 protection 679 7.2.2. Stage 2 681 Stage 1 on its own isn't very useful. The purpose of IKE, after all, 682 is to establish associations to be used to protect other traffic, not 683 just to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is 684 used for this purpose. The basic Stage 2 handshake is shown below. 686 Initiator Responder 687 --------- --------- 688 AH/ESP parameters, 689 Algorithms, Nonce, 690 Handshake Hash -> 692 <- AH/ESP parameters, 693 Algorithms, Nonce, 694 Handshake Hash 695 Handshake Hash -> 697 As with quick mode, the first two messages establish the algorithms 698 and parameters while the final message is a check over the previous 699 messages. In this case, the parameters also include the transforms to 700 be applied to the traffic (AH or ESP) and the kinds of traffic which 701 are to be protected. Note that there is no key exchange information 702 shown in these messages. 704 In this version of Quick Mode, the peers use the pre-existing Stage 1 705 keying material to derive fresh keying material for traffic protec- 706 tion (with the nonces to ensure freshness). Quick mode also allows 707 for a new Diffie-Hellman handshake for per-traffic key PFS. In that 708 case, the first two messages shown above would also include Key 709 Exchange payloads, as shown below. 711 Initiator Responder 712 --------- --------- 713 AH/ESP parameters, 714 Algorithms, Nonce, 715 Key Exchange, -> 716 Handshake Hash 718 <- AH/ESP parameters, 719 Algorithms, Nonce, 720 Key Exchange, 721 Handshake Hash 722 Handshake Hash -> 724 7.3. Other Considerations 726 There are a number of features of IKE that deserve special considera- 727 tion. These are discussed here. 729 7.3.1. Cookie Generation 731 As mentioned previously, IKE uses cookies as a partial defense 732 against DoS attacks. When the responder receives Main Mode message 3 733 containing the Key Exchange data and the cookie, it verifies that the 734 cookie is correct. However, this verification must not involve having 735 a list of valid cookies. Otherwise, an attacker could potentially 736 consume arbitrary amounts of memory by repeatedly requesting cookies 737 from a responder. The recommended way to generate a cookie, suggested 738 by Phil Karn, is by having a single master key and compute a hash of 739 the secret and the initiator's address information. This cookie can 740 be verified by recomputing the cookie value based on information in 741 the third message and seeing if it matches. 743 7.3.2. Endpoint Identities 745 So far we have been rather vague about what sorts of endpoint identi- 746 ties are used. In principle, there are three ways a peer might be 747 identified: by a shared key, a pre-configured public key, and a 748 certificate. 750 7.3.2.1. Shared Key 752 In a shared key scheme, the peers share some symmetric key. This key 753 is associated with a key identifier which is known to both parties. 754 It is assumed that the party verifying that identity also has some 755 sort of table that indicates what sorts of traffic (e.g. what 756 addresses) that identity is allowed to negotiate SAs for. 758 7.3.2.2. Pre-configured public key 760 A pre-configured public key scheme is the same as a shared key scheme 761 except that the verifying party has the authenticating party's public 762 key instead of a shared key. 764 7.3.2.3. Certificate 766 In a certificate scheme, authenticating party presents a certificate 767 containing their public key. It's straightforward to establish that 768 that certificate matches the authentication data provided by the 769 peer. What's less straightforward is to determine whether a given 770 peer is entitled to negotiate for a given class of traffic. In the- 771 ory, one might be able to determine this from the name in the 772 certificate (e.g. the subject name contains an IP address that 773 matches the ostensible IP address). In practice, this is not clearly 774 specified in IKE and therefore not really interoperable. The more 775 likely case at the moment is that there is a configuration table map- 776 ping certificates to policies, as with the other two authentication 777 schemes. 779 References 780 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 781 RFC 2402, November 1998. 783 [CCID2] Floyd, S., Kohler, E., "Profile for DCCP Congestion Control ID 2: 784 TCP-like Congestion Control", draft-ietf-dccp-ccid2-04.txt, 785 October 2003. 787 [CCID3] Floyd, S., Kohler, E., Padhye, J. "Profile for DCCP Congestion 788 Control ID 3: TFRC Congestion Control", 789 draft-ietf-dccp-ccid3-05.txt, February 2004. 791 [DCCP] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion 792 Control Protocol (DCCP)", draft-ietf-dccp-spec-06.txt, 793 February 2004. 795 [ECN] Ramakrishnan, K. Floyd, S., Black D., "The Addition of 796 Explicit Congestion Notification (ECN) to IP", 797 RFC 3168, September 2001. 799 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 800 Payload (ESP)", RFC 2406, November 1998. 802 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 803 RFC 2409, November 1998. 805 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet 806 Protocol", RFC 2401, November 1998. 808 [KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication 809 Service (V5)", RFC 1510, September 1993. 811 [SDP] Handley, M., Jacobson, V., "SDP: Session Description Protocol" 812 RFC 2327, April 1998. 814 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R., 815 "STUN - Simple Traversal of User Datagram Protocol (UDP)", 816 RFC 3489, March 2003. 818 [WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D. 819 "HTTP Extensions for Distributed Authoring -- WEBDAV", 820 RFC 2518, February 1999. 822 Security Considerations 824 This document does not define any protocols and therefore has no 825 security considerations. 827 Author's Address 828 Eric Rescorla 829 RTFM, Inc. 831 2064 Edgewood Drive 832 Palo Alto, CA 94303 833 Phone: (650)-320-8549 835 Internet Architecture Board 836 IAB 838 Appendix A. IAB Members at the time of this writing 840 Bernard Aboba 841 Harald Alvestrand 842 Rob Austein 843 Leslie Daigle 844 Patrik Falstrom 845 Sally Floyd 846 Jun-ichiro Itojun Hagino 847 Mark Handley 848 Bob Hinden 849 Geoff Huston 850 Eric Rescorla 851 Pete Resnick 852 Jonathon Rosenberg