idnits 2.17.1 draft-iab-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 924. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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.) ** There are 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** 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 293: '... This section SHOULD NOT contain det...' RFC 2119 keyword, line 295: '...s and XML schema SHOULD NOT be shown. ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 691, but not defined -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-10) exists of draft-ietf-dccp-ccid2-04 == Outdated reference: A later version (-11) exists of draft-ietf-dccp-ccid3-05 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-06 -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. 'KERBEROS') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2518 (ref. 'WEBDAV') (Obsoleted by RFC 4918) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 16 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-02.txt September 2004 (Expires March 2005) 6 Writing Protocol Models 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than a "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright Notice 32 Copyright (C) The Internet Society (1999-2004). All Rights Reserved. 34 Abstract 36 The IETF process depends on peer review. However, IETF documents 37 are generally written to be useful for implementors, not for 38 reviewers. In particular, while great care is generally taken to 39 provide a complete description of the state machines and bits on 40 the wire, this level of detail tends to get in the way of initial 41 understanding. This document describes an approach for providing 42 protocol "models" that allow reviewers to quickly grasp the essence 43 of a system. 45 Contents 47 1 Introduction 2 48 2 The Purpose of a Protocol Model 3 49 3 Basic Principles 3 50 3.1 Less is more 4 51 3.2 Abstraction is good 4 52 3.3 A few well-chosen details sometimes helps 4 53 4 Writing Protocol Models 4 54 4.1 Describe the problem you're trying to solve 4 55 4.1.1 Example: STUN (RFC 3489) 5 56 4.2 Describe the protocol in broad overview 7 57 4.3 State Machines 8 58 4.4 Example: DCCP 8 59 4.4.1 Initiation 8 60 4.4.2 Feature Negotiation 9 61 4.4.3 Data Transfer 10 62 4.4.3.1 CCID-2 10 63 4.4.3.2 CCID-3 10 64 4.4.4 Termination 10 65 5 Describe any important protocol features 11 66 5.1 Example: WebDAV COPY and MOVE 11 67 6 Formatting Issues 12 68 7 A Complete Example: Internet Key Exchange (IKE) 12 69 7.1 Operating Environment 12 70 7.1.1 Initiator and Responder 13 71 7.1.2 Perfect Forward Secrecy 13 72 7.1.3 Denial of Service Resistance 14 73 7.1.4 Keying Assumptions 14 74 7.1.5 Identity Protection 14 75 7.2 Protocol Overview 14 76 7.2.1 Stage 1 15 77 7.2.1.1 Main Mode 15 78 7.2.1.2 Aggressive Mode 17 79 7.2.2 Stage 2 18 80 7.3 Other Considerations 19 81 7.3.1 Cookie Generation 19 82 7.3.2 Endpoint Identities 19 83 7.3.2.1 Shared Key 19 84 7.3.2.2 Pre-configured public key 20 85 7.3.2.3 Certificate 20 87 1. Introduction 89 The IETF process depends on peer review. However, in many cases, 90 the documents submitted for publication are extremely difficult to 91 review. Since reviewers have only limited amounts of time, this 92 leads to extremely long review times, inadequate reviews, or both. 93 In my view, a large part of the problem is that most documents fail 94 to present an architectural model for how the protocol operates, 95 opting instead to simply describe the protocol and let the reviewer 96 figure it out. 98 This is acceptable when documenting a protocol for implementors, 99 because they need to understand the protocol in any case, but 100 dramatically increases the strain on reviewers. Reviewers 101 necessarily need to get the big picture of the system and then 102 focus on particular points. They simply do not have time to give 103 the entire document the attention an implementor would. 105 One way to reduce this load is to present the reviewer with a 106 MODEL--a short description of the system in overview form. This 107 provides the reviewer with the context to identify the important or 108 difficult pieces of the system and focus on them for review. As a 109 side benefit, if the model is done first, it can be serve as an aid 110 to the detailed protocol design and a focus for early review prior 111 to protocol completion. The intention is that the model would 112 either be the first section of the protocol document or be a 113 separate document provided with the protocol. 115 2. The Purpose of a Protocol Model 117 A protocol model needs to answer three basic questions: 119 1. What problem is the protocol trying to achieve? 120 2. What messages are being transmitted and what do they 121 mean? 122 3. What are the important but un-obvious features of the 123 protocol? 125 The basic idea is to provide enough information that the reader 126 could design a protocol which was roughly isomorphic to the 127 protocol being described. This doesn't, of course, mean that the 128 protocol would be identical, but merely that it would share most 129 important features. For instance, the decision to use a KDC-based 130 authentication model is an essential feature of Kerberos 131 [KERBEROS]. By constrast, the use of ASN.1 is a simple 132 implementation decision. S-expressions--or XML, had it existed at 133 the time--would have served equally well. 135 3. Basic Principles 137 In this section we discuss basic principles that should guide your 138 presentation. 140 3.1. Less is more 142 Humans are only capable of keeping a very small number of pieces of 143 information in their head at once. Since we're interested in 144 ensuring that people get the big picture, we therefore have to 145 dispense with a lot of detail. That's good, not bad. The simpler 146 you can make things the better. 148 3.2. Abstraction is good 150 A key technique for representing complex systems is to try to 151 abstract away pieces. For instance, maps are better than 152 photographs for finding out where you want to go because they 153 provide an abstract, stylized, view of the information you're 154 interested in. Don't be afraid to compress multiple protocol 155 elements into a single abstract piece for pedagogical purposes. 157 3.3. A few well-chosen details sometimes helps 159 The converse of the previous principle is that sometimes details 160 help to bring a description into focus. Many people work better 161 when given examples. Thus, it's often a good approach to talk about 162 the material in the abstract and then provide a concrete 163 description of one specific piece to bring it into focus. Authors 164 should focus on the normal path. Error cases and corner cases 165 should only be discussed where they help illustrate some important 166 point. 168 4. Writing Protocol Models 170 Our experience indicates that it's easiest to grasp protocol models 171 when they're presented in visual form. We recommend a presentation 172 format that is centered around a few key diagrams with explanatory 173 text for each. These diagrams should be simple and typically 174 consist of "boxes and arrows"--boxes representing the major 175 components, arrows representing their relationships and labels 176 indicating important features. 178 We recommend a presentation structured in three parts to match the 179 three questions mentioned in the previous sections. Each part 180 should contain 1-3 diagrams intended to illustrate the relevant 181 points. 183 4.1. Describe the problem you're trying to solve 184 First, figure out what you are trying to do (this is good 185 advice under most circumstances, and it is especially apropos here. 186 --NNTP Installation Guide 188 The absolutely most critical task that a protocol model must 189 perform is to explain what the protocol is trying to achieve. This 190 provides crucial context for understanding how the protocol works 191 and whether it meets its goals. Given the desired goals, in most 192 cases an experienced reviewer will have an idea of how they would 193 approach the problem and be able to compare that to the approach 194 taken by the protocol under review. 196 The "Problem" section of the model should start out with a short 197 statement of the environments in which the protocol is expected to 198 be used. This section should describe the relevant entities and the 199 likely scenarios under which they participate in the protocol. The 200 Problem section should feature a diagram showing the major 201 communicating parties and their inter-relationships. It is 202 particularly important to lay out the trust relationships between 203 the various parties as these are often un-obvious. 205 4.1.1. Example: STUN (RFC 3489) 207 Network Address Translation (NAT) makes it difficult to run a 208 number of classes of service from behind the NAT gateway. This is a 209 particular problem when protocols need to advertise address/port 210 pairs as part of the application layer protocol. Although the NAT 211 can be configured to accept data destined for that port, address 212 translation means that the address that the application knows about 213 is not the same as the one that it is reachable on. 215 Consider the scenario represented in the figure below. A SIP client 216 is initiating a session with a SIP server in which it wants the SIP 217 server to send it some media. In its Session Description Protocol 218 (SDP) [SDP] request it provides the IP address and port on which it 219 is listening. However, unbeknownst to the client, a NAT is in the 220 way. It translates the IP address in the header, but unless it is 221 SIP aware, it doesn't change the address in the request. The result 222 is that the media goes into a black hole. 224 +-----------+ 225 | SIP | 226 | Server | 227 | | 228 +-----------+ 229 ^ 230 | [FROM: 192.0.2.1:8954] 231 | [MSG: SEND MEDIA TO 10.0.10.5:6791] 232 | 233 | 234 +-----------+ 235 | | 236 | NAT | 237 --------------+ Gateway +---------------- 238 | | 239 +-----------+ 240 ^ 241 | [FROM: 10.0.10.5:6791] 242 | [MSG: SEND MEDIA TO 10.0.10.5:6791] 243 | 244 10.0.10.5 245 +-----------+ 246 | SIP | 247 | Client | 248 | | 249 +-----------+ 251 The purpose of STUN [STUN] is to allow clients to detect this 252 situation and determine the address mapping. They can then place the 253 appropriate address in their application-level messages. This is done 254 by making use of an external STUN server. That server is able to 255 determine the translated address and tell the STUN client, as shown 256 below. 258 +-----------+ 259 | STUN | 260 | Server | 261 | | 262 +-----------+ 263 ^ | 264 [IP HDR FROM: 192.0.2.1:8954] | | [IP HDR TO: 192.0.2.1:8954] 265 [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 192.0.2.1:8954] 266 | v 267 +-----------+ 268 | | 269 | NAT | 270 --------------+ Gateway +---------------- 271 | | 272 +-----------+ 273 ^ | 274 [IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791] 275 [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 192.0.2.1:8954] 276 | v 277 10.0.10.5 278 +-----------+ 279 | SIP | 280 | Client | 281 | | 282 +-----------+ 284 4.2. Describe the protocol in broad overview 286 Once you've described the problem, the next task is to describe the 287 protocol in broad overview. This means showing, either in "ladder 288 diagram" or "boxes and arrows" form, the protocol messages that 289 flow between the various networking agents. This diagram should be 290 accompanied with explanatory text that describes the purpose of 291 each message and the MAJOR data elements. 293 This section SHOULD NOT contain detailed descriptions of the 294 protocol messages or of each data element. In particular, bit 295 diagrams, ASN.1 modules and XML schema SHOULD NOT be shown. The 296 purpose of this section is explicitly not to provide a complete 297 description of the protocol. Instead, it is to provide enough of a 298 map so that a person reading the full protocol document can see 299 where each specific piece fits. 301 4.3. State Machines 303 In certain cases, it may be helpful to provide a state machine 304 description of the behavior of network elements. However, such 305 state machines should be kept as minimal as possible. Remember that 306 the purpose is to promote high-level comprehension, not complete 307 understanding. 309 4.4. Example: DCCP 311 Although DCCP [DCCP] is datagram oriented like UDP, it is stateful 312 like TCP. Connections go through the following phases: 313 1. Initiation 314 2. Feature negotiation 315 3. Data transfer 316 4. Termination 318 4.4.1. Initiation 320 As with TCP, the initiation phase of DCCP involves a three-way 321 handshake, shown below. 322 Client Server 323 ------ ------ 324 DCCP-Request -> 325 [Ports, Service, 326 Features] 327 <- DCCP-Response 328 [Features, 329 Cookie] 330 DCCP-Ack -> 331 [Features, 332 Cookie] 334 DCCP 3-way handshake 336 In the DCCP-Request message, the client tells the server the name 337 of the service it wants to talk to and the ports it wants to 338 communicate on. Note that ports are not tightly bound to services 339 the way they are in TCP or UDP common practice. It also starts 340 feature negotiation. For pedagogical reasons, we will present 341 feature negotiation separately in the next section. However, 342 realize that the early phases of feature negotiation happen 343 concurrently with initiation. 345 In the DCCP-Response message, the server tells the client that it 346 is willing to accept the connection and continues feature 347 negotiation. In order to prevent SYN-flood style DOS attacks, DCCP 348 incorporates an IKE-style cookie exchange. The server can provide 349 the client with a cookie that contains all the negotiation state. 350 This cookie must be echoed by the client in the DCCP-Ack, thus 351 removing the need for the server to keep state. 353 In the DCCP-Ack message, the client acknowledges the DCCP-Response 354 and returns the cookie to permit the server to complete its side of 355 the connection. As indicated above this message may also include 356 feature negotiation messages. 358 4.4.2. Feature Negotiation 360 In DCCP, feature negotiation is performed by attaching options to 361 other DCCP packets. Thus feature negotiation can be piggybacked on 362 any other DCCP message. This allows feature negotiation during 363 connection initiation as well as feature renegotiation during data 364 flow. 366 Somewhat unusually, DCCP features are one-sided. Thus, it's 367 possible to have a different congestion control regime for data 368 sent from client to server than from server to client. 370 Feature negotiation is done with the Change and Confirm options. 371 There are four feature negotiation options in all: Change L, 372 Confirm L, Change R, and Confirm R. The "L" options are sent by the 373 feature location, where the feature is maintained, and the "R" 374 options are sent by the feature remote. 376 A Change R message says to the peer "change this option setting on 377 your side". The peer can respond with a Confirm L, meaning "I've 378 changed it". Some features allow Change R options to contain 379 multiple values, sorted in preference order. For example: 381 Client Server 382 ------ ------ 383 Change R(CCID, 2) --> 384 <-- Confirm L(CCID, 2) 385 * agreement that CCID/Server = 2 * 387 Change R(CCID, 3 4) --> 388 <-- Confirm L(CCID, 4, 4 2) 389 * agreement that CCID/Server = 4 * 390 <- Confirm(CC,2) 392 In the second exchange, the client requests that the server use 393 either CCID 3 or CCID 4, with 3 preferred. The server chooses 4 and 394 supplies its preference list, "4 2". 396 The Change L and Confirm R options are used for feature 397 negotiations initiated by the feature location. In the following 398 example, the server requests that CCID/Server be set to 3 or 2, 399 with 3 preferred, and the client agrees. 401 Client Server 402 ------ ------ 403 <-- Change L(CCID, 3 2) 404 Confirm R(CCID, 3, 3 2) --> 405 * agreement that CCID/Server = 3 * 407 4.4.3. Data Transfer 409 Rather than have a single congestion control regime as in TCP, DCCP 410 offers a variety of negotiable congestion control regimes. The DCCP 411 documents describe two congestion control regimes: additive 412 increase, multiplicative decrease (CCID-2 [CCID2]) and TCP-friendly 413 rate control (CCID-3 [CCID3]). CCID-2 is intended for applications 414 which want maximum throughput. CCID-3 is intended for real-time 415 applications which want smooth response to congestion. 417 4.4.3.1. CCID-2 419 CCID-2's congestion control is extremely similar to that of TCP. 420 The sender maintains a congestion window and sends packets until 421 that window is full. Packets are Acked by the receiver. Dropped 422 packets and ECN [ECN] are used to indicate congestion. The response 423 to congestion is to halve the congestion window. One subtle 424 diference between DCCP and TCP is that the Acks in DCCP must 425 contain the sequence numbers of all received packets (within a 426 given window) not just the highest sequence number as in TCP. 428 4.4.3.2. CCID-3 430 CCID-3 is an equation-based form of rate control which is intended 431 to provide smoother response to congestion than CCID-2. The sender 432 maintains a "transmit rate". The receiver sends ACK packets which 433 also contain information about the receiver's estimate of packet 434 loss. The sender uses this information to update its transmit rate. 435 Although CCID-3 behaves somewhat differently from TCP in its short- 436 term congestion response, it is designed to operate fairly with TCP 437 over the long term. 439 4.4.4. Termination 441 Connection termination in DCCP is initiated by sending a Close 442 message. Either side can send a Close message. The peer then 443 responds with a Reset message, at which point the connection is 444 closed. The side that sent the Close message must quietly preserve 445 the socket in TIMEWAIT state for 2MSL. 447 Client Server 448 ------ ------ 449 Close -> 450 <- Reset 451 [Remains in TIMEWAIT] 453 Note that the server may wish to close the connection but not 454 remain in TIMEWAIT (e.g., due to a desire to minimize server-side 455 state.) In order to accomplish this, the server can elicit a Close 456 from the client by sending a CloseReq message and thus keeping the 457 TIMEWAIT state on the client. 459 5. Describe any important protocol features 461 The final section (if there is one) should contain an explanation 462 of any important protocol features which are not obvious from the 463 previous sections. In the best case, all the important features of 464 the protocol would be obvious from the message flow. However, this 465 isn't always the case. This section is an opportunity for the 466 author to explain those features. Authors should think carefully 467 before writing this section. If there are no important points to be 468 made they should not populate this section. 470 Examples of the kind of feature that belongs in this section 471 include: high-level security considerations, congestion control 472 information and overviews of the algorithms that the network 473 elements are intended to follow. For instance, if you have a 474 routing protocol you might use this section to sketch out the 475 algorithm that the router uses to determine the appropriate routes 476 from protocol messages. 478 5.1. Example: WebDAV COPY and MOVE 480 WebDAV [WEBDAV] includes both a COPY method and a MOVE method. 481 While a MOVE can be thought of as a COPY followed by DELETE, 482 COPY+DELETE and MOVE aren't entirely equivalent. 484 The use of COPY+DELETE as a MOVE substitute is problematic because 485 of the creation of the intermediate file. Consider the case where 486 the user is approaching some quota boundary. A COPY+DELETE should 487 be forbidden because it would temporarily exceed the quota. 488 However, a simple rename should work in this situation. 490 The second issue is permissions. The WebDAV permissions model 491 allows the server to grant users permission to rename files but not 492 to create new ones--this is unusual in ordinary filesystems but 493 nothing prevents it in WebDAV. This is clearly not possible if a 494 client uses COPY+DELETE to do a MOVE. 496 Finally, a COPY+DELETE does not produce the same logical result as 497 would be expected with a MOVE. Because COPY creates a new resource, 498 it is permitted (but not required) to use the time of new file 499 creation as the creation date property. By contrast, the 500 expectation for move is that the renamed file will have the same 501 properties as the original. 503 6. Formatting Issues 505 The requirement that Internet-Drafts and RFCs be renderable in 506 ASCII is a significant obstacle when writing the sort of graphics- 507 heavy document being described here. Authors may find it more 508 convenient to do a separate protocol model document in Postscript 509 or PDF and simply make it available at review time--though an 510 archival version would certainly be handy. 512 7. A Complete Example: Internet Key Exchange (IKE) 514 7.1. Operating Environment 516 Internet key Exchange (IKE) [IKE] is a key establishment and 517 parameter negotiation protocol for Internet protocols. Its primary 518 application is for establishing security associations (SAs) [IPSEC] 519 for IPsec AH [AH] and ESP [ESP]. 521 +--------------------+ +--------------------+ 522 | | | | 523 | +------------+ | | +------------+ | 524 | | Key | | IKE | | Key | | 525 | | Management | <-+-----------------------+-> | Management | | 526 | | Process | | | | Process | | 527 | +------------+ | | +------------+ | 528 | ^ | | ^ | 529 | | | | | | 530 | v | | v | 531 | +------------+ | | +------------+ | 532 | | IPsec | | AH/ESP | | IPsec | | 533 | | Stack | <-+-----------------------+-> | Stack | | 534 | | | | | | | | 535 | +------------+ | | +------------+ | 536 | | | | 537 | | | | 538 | Initiator | | Responder | 539 +--------------------+ +--------------------+ 541 The general deployment model for IKE is shown in Figure 1. The 542 IPsec engines and IKE engines typically are separate modules. When 543 a packet needs to be processed (either sent or received) for which 544 no security association exists, the IPsec engine contacts the IKE 545 engine and asks it to establish an appropriate SA. The IKE engine 546 contacts the appropriate peer and uses IKE to establish the SA. 547 Once the IKE handshake is finished it registers the SA with the 548 IPsec engine. 550 In addition, IKE traffic between the peers can be used to refresh 551 keying material or adjust operating parameters such as algorithms. 553 7.1.1. Initiator and Responder 555 Although IPsec is basically symmetrical, IKE is not. The party who 556 sends the first message is called the INITIATOR. The other party is 557 called the RESPONDER. In the case of TCP connections the INITIATOR 558 will typically be the peer doing the active open (i.e. the client). 560 7.1.2. Perfect Forward Secrecy 562 One of the major concerns in IKE design was that traffic be 563 protected even if they keying material of the nodes was later 564 compromised, provided that the session in question had terminated 565 and so the session-specific keying material was gone. This property 566 is often called PERFECT FORWARD SECRECY (PFS) or BACK TRAFFIC 567 PROTECTION. 569 7.1.3. Denial of Service Resistance 571 Since IKE allows arbitrary peers to initiate computationally 572 expensive cryptographic operations, it potentially allows resource 573 consumption denial of service attacks to be mounted against the IKE 574 engine. IKE includes countermeasures designed to minimize this 575 risk. 577 7.1.4. Keying Assumptions 579 Because Security Associations are essentially symmetric, both sides 580 must in general be authenticated. Because IKE needs to be able to 581 establish SAs between a broad range of peers with various kinds of 582 prior relationships, IKE supports a very flexible keying model. 583 Peers can authenticate via shared keys, digital signatures 584 (typically from keys vouched for by certificates), or encryption 585 keys. 587 7.1.5. Identity Protection 589 Although IKE requires the peers to authenticate to each other, it 590 was considered desirable by the working group to provide some 591 identity protection for the communicating peers. In particular, the 592 peers should be able to hide their identity from passive observers 593 and one peer should be able to require the author to authenticate 594 before they self-identity. In this case, the designers chose to 595 make the party who speaks first (the INITIATOR) identify first. 597 7.2. Protocol Overview 599 At a very high level, there are two kinds of IKE handshake: 600 (1) Those which establish an IKE security association. 601 (2) Those which establish an AH or ESP security association. 603 When two peers which have never communicated before need to 604 establish an AH/ESH SA, they must first establish an IKE SA. This 605 allows them to exchange an arbitrary amount of protected IKE 606 traffic. They can then use that SA to do a second handshake to 607 establish SAs for AH and ESP. This process is shown in schematic 608 form below. The notation E(SA,XXXX) is used to indicate that 609 traffic is encrypted under a given SA. 611 Initiator Responder 612 --------- --------- 614 Handshake MSG -> \ Stage 1: 615 <- Handshake MSG \ Establish IKE 616 / SA (IKEsa) 617 [...] / 619 Stage 2: 620 E(IKEsa, Handshake MSG) -> \ Establish AH/ESP 621 <- E(IKEsa, Handshake MSG) / SA 623 The two kinds of IKE handshake 625 IKE terminology is somewhat confusing, referring under different 626 circumstances to "phases" and "modes". For maximal clarity we will 627 refer to the Establishment of the IKE SA as "Stage 1" and the 628 Establishment of AH/ESP SAs as "Stage 2". Note that it's quite 629 possible for there to be more than one Stage 2 handshake, once 630 Stage 1 has been finished. This might be useful if you wanted to 631 establish multiple AH/ESP SAs with different cryptographic 632 properties. 634 The Stage 1 and Stage 2 handshakes are actually rather different, 635 because the Stage 2 handshake can of course assume that its traffic 636 is being protected with an IKE SA. Accordingly, we will first 637 discuss Stage 1 and then Stage 2. 639 7.2.1. Stage 1 641 There are a large number of variants of the IKE Stage 1 handshake, 642 necessitated by use of different authentication mechanisms. 643 However, broadly speaking they fall into one of two basic 644 categories: MAIN MODE, which provides identity protection and DoS 645 resistance, and AGGRESSIVE MODE, which does not. We will cover MAIN 646 MODE first. 648 7.2.1.1. Main Mode 650 Main Mode is a six message (3 round trip) handshake which offers 651 identity protection and DoS resistance. An overview of the 652 handshake is below. 654 Initiator Responder 655 --------- --------- 656 CookieI, Algorithms -> \ Parameter 657 <- CookieR, Algorithms / Establishment 659 CookieR, 660 Nonce, Key Exchange -> 661 <- Nonce, Key Exchange\ Establish 662 / Shared key 664 E(IKEsa, Auth Data) -> 665 <- E(IKEsa, Auth data)\ Authenticate 666 / Peers 668 IKE Main Mode handshake (stage 1) 670 In the first round trip, the Initiator offers a set of algorithms 671 and parameters. The Responder picks out the single set that it 672 likes and responds with that set. It also provides CookieR, which 673 will be used to prevent DoS attacks. At this point, there is no 674 secure association but the peers have tentatively agreed upon 675 parameters. These parameters include a Diffie-Hellman group, which 676 will be used in the second round trip. 678 In the second round trip, the Initiator sends the key exchange 679 information. This generally consists of the Initiator's Diffie- 680 Hellman public share (Yi). He also supplies CookieR, which was 681 provided by the responder. The Responder replies with his own DH 682 share (Yr). At this point, both Initiator and Responder can compute 683 the shared DH key (ZZ). However, there has been no authentication 684 and so they don't know with any certainty that the connection 685 hasn't been attacked. Note that as long as the peers generate fresh 686 DH shares for each handshake than PFS will be provided. 688 Before we move on, let's take a look at the cookie exchange. The 689 basic anti-DoS measure used by IKE is to force the peer to 690 demonstrate that they can receive traffic from you. This foils 691 blind attacks like SYN floods [SYNFLOOD] and also makes it somewhat 692 easier to track down attackers. The cookie exchange serves this 693 role in IKE. The Responder can verify that the Initiator supplied a 694 valid CookieR before doing the expensive DH key agreement. This 695 does not totally eliminate DoS attacks, since an attacker who was 696 willing to reveal his location could still consume server 697 resources, but it does protect against a certain class of blind 698 attack. 700 In the final round trip, the peers establish their identities. 701 Since they share an (unauthenticated) key, they can send their 702 identities encrypted, thus providing identity protection from 703 eavesdroppers. The exact method of proving identity depends on what 704 form of credential is being used (signing key, encryption key, 705 shared secret, etc.), but in general you can think of it as a 706 signature over some subset of the handshake messages. So, each side 707 would supply its certificate and then sign using the key associated 708 with that certificate. If shared keys are used, the authentication 709 data would be a key id and a MAC. Authentication using public key 710 encryption follows similar principles but is more complicated. 711 Refer to the IKE document for more details. 713 At the end of the Main Mode handshake, the peers share: 714 (1) A set of algorithms for encryption of further IKE traffic. 715 (2) Traffic encryption and authentication keys. 716 (3) Mutual knowledge of the peer's identity. 718 7.2.1.2. Aggressive Mode 720 Although IKE Main Mode provides the required services, there was 721 concern that the large number of round trips required added 722 excessive latency. Accordingly, an Aggressive Mode was defined. 723 Aggressive mode packs more data into fewer messages and thus 724 reduces latency. However, it does not provide protection against 725 DoS or identity protection. 726 Initiator Responder 727 --------- --------- 728 Algorithms, Nonce, 729 Key Exchange, -> 730 <- Algorithms, Nonce, 731 Key Exchange, Auth Data 732 Auth Data -> 734 IKE Aggressive Mode handshake (stage 1) 736 After the first round trip, the peers have all the required 737 properties except that the Initiator has not authenticated to the 738 Responder. The third message closes the loop by authenticating the 739 Initiator. Note that since the authentication data is sent in the 740 clear, no identity protection is provided and since the Responder 741 does the DH key agreement without a round trip to the Initiator, 742 there is no DoS protection 743 7.2.2. Stage 2 745 Stage 1 on its own isn't very useful. The purpose of IKE, after 746 all, is to establish associations to be used to protect other 747 traffic, not just to establish IKE SAs. Stage 2 (what IKE calls 748 "Quick Mode") is used for this purpose. The basic Stage 2 handshake 749 is shown below. 751 Initiator Responder 752 --------- --------- 753 AH/ESP parameters, 754 Algorithms, Nonce, 755 Handshake Hash -> 757 <- AH/ESP parameters, 758 Algorithms, Nonce, 759 Handshake Hash 760 Handshake Hash -> 762 The basic IKE Quick Mode (stage 2) 764 As with quick mode, the first two messages establish the algorithms 765 and parameters while the final message is a check over the previous 766 messages. In this case, the parameters also include the transforms 767 to be applied to the traffic (AH or ESP) and the kinds of traffic 768 which are to be protected. Note that there is no key exchange 769 information shown in these messages. 771 In this version of Quick Mode, the peers use the pre-existing Stage 772 1 keying material to derive fresh keying material for traffic 773 protection (with the nonces to ensure freshness). Quick mode also 774 allows for a new Diffie-Hellman handshake for per-traffic key PFS. 775 In that case, the first two messages shown above would also include 776 Key Exchange payloads, as shown below. 778 Initiator Responder 779 --------- --------- 780 AH/ESP parameters, 781 Algorithms, Nonce, 782 Key Exchange, -> 783 Handshake Hash 785 <- AH/ESP parameters, 786 Algorithms, Nonce, 787 Key Exchange, 788 Handshake Hash 789 Handshake Hash -> 791 A variant of Quick Mode with PFS (stage 2) 793 7.3. Other Considerations 795 There are a number of features of IKE that deserve special 796 consideration. These are discussed here. 798 7.3.1. Cookie Generation 800 As mentioned previously, IKE uses cookies as a partial defense 801 against DoS attacks. When the responder receives Main Mode message 802 3 containing the Key Exchange data and the cookie, it verifies that 803 the cookie is correct. However, this verification must not involve 804 having a list of valid cookies. Otherwise, an attacker could 805 potentially consume arbitrary amounts of memory by repeatedly 806 requesting cookies from a responder. The recommended way to 807 generate a cookie, suggested by Phil Karn, is by having a single 808 master key and compute a hash of the secret and the initiator's 809 address information. This cookie can be verified by recomputing the 810 cookie value based on information in the third message and seeing 811 if it matches. 813 7.3.2. Endpoint Identities 815 So far we have been rather vague about what sorts of endpoint 816 identities are used. In principle, there are three ways a peer 817 might be identified: by a shared key, a pre-configured public key, 818 and a certificate. 820 7.3.2.1. Shared Key 822 In a shared key scheme, the peers share some symmetric key. This 823 key is associated with a key identifier which is known to both 824 parties. It is assumed that the party verifying that identity also 825 has some sort of table that indicates what sorts of traffic (e.g. 827 what addresses) that identity is allowed to negotiate SAs for. 829 7.3.2.2. Pre-configured public key 831 A pre-configured public key scheme is the same as a shared key 832 scheme except that the verifying party has the authenticating 833 party's public key instead of a shared key. 835 7.3.2.3. Certificate 837 In a certificate scheme, authenticating party presents a 838 certificate containing their public key. It's straightforward to 839 establish that that certificate matches the authentication data 840 provided by the peer. What's less straightforward is to determine 841 whether a given peer is entitled to negotiate for a given class of 842 traffic. In theory, one might be able to determine this from the 843 name in the certificate (e.g. the subject name contains an IP 844 address that matches the ostensible IP address). In practice, this 845 is not clearly specified in IKE and therefore not really 846 interoperable. The more likely case at the moment is that there is 847 a configuration table mapping certificates to policies, as with the 848 other two authentication schemes. 850 Normative References 852 There are no normative references for this document. 854 Informative References 855 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 856 RFC 2402, November 1998. 858 [CCID2] Floyd, S., Kohler, E., "Profile for DCCP Congestion Control ID 2: 859 TCP-like Congestion Control", draft-ietf-dccp-ccid2-04.txt, 860 October 2003. 862 [CCID3] Floyd, S., Kohler, E., Padhye, J. "Profile for DCCP Congestion 863 Control ID 3: TFRC Congestion Control", 864 draft-ietf-dccp-ccid3-05.txt, February 2004. 866 [DCCP] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion 867 Control Protocol (DCCP)", draft-ietf-dccp-spec-06.txt, 868 February 2004. 870 [ECN] Ramakrishnan, K. Floyd, S., Black D., "The Addition of 871 Explicit Congestion Notification (ECN) to IP", 872 RFC 3168, September 2001. 874 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 875 Payload (ESP)", RFC 2406, November 1998. 877 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 878 RFC 2409, November 1998. 880 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet 881 Protocol", RFC 2401, November 1998. 883 [KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication 884 Service (V5)", RFC 1510, September 1993. 886 [SDP] Handley, M., Jacobson, V., "SDP: Session Description Protocol" 887 RFC 2327, April 1998. 889 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R., 890 "STUN - Simple Traversal of User Datagram Protocol (UDP)", 891 RFC 3489, March 2003. 893 [WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D. 894 "HTTP Extensions for Distributed Authoring -- WEBDAV", 895 RFC 2518, February 1999. 897 Security Considerations 899 This document does not define any protocols and therefore has no 900 security considerations. 902 Full Copyright Statement 904 The IETF takes no position regarding the validity or scope of any 905 Intellectual Property Rights or other rights that might be claimed to 906 pertain to the implementation or use of the technology described in 907 this document or the extent to which any license under such rights 908 might or might not be available; nor does it represent that it has 909 made any independent effort to identify any such rights. Information 910 on the procedures with respect to rights in RFC documents can be 911 found in BCP 78 and BCP 79. 913 Copies of IPR disclosures made to the IETF Secretariat and any 914 assurances of licenses to be made available, or the result of an 915 attempt made to obtain a general license or permission for the use of 916 such proprietary rights by implementers or users of this 917 specification can be obtained from the IETF on-line IPR repository at 918 http://www.ietf.org/ipr. 920 The IETF invites any interested party to bring to its attention any 921 copyrights, patents or patent applications, or other proprietary 922 rights that may cover technology that may be required to implement 923 this standard. Please address the information to the IETF at ietf- 924 ipr@ietf.org. 926 Copyright Notice 927 Copyright (C) The Internet Society (2003). This document is subject 928 to the rights, licenses and restrictions contained in BCP 78, and 929 except as set forth therein, the authors retain all their rights. 931 This document and the information contained herein are provided on an 932 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 933 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 934 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 935 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 936 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 937 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 939 Author's Address 940 Eric Rescorla 941 RTFM, Inc. 942 2064 Edgewood Drive 943 Palo Alto, CA 94303 944 Phone: (650)-320-8549 946 Internet Architecture Board 947 IAB 949 Appendix A. IAB Members at the time of this writing 951 Bernard Aboba 952 Harald Alvestrand 953 Rob Austein 954 Leslie Daigle 955 Patrik Falstrom 956 Sally Floyd 957 Jun-ichiro Itojun Hagino 958 Mark Handley 959 Bob Hinden 960 Geoff Huston 961 Eric Rescorla 962 Pete Resnick 963 Jonathon Rosenberg