draft-iab-model-01.txt   draft-iab-model-02.txt 
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
INTERNET-DRAFT IAB INTERNET-DRAFT IAB
draft-iab-model-01.txt May 2004 (Expires November 2004) draft-iab-model-02.txt September 2004 (Expires March 2005)
Writing Protocol Models Writing Protocol Models
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. Internet-Drafts are working patent or other IPR claims of which I am aware have been disclosed,
documents of the Internet Engineering Task Force (IETF), its areas, and any of which I become aware will be disclosed, in accordance with
and its working groups. Note that other groups may also distribute RFC 3668.
working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate- time. It is inappropriate to use Internet-Drafts as reference
rial or to cite them other than as ``work in progress.'' material or to cite them other than a "work in progress."
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow http://www.ietf.org/1id-abstracts.html
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or The list of Internet-Draft Shadow Directories can be accessed at
ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (1999-2004). All Rights Reserved.
Abstract Abstract
The IETF process depends on peer review. However, IETF documents are The IETF process depends on peer review. However, IETF documents
generally written to be useful for implementors, not for reviewers. are generally written to be useful for implementors, not for
In particular, while great care is generally taken to provide a com- reviewers. In particular, while great care is generally taken to
plete description of the state machines and bits on the wire, this provide a complete description of the state machines and bits on
level of detail tends to get in the way of initial understanding. the wire, this level of detail tends to get in the way of initial
This document describes an approach for providing protocol "models" understanding. This document describes an approach for providing
that allow reviewers to quickly grasp the essence of a system. protocol "models" that allow reviewers to quickly grasp the essence
of a system.
Contents
1 Introduction 2
2 The Purpose of a Protocol Model 3
3 Basic Principles 3
3.1 Less is more 4
3.2 Abstraction is good 4
3.3 A few well-chosen details sometimes helps 4
4 Writing Protocol Models 4
4.1 Describe the problem you're trying to solve 4
4.1.1 Example: STUN (RFC 3489) 5
4.2 Describe the protocol in broad overview 7
4.3 State Machines 8
4.4 Example: DCCP 8
4.4.1 Initiation 8
4.4.2 Feature Negotiation 9
4.4.3 Data Transfer 10
4.4.3.1 CCID-2 10
4.4.3.2 CCID-3 10
4.4.4 Termination 10
5 Describe any important protocol features 11
5.1 Example: WebDAV COPY and MOVE 11
6 Formatting Issues 12
7 A Complete Example: Internet Key Exchange (IKE) 12
7.1 Operating Environment 12
7.1.1 Initiator and Responder 13
7.1.2 Perfect Forward Secrecy 13
7.1.3 Denial of Service Resistance 14
7.1.4 Keying Assumptions 14
7.1.5 Identity Protection 14
7.2 Protocol Overview 14
7.2.1 Stage 1 15
7.2.1.1 Main Mode 15
7.2.1.2 Aggressive Mode 17
7.2.2 Stage 2 18
7.3 Other Considerations 19
7.3.1 Cookie Generation 19
7.3.2 Endpoint Identities 19
7.3.2.1 Shared Key 19
7.3.2.2 Pre-configured public key 20
7.3.2.3 Certificate 20
1. Introduction 1. Introduction
The IETF process depends on peer review. However, in many cases, the The IETF process depends on peer review. However, in many cases,
documents submitted for publication are extremely difficult to the documents submitted for publication are extremely difficult to
review. Since reviewers have only limited amounts of time, this leads review. Since reviewers have only limited amounts of time, this
to extremely long review times, inadequate reviews, or both. In my
view, a large part of the problem is that most documents fail to pre- Rescorla [Page 2] Internet-Draft Writing Protocol Models 9/2004
sent an architectural model for how the protocol operated, opting
instead to siply describe the protocol and let the reviewer figure it leads to extremely long review times, inadequate reviews, or both.
out. In my view, a large part of the problem is that most documents fail
to present an architectural model for how the protocol operates,
opting instead to simply describe the protocol and let the reviewer
figure it out.
This is acceptable when documenting a protocol for implementors, This is acceptable when documenting a protocol for implementors,
because they need to understand the protocol in any case, but dramat- because they need to understand the protocol in any case, but
ically increases the strain on reviewers. Reviewers necessarily need dramatically increases the strain on reviewers. Reviewers
to get the big picture of the system and then focus on particular necessarily need to get the big picture of the system and then
points. They simply do not have time to give the entire document the focus on particular points. They simply do not have time to give
attention an implementor would. the entire document the attention an implementor would.
One way to reduce this load is to present the reviewer with a One way to reduce this load is to present the reviewer with a
MODEL--a short description of the system in overview form. This pro- MODEL--a short description of the system in overview form. This
vides the reviewer with the context to identify the important or dif- provides the reviewer with the context to identify the important or
ficult pieces of the system and focus on them for review. As a side difficult pieces of the system and focus on them for review. As a
benefit, if the model is done first, it can be serve as an aid to the side benefit, if the model is done first, it can be serve as an aid
detailed protocol design and a focus for early review prior to proto- to the detailed protocol design and a focus for early review prior
col completion. The intention is that the model would either be the to protocol completion. The intention is that the model would
first section of the protocol document or be a separate document pro- either be the first section of the protocol document or be a
vided with the protocol. separate document provided with the protocol.
2. The Purpose of a Protocol Model 2. The Purpose of a Protocol Model
A protocol model needs to answer three basic questions: A protocol model needs to answer three basic questions:
1. What problem is the protocol trying to achieve? 1. What problem is the protocol trying to achieve?
2. What messages are being transmitted and what do they 2. What messages are being transmitted and what do they
mean? mean?
3. What are the important but un-obvious features of the 3. What are the important but un-obvious features of the
protocol? protocol?
The basic idea is to provide enough information that the reader could The basic idea is to provide enough information that the reader
design a protocol which was roughly isomorphic to the protocol being could design a protocol which was roughly isomorphic to the
described. This doesn't, of course, mean that the protocol would be protocol being described. This doesn't, of course, mean that the
identical, but merely that it would share most important features. protocol would be identical, but merely that it would share most
For instance, the decision to use a KDC-based authentication model is important features. For instance, the decision to use a KDC-based
an essential feature of Kerberos [KERBEROS]. By constrast, the use of authentication model is an essential feature of Kerberos
ASN.1 is a simple implementation decision. S-expressions--or XML, had [KERBEROS]. By constrast, the use of ASN.1 is a simple
it existed at the time--would have served equally well. implementation decision. S-expressions--or XML, had it existed at
the time--would have served equally well.
3. Basic Principles 3. Basic Principles
In this section we discuss basic principles that should guide your In this section we discuss basic principles that should guide your
presentation. presentation.
3.1. Less is more 3.1. Less is more
Humans are only capable of keeping a very small number of pieces of Humans are only capable of keeping a very small number of pieces of
information in their head at once. Since we're interested in ensuring information in their head at once. Since we're interested in
that people get the big picture, we therefore have to dispense with a ensuring that people get the big picture, we therefore have to
lot of detail. That's good, not bad. The simpler you can make things dispense with a lot of detail. That's good, not bad. The simpler
you can make things the better.
Rescorla [Page 2] Internet-Draft Writing Protocol Models 5/2004
the better.
3.2. Abstraction is good 3.2. Abstraction is good
A key technique for representing complex systems is to try to A key technique for representing complex systems is to try to
abstract away pieces. For instance, maps are better than photographs abstract away pieces. For instance, maps are better than
for finding out where you want to go because they provide an photographs for finding out where you want to go because they
abstract, stylized, view of the information you're interested in. provide an abstract, stylized, view of the information you're
Don't be afraid to compress multiple protocol elements into a single interested in. Don't be afraid to compress multiple protocol
abstract piece for pedagogical purposes. elements into a single abstract piece for pedagogical purposes.
3.3. A few well-chosen detail sometimes helps 3.3. A few well-chosen details sometimes helps
The converse of the the previous principle is that sometimes details The converse of the previous principle is that sometimes details
help to bring a description into focus. Many people work better when help to bring a description into focus. Many people work better
given examples. Thus, it's often a good approach to talk about the when given examples. Thus, it's often a good approach to talk about
material in the abstract and then provide a concrete description of the material in the abstract and then provide a concrete
one specific piece to bring it into focus. Authors should focus on description of one specific piece to bring it into focus. Authors
the normal path. Error cases and corner cases should only be dis- should focus on the normal path. Error cases and corner cases
cussed where they help illustrate some important point. should only be discussed where they help illustrate some important
point.
4. Writing Protocol Models 4. Writing Protocol Models
Our experience indicates that it's easiest to grasp protocol models Our experience indicates that it's easiest to grasp protocol models
when they're presented in visual form. We recommend a presentation when they're presented in visual form. We recommend a presentation
format that is centered around a few key diagrams with explanatory format that is centered around a few key diagrams with explanatory
text for each. These diagrams should be simple and typically consist text for each. These diagrams should be simple and typically
of "boxes and arrows"--boxes representing the major components, consist of "boxes and arrows"--boxes representing the major
arrows representing their relationships and labels indicating impor- components, arrows representing their relationships and labels
tant features. indicating important features.
We recommend a presentation structured in three parts to match the We recommend a presentation structured in three parts to match the
three questions mentioned in the previous sections. Each part should three questions mentioned in the previous sections. Each part
contain 1-3 diagrams intended to illustrate the relevant points. should contain 1-3 diagrams intended to illustrate the relevant
points.
4.1. Describe the problem you're trying to solve 4.1. Describe the problem you're trying to solve
Rescorla [Page 4] Internet-Draft Writing Protocol Models 9/2004
First, figure out what you are trying to do (this is good First, figure out what you are trying to do (this is good
advice under most circumstances, and it is especially apropos here. advice under most circumstances, and it is especially apropos here.
--NNTP Installation Guide --NNTP Installation Guide
The absolutely most critical task that a protocol model must perform The absolutely most critical task that a protocol model must
is to explain what the protocol is trying to achieve. This provides perform is to explain what the protocol is trying to achieve. This
crucial context for understanding how the protocol works and whether provides crucial context for understanding how the protocol works
it meets its goals. Given the desired goals, in most cases an experi- and whether it meets its goals. Given the desired goals, in most
enced reviewer will have an idea of how they would approach the prob- cases an experienced reviewer will have an idea of how they would
lem and be able to compare that to the approach taken by the protocol approach the problem and be able to compare that to the approach
taken by the protocol under review.
under review.
The "Problem" section of the model should start out with a short The "Problem" section of the model should start out with a short
statement of the environments in which the protocol is expected to be statement of the environments in which the protocol is expected to
used. This section should describe the relevant entities and the be used. This section should describe the relevant entities and the
likely scenarios under which they participate in the protocol. The likely scenarios under which they participate in the protocol. The
Problem section should feature a diagram showing the major communi- Problem section should feature a diagram showing the major
cating parties and their inter-relationships. It is particularly communicating parties and their inter-relationships. It is
important to lay out the trust relationships between the various par- particularly important to lay out the trust relationships between
ties as these are often un-obvious. the various parties as these are often un-obvious.
4.1.1. Example: STUN (RFC 3489) 4.1.1. Example: STUN (RFC 3489)
Network Address Translation (NAT) makes it difficult to run a number Network Address Translation (NAT) makes it difficult to run a
of classes of service from behind the NAT gateway. This is a particu- number of classes of service from behind the NAT gateway. This is a
lar problem when protocols need to advertise address/port pairs as particular problem when protocols need to advertise address/port
part of the application layer protocol. Although the NAT can be con- pairs as part of the application layer protocol. Although the NAT
figured to accept data destined for that port, address translation can be configured to accept data destined for that port, address
means that the address that the application knows about is not the translation means that the address that the application knows about
same as the one that it is reachable on. is not the same as the one that it is reachable on.
Consider the scenario represented in the figure below. A SIP client Consider the scenario represented in the figure below. A SIP client
is initiating a session with a SIP server in which it wants the SIP is initiating a session with a SIP server in which it wants the SIP
server to send it some media. In its Session Description Protocol server to send it some media. In its Session Description Protocol
(SDP) [SDP] request it provides the IP and port on which it is lis- (SDP) [SDP] request it provides the IP address and port on which it
tening. However, unbeknownst to the client, a NAT is in the way. It is listening. However, unbeknownst to the client, a NAT is in the
translates the IP address in the header, but unless it is SIP aware, way. It translates the IP address in the header, but unless it is
it doesn't change the address in the request. The result is that the SIP aware, it doesn't change the address in the request. The result
media goes into a black hole. is that the media goes into a black hole.
Rescorla [Page 4] Internet-Draft Writing Protocol Models 5/2004
+-----------+ +-----------+
| SIP | | SIP |
| Server | | Server |
| | | |
+-----------+ +-----------+
^ ^
| [FROM: 198.203.2.1:8954] | [FROM: 192.0.2.1:8954]
| [MSG: SEND MEDIA TO 10.0.10.5:6791] | [MSG: SEND MEDIA TO 10.0.10.5:6791]
| |
| |
+-----------+ +-----------+
| | | |
| NAT | | NAT |
--------------+ Gateway +---------------- --------------+ Gateway +----------------
| | | |
+-----------+ +-----------+
^ ^
| [FROM: 10.0.10.5:6791] | [FROM: 10.0.10.5:6791]
| [MSG: SEND MEDIA TO 10.0.10.5:6791] | [MSG: SEND MEDIA TO 10.0.10.5:6791]
| |
10.0.10.5 10.0.10.5
+-----------+ +-----------+
| SIP | | SIP |
| Client | | Client |
| | | |
+-----------+ +-----------+
The purpose of STUN [STUN] is to allow clients to detect this situation The purpose of STUN [STUN] is to allow clients to detect this
and determine the address mapping. They can then place the appropriate situation and determine the address mapping. They can then place the
address in their application-level messages. This is done by making use appropriate address in their application-level messages. This is done
of an external STUN server. That server is able to determine the trans- by making use of an external STUN server. That server is able to
lated address and tell the STUN client, as shown below. determine the translated address and tell the STUN client, as shown
below.
Rescorla [Page 6] Internet-Draft Writing Protocol Models 9/2004
+-----------+ +-----------+
| STUN | | STUN |
| Server | | Server |
| | | |
+-----------+ +-----------+
^ | ^ |
[IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954] [IP HDR FROM: 192.0.2.1:8954] | | [IP HDR TO: 192.0.2.1:8954]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 192.0.2.1:8954]
| v | v
+-----------+ +-----------+
| | | |
| NAT | | NAT |
--------------+ Gateway +---------------- --------------+ Gateway +----------------
| | | |
+-----------+ +-----------+
^ | ^ |
[IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791] [IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 192.0.2.1:8954]
| v | v
10.0.10.5 10.0.10.5
+-----------+ +-----------+
| SIP | | SIP |
| Client | | Client |
| | | |
+-----------+ +-----------+
4.2. Describe the protocol in broad overview 4.2. Describe the protocol in broad overview
Once you've described the problem, the next task is to describe the Once you've described the problem, the next task is to describe the
protocol in broad overview. This means showing, either in "ladder protocol in broad overview. This means showing, either in "ladder
diagram" or "boxes and arrows" form, the protocol messages that flow diagram" or "boxes and arrows" form, the protocol messages that
between the various networking agents. This diagram should be accom- flow between the various networking agents. This diagram should be
pied with explanatory text that describes the purpose of each message accompanied with explanatory text that describes the purpose of
and the MAJOR data elements. each message and the MAJOR data elements.
This section SHOULD NOT contain detailed descriptions of the protocol
messages or of each data element. In particular, bit diagrams, ASN.1
modules and XML schema SHOULD NOT be shown. The purpose of this sec-
tion is explicitly not to provide a complete description of the pro-
tocol. Instead, it is to provide enough of a map so that a person
reading the full protocol document can see where each specific piece
fits.
Rescorla [Page 6] Internet-Draft Writing Protocol Models 5/2004 This section SHOULD NOT contain detailed descriptions of the
protocol messages or of each data element. In particular, bit
diagrams, ASN.1 modules and XML schema SHOULD NOT be shown. The
purpose of this section is explicitly not to provide a complete
description of the protocol. Instead, it is to provide enough of a
map so that a person reading the full protocol document can see
where each specific piece fits.
4.3. State Machines 4.3. State Machines
In certain cases, it may be helpful to provide a state machine In certain cases, it may be helpful to provide a state machine
description of the behavior of network elements. However, such state description of the behavior of network elements. However, such
machines should be kept as minimal as possible. Remember that the state machines should be kept as minimal as possible. Remember that
purpose is to promote high-level comprehension, not complete under- the purpose is to promote high-level comprehension, not complete
standing. understanding.
4.4. Example: DCCP 4.4. Example: DCCP
Although DCCP [DCCP] is datagram oriented like UDP, it is stateful Although DCCP [DCCP] is datagram oriented like UDP, it is stateful
like TCP. Connections go through the following phases: like TCP. Connections go through the following phases:
1. Initiation 1. Initiation
2. Feature negotiation 2. Feature negotiation
3. Data transfer 3. Data transfer
4. Termination 4. Termination
4.4.1. Initiation 4.4.1. Initiation
As with TCP, the initiation phase of DCCP involves a three-way hand- As with TCP, the initiation phase of DCCP involves a three-way
shake, shown in Figure 1. handshake, shown below.
Client Server Client Server
------ ------ ------ ------
DCCP-Request -> DCCP-Request ->
[Ports, Service, [Ports, Service,
Features] Features]
<- DCCP-Response <- DCCP-Response
[Features, [Features,
Cookie] Cookie]
DCCP-Ack -> DCCP-Ack ->
[Features, [Features,
Cookie] Cookie]
FFiigguurree 11 DCCP 3-way handshake DCCP 3-way handshake
In the DCCP-Request message, the client tells the server the name of In the DCCP-Request message, the client tells the server the name
the service it wants to talk to and the ports it wants to communicate of the service it wants to talk to and the ports it wants to
on. Note that ports are not tightly bound to services the way they communicate on. Note that ports are not tightly bound to services
are in TCP or UDP common practice. It also starts feature negotia- the way they are in TCP or UDP common practice. It also starts
tion. For pedagogical reasons, we will present feature negotiation feature negotiation. For pedagogical reasons, we will present
separately in the next section. However, realize that the early feature negotiation separately in the next section. However,
phases of feature negotiation happen concurrently with initiation. realize that the early phases of feature negotiation happen
concurrently with initiation.
In the DCCP-Response message, the server tells the client that it is In the DCCP-Response message, the server tells the client that it
willing to accept the connection and continues feature negotiation. is willing to accept the connection and continues feature
In order to prevent SYN-flood style DOS attacks, DCCP incorporates an negotiation. In order to prevent SYN-flood style DOS attacks, DCCP
IKE-style cookie exchange. The server can provide the client with a incorporates an IKE-style cookie exchange. The server can provide
cookie that contains all the negotiation state. This cookie must be
echoed by the client in the DCCP-Ack, thus removing the need for the Rescorla [Page 8] Internet-Draft Writing Protocol Models 9/2004
server to keep state.
the client with a cookie that contains all the negotiation state.
This cookie must be echoed by the client in the DCCP-Ack, thus
removing the need for the server to keep state.
In the DCCP-Ack message, the client acknowledges the DCCP-Response In the DCCP-Ack message, the client acknowledges the DCCP-Response
and returns the cookie to permit the server to compleye its side of and returns the cookie to permit the server to complete its side of
the connection. As indicated in Figure 1, this message may also the connection. As indicated above this message may also include
include feature negotiation messages. feature negotiation messages.
4.4.2. Feature Negotiation 4.4.2. Feature Negotiation
In DCCP, feature negotiation is performed by attaching options to In DCCP, feature negotiation is performed by attaching options to
other DCCP packets. Thus feature negotiation can be piggybacked on other DCCP packets. Thus feature negotiation can be piggybacked on
any other DCCP message. This allows feature negotiation during con- any other DCCP message. This allows feature negotiation during
nection initiation as well as feature renegotiation during data flow. connection initiation as well as feature renegotiation during data
flow.
Somewhat unusually, DCCP features are one-sided. Thus, it's possible
to have a different congestion control regime for data sent from
client to server than from server to client.
Feature negotiation is done with three options:
1. Change
2. Prefer
3. Confirm
A Change message says to the peer "change this option setting on your Somewhat unusually, DCCP features are one-sided. Thus, it's
side". The peer can either respond with a Confirm, meaning "I've possible to have a different congestion control regime for data
changed it" or a Prefer, containing a list of other settings that the sent from client to server than from server to client.
peer would like. Multiple exchanges of Change and Prefer may occur as
the peers attempt so sort out what options they have in common. Some
sample exchanges (partly cribbed from the DCCP spec) follow:
Client Server Feature negotiation is done with the Change and Confirm options.
------ ------ There are four feature negotiation options in all: Change L,
Change(CC,2) -> Confirm L, Change R, and Confirm R. The "L" options are sent by the
<- Confirm(CC,2) feature location, where the feature is maintained, and the "R"
options are sent by the feature remote.
In this exchange, the peers agree to set CC equal to 2. A Change R message says to the peer "change this option setting on
your side". The peer can respond with a Confirm L, meaning "I've
changed it". Some features allow Change R options to contain
multiple values, sorted in preference order. For example:
Client Server Client Server
------ ------ ------ ------
Change(CC,3,4) -> Change R(CCID, 2) -->
<- Prefer(CC,1,2,5) <-- Confirm L(CCID, 2)
Change(CC,5) -> * agreement that CCID/Server = 2 *
<- Confirm(CC,5)
In this exchange, the client requests CC values 3 and 4. Note that
the client can offer multiple values. The server doesn't like any of
Rescorla [Page 8] Internet-Draft Writing Protocol Models 5/2004 Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
<- Confirm(CC,2)
these and offers 1, 2, and 5. The client chooses 5 and the server In the second exchange, the client requests that the server use
agrees. either CCID 3 or CCID 4, with 3 preferred. The server chooses 4 and
supplies its preference list, "4 2".
Since features are one-sided, if a party wants to change one of his The Change L and Confirm R options are used for feature
own options, he must ask the peer to issue a Change. This is done negotiations initiated by the feature location. In the following
using a Prefer, as shown below, where the client gets the server to example, the server requests that CCID/Server be set to 3 or 2,
request that the client change the value of CC to 3. with 3 preferred, and the client agrees.
Client Server Client Server
------ ------ ------ ------
Prefer(CC,3,4) -> <-- Change L(CCID, 3 2)
<- Change(CC,3) Confirm R(CCID, 3, 3 2) -->
Confirm(CC,3) -> * agreement that CCID/Server = 3 *
4.4.3. Data Transfer 4.4.3. Data Transfer
Rather than have a single congestion control regime as in TCP, DCCP Rather than have a single congestion control regime as in TCP, DCCP
offers a variety of negotiable congestion control regimes. The DCCP offers a variety of negotiable congestion control regimes. The DCCP
documents describe two congestion control regimes: additive increase, documents describe two congestion control regimes: additive
multiplicative decrease (CCID-2 [CCID2]) and TCP-friendly rate con- increase, multiplicative decrease (CCID-2 [CCID2]) and TCP-friendly
trol (CCID-3 [CCID3]). CCID-2 is intended for applications which want rate control (CCID-3 [CCID3]). CCID-2 is intended for applications
maximum throughput. CCID-3 is intended for real-time applications which want maximum throughput. CCID-3 is intended for real-time
which want smooth response to congestion. applications which want smooth response to congestion.
4.4.3.1. CCID-2 4.4.3.1. CCID-2
CCID-2's congestion control is extremely similar to that of TCP. The CCID-2's congestion control is extremely similar to that of TCP.
sender maintains a congestion window and sends packets until that The sender maintains a congestion window and sends packets until
window is full. Packets are Acked by the receiver. Dropped packets that window is full. Packets are Acked by the receiver. Dropped
and ECN [ECN] are used to indicate congestion. The response to con- packets and ECN [ECN] are used to indicate congestion. The response
gestion is to halve the congestion window. One subtle diference to congestion is to halve the congestion window. One subtle
between DCCP and TCP is that the Acks in DCCP must contain the diference between DCCP and TCP is that the Acks in DCCP must
sequence numbers of all received packets (within a given window) not contain the sequence numbers of all received packets (within a
just the highest sequence number as in TCP. given window) not just the highest sequence number as in TCP.
4.4.3.2. CCID-3 4.4.3.2. CCID-3
CCID-3 is an equation based form of rate control which is intended to CCID-3 is an equation-based form of rate control which is intended
provide smoother response to congestion than CCID-2. The sender main- to provide smoother response to congestion than CCID-2. The sender
tains a "transmit rate". The receiver sends ACK packets which also maintains a "transmit rate". The receiver sends ACK packets which
contain information about the receiver's estimate of packet loss. The also contain information about the receiver's estimate of packet
sender uses this information to update its transmit rate. Although loss. The sender uses this information to update its transmit rate.
CCID-3 behaves somewhat differently from TCP in its short term con- Although CCID-3 behaves somewhat differently from TCP in its short-
gestion response, it is designed to operate fairly with TCP over the term congestion response, it is designed to operate fairly with TCP
long term. over the long term.
4.4.4. Termination 4.4.4. Termination
Connection termination in DCCP is initiated by sending a Close mes- Connection termination in DCCP is initiated by sending a Close
sage. Either side can send a Close message. The peer then responds message. Either side can send a Close message. The peer then
with a Reset message, at which point the connection is closed. The responds with a Reset message, at which point the connection is
side that sent the Close message must quietly preserve the socket in
TIMEWAIT state for 2MSL. Rescorla [Page 10] Internet-Draft Writing Protocol Models 9/2004
closed. The side that sent the Close message must quietly preserve
the socket in TIMEWAIT state for 2MSL.
Client Server Client Server
------ ------ ------ ------
Close -> Close ->
<- Reset <- Reset
[Remains in TIMEWAIT] [Remains in TIMEWAIT]
Note that the server may wish to close the connection but not remain Note that the server may wish to close the connection but not
in TIMEWAIT (e.g., due to a desire to minimize server-side state.) In remain in TIMEWAIT (e.g., due to a desire to minimize server-side
order to accomplish this, the server can elicit a Close from the state.) In order to accomplish this, the server can elicit a Close
client by sending a CloseReq message and thus keeping the TIMEWAIT from the client by sending a CloseReq message and thus keeping the
state on the client. TIMEWAIT state on the client.
5. Describe any important protocol features 5. Describe any important protocol features
The final section (if there is one) should contain an explanation of The final section (if there is one) should contain an explanation
any important protocol features which are not obvious from the previ- of any important protocol features which are not obvious from the
ous sections. In the best case, all the important features of the previous sections. In the best case, all the important features of
protocol would be obvious from the message flow. However, this isn't the protocol would be obvious from the message flow. However, this
always the case. This section is an opportunity for the author to isn't always the case. This section is an opportunity for the
explicate those features. Authors should think carefully before writ- author to explain those features. Authors should think carefully
ing this section. If there are no important points to be made they before writing this section. If there are no important points to be
should not populate this section. made they should not populate this section.
Examples of the kind of feature that belongs in this section include: Examples of the kind of feature that belongs in this section
high-level security considerations, congestion control information include: high-level security considerations, congestion control
and overviews of the algorithms that the network elements are information and overviews of the algorithms that the network
intended to follow. For instance, if you have a routing protocol you elements are intended to follow. For instance, if you have a
might use this section to sketch out the algorithm that the router routing protocol you might use this section to sketch out the
uses to determine the appropriate routes from protocol messages. algorithm that the router uses to determine the appropriate routes
from protocol messages.
5.1. Example: WebDAV COPY and MOVE 5.1. Example: WebDAV COPY and MOVE
WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While WebDAV [WEBDAV] includes both a COPY method and a MOVE method.
a MOVE can be thought of as a COPY followed by DELETE, COPY+DELETE While a MOVE can be thought of as a COPY followed by DELETE,
and MOVE aren't entirely equivalent. COPY+DELETE and MOVE aren't entirely equivalent.
The use of COPY+DELETE as a MOVE substitute is problematic because of
the creation of the intermediate file. Consider the case where the
user is approaching some quota boundary. A COPY+DELETE should be for-
bidden because it would temporarily exceed the quota. However, a
Rescorla [Page 10] Internet-Draft Writing Protocol Models 5/2004 The use of COPY+DELETE as a MOVE substitute is problematic because
of the creation of the intermediate file. Consider the case where
the user is approaching some quota boundary. A COPY+DELETE should
be forbidden because it would temporarily exceed the quota.
However, a simple rename should work in this situation.
simple rename should work in this situation. The second issue is permissions. The WebDAV permissions model
allows the server to grant users permission to rename files but not
The second issue is permissions. The WebDAV permissions model allows to create new ones--this is unusual in ordinary filesystems but
the server to grant users permission to rename files but not to cre- nothing prevents it in WebDAV. This is clearly not possible if a
ate new ones--this is unusual in ordinary filesystems but nothing client uses COPY+DELETE to do a MOVE.
prevents it in WebDAV. This is clearly not possible if a client uses
COPY+DELETE to do a MOVE.
Finally, a COPY+DELETE does not produce the same logical result as Finally, a COPY+DELETE does not produce the same logical result as
would be expected with a MOVE. Because COPY creates a new resource, would be expected with a MOVE. Because COPY creates a new resource,
it is permitted (but not required) to use the time of new file cre- it is permitted (but not required) to use the time of new file
ation as the creation date property. By contrast, the expectation for creation as the creation date property. By contrast, the
move is that the renamed file will have the same properties as the expectation for move is that the renamed file will have the same
original. properties as the original.
6. Formatting Issues 6. Formatting Issues
The requirement that Internet-Drafts and RFCs be renderable in ASCII The requirement that Internet-Drafts and RFCs be renderable in
is a significant obstacle when writing the sort of graphics-heavy ASCII is a significant obstacle when writing the sort of graphics-
document being described here. Authors may find it more convenient to heavy document being described here. Authors may find it more
do a separate protocol model document in Postscript or PDF and simply convenient to do a separate protocol model document in Postscript
make it available at review time--though an archival version would or PDF and simply make it available at review time--though an
certainly be handy. archival version would certainly be handy.
7. A Complete Example: Internet Key Exchange (IKE) 7. A Complete Example: Internet Key Exchange (IKE)
7.1. Operating Environment 7.1. Operating Environment
Internet key Exchange (IKE) [IKE] is a key establishment and parame- Internet key Exchange (IKE) [IKE] is a key establishment and
ter negotiation protocol for Internet protocols. Its primary applica- parameter negotiation protocol for Internet protocols. Its primary
tion is for establishing security associations (SAs) [IPSEC] for application is for establishing security associations (SAs) [IPSEC]
IPsec AH [AH] and ESP [ESP]. for IPsec AH [AH] and ESP [ESP].
Rescorla [Page 12] Internet-Draft Writing Protocol Models 9/2004
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | Key | | IKE | | Key | | | | Key | | IKE | | Key | |
| | Management | <-+-----------------------+-> | Management | | | | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | | | | Process | | | | Process | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| ^ | | ^ | | ^ | | ^ |
| | | | | | | | | | | |
skipping to change at page 13, line ? skipping to change at page 13, line ?
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | IPsec | | AH/ESP | | IPsec | | | | IPsec | | AH/ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | | | | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | | | | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | | | | | | |
| | | | | | | |
| Initiator | | Responder | | Initiator | | Responder |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
The general deployment model for IKE is shown in Figure 2. The IPsec The general deployment model for IKE is shown in Figure 1. The
engines and IKE engines typically are separate modules. When a packet IPsec engines and IKE engines typically are separate modules. When
needs to be processed (either sent or received) for which no security a packet needs to be processed (either sent or received) for which
association exists, the IPsec engine contacts the IKE engine and asks no security association exists, the IPsec engine contacts the IKE
it to establish an appropriate SA. The IKE engine contacts the appro- engine and asks it to establish an appropriate SA. The IKE engine
priate peer and uses IKE to establish the SA. Once the IKE handshake contacts the appropriate peer and uses IKE to establish the SA.
is finished it registers the SA with the IPsec engine. Once the IKE handshake is finished it registers the SA with the
IPsec engine.
In addition, IKE traffic between the peers can be used to refresh In addition, IKE traffic between the peers can be used to refresh
keying material or adjust operating parameters such as algorithms. keying material or adjust operating parameters such as algorithms.
7.1.1. Initiator and Responder 7.1.1. Initiator and Responder
Although IPsec is basically symmetrical, IKE is not. The party who Although IPsec is basically symmetrical, IKE is not. The party who
sends the first message is called the INITIATOR. The other party is sends the first message is called the INITIATOR. The other party is
called the RESPONDER. In the case of TCP connections the INITIATOR called the RESPONDER. In the case of TCP connections the INITIATOR
will typically be the peer doing the active open (i.e. the client). will typically be the peer doing the active open (i.e. the client).
7.1.2. Perfect Forward Secrecy 7.1.2. Perfect Forward Secrecy
One of the major concerns in IKE design was that traffic be protected One of the major concerns in IKE design was that traffic be
even if they keying material of the nodes was later compromised, pro- protected even if they keying material of the nodes was later
vided that the session in question had terminated and so the session- compromised, provided that the session in question had terminated
specific keying material was gone. This property is often called PER- and so the session-specific keying material was gone. This property
FECT FORWARD SECRECY (PFS) or BACK TRAFFIC PROTECTION.
Rescorla [Page 12] Internet-Draft Writing Protocol Models 5/2004 is often called PERFECT FORWARD SECRECY (PFS) or BACK TRAFFIC
PROTECTION.
7.1.3. Denial of Service Resistance 7.1.3. Denial of Service Resistance
Since IKE allows arbitrary peers to initiate computationally expen- Since IKE allows arbitrary peers to initiate computationally
sive cryptographic operations, it potentially allows resource con- expensive cryptographic operations, it potentially allows resource
sumption denial of service attacks to be mounted against the IKE consumption denial of service attacks to be mounted against the IKE
engine. IKE includes countermeasures designed to minimize this risk. engine. IKE includes countermeasures designed to minimize this
risk.
7.1.4. Keying Assumptions 7.1.4. Keying Assumptions
Because Security Associations are essentially symmetric, both sides Because Security Associations are essentially symmetric, both sides
must in general be authenticated. Because IKE needs to be able to must in general be authenticated. Because IKE needs to be able to
establish SAs between a broad range of peers with various kinds of establish SAs between a broad range of peers with various kinds of
prior relationships, IKE supports a very flexible keying model. Peers prior relationships, IKE supports a very flexible keying model.
can authenticate via shared keys, digital signatures (typically from Peers can authenticate via shared keys, digital signatures
keys vouched for by certificates), or encryption keys. (typically from keys vouched for by certificates), or encryption
keys.
7.1.5. Identity Protection 7.1.5. Identity Protection
Although IKE requires the peers to authenticate to each other, it was Although IKE requires the peers to authenticate to each other, it
considered desirable by the working group to provide some identity was considered desirable by the working group to provide some
protection for the communicating peers. In particular, the peers identity protection for the communicating peers. In particular, the
should be able to hide their identity from passive observers and one peers should be able to hide their identity from passive observers
peer should be able to require the author to authenticate before they and one peer should be able to require the author to authenticate
self-identity. In this case, the designers chose to make the party before they self-identity. In this case, the designers chose to
who speaks first (the INITIATOR) identify first. make the party who speaks first (the INITIATOR) identify first.
7.2. Protocol Overview 7.2. Protocol Overview
At a very high level, there are two kinds of IKE handshake: At a very high level, there are two kinds of IKE handshake:
(1) Those which establish an IKE security association. (1) Those which establish an IKE security association.
(2) Those which establish an AH or ESP security association. (2) Those which establish an AH or ESP security association.
When two peers which have never communicated before need to establish When two peers which have never communicated before need to
an AH/ESH SA, they must first establish an IKE SA. This allows them establish an AH/ESH SA, they must first establish an IKE SA. This
to exchange an arbitrary amount of protected IKE traffic. They can allows them to exchange an arbitrary amount of protected IKE
then use that SA to do a second handshake to establish SAs for AH and traffic. They can then use that SA to do a second handshake to
ESP. This process is shown in schematic form below. The notation establish SAs for AH and ESP. This process is shown in schematic
E(SA,XXXX) is used to indicate that traffic is encrypted under a form below. The notation E(SA,XXXX) is used to indicate that
given SA. traffic is encrypted under a given SA.
Rescorla [Page 14] Internet-Draft Writing Protocol Models 9/2004
Initiator Responder Initiator Responder
--------- --------- --------- ---------
Handshake MSG -> \ Handshake MSG -> \ Stage 1:
<- Handshake MSG \ Establish IKE <- Handshake MSG \ Establish IKE
/ SA (IKEsa) / SA (IKEsa)
[...] / [...] /
Stage 2:
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA <- E(IKEsa, Handshake MSG) / SA
IKE terminology is somewhat confusing, referring under different cir- The two kinds of IKE handshake
cumstances to "phases" and "modes". For maximal clarity we will refer
to the the Establishment of the IKE SA as "Stage 1" and the Estab- IKE terminology is somewhat confusing, referring under different
lishment of AH/ESP SAs as "Stage 2". Note that it's quite possible circumstances to "phases" and "modes". For maximal clarity we will
for there to be more than one Stage 2 handshake, once Stage 1 has refer to the Establishment of the IKE SA as "Stage 1" and the
been finished. This might be useful if you wanted to establish multi- Establishment of AH/ESP SAs as "Stage 2". Note that it's quite
ple AH/ESP SAs with different cryptographic properties. possible for there to be more than one Stage 2 handshake, once
Stage 1 has been finished. This might be useful if you wanted to
establish multiple AH/ESP SAs with different cryptographic
properties.
The Stage 1 and Stage 2 handshakes are actually rather different, The Stage 1 and Stage 2 handshakes are actually rather different,
because the Stage 2 handshake can of course assume that its traffic because the Stage 2 handshake can of course assume that its traffic
is being protected with an IKE SA. Accordingly, we will first discuss is being protected with an IKE SA. Accordingly, we will first
Stage 1 and then Stage 2. discuss Stage 1 and then Stage 2.
7.2.1. Stage 1 7.2.1. Stage 1
There are a large number of variants of the IKE Stage 1 handshake, There are a large number of variants of the IKE Stage 1 handshake,
necessitated by use of different authentication mechanisms. However, necessitated by use of different authentication mechanisms.
broadly speaking they fall into one of two basic categories: MAIN However, broadly speaking they fall into one of two basic
MODE, which provides identity protection and DoS resistance, and categories: MAIN MODE, which provides identity protection and DoS
AGGRESSIVE MODE, which does not. We will cover MAIN MODE first. resistance, and AGGRESSIVE MODE, which does not. We will cover MAIN
MODE first.
7.2.1.1. Main Mode 7.2.1.1. Main Mode
Main Mode is a six message (3 round trip) handshake which offers Main Mode is a six message (3 round trip) handshake which offers
identity protection and DoS resistance. An overview of the handshake identity protection and DoS resistance. An overview of the
is below. handshake is below.
Rescorla [Page 14] Internet-Draft Writing Protocol Models 5/2004
Initiator Responder Initiator Responder
--------- --------- --------- ---------
CookieI, Algorithms -> \ Parameter CookieI, Algorithms -> \ Parameter
<- CookieR, Algorithms / Establishment <- CookieR, Algorithms / Establishment
CookieR, CookieR,
Nonce, Key Exchange -> Nonce, Key Exchange ->
<- Nonce, Key Exchange\ Establish <- Nonce, Key Exchange\ Establish
/ Shared key / Shared key
E(IKEsa, Auth Data) -> E(IKEsa, Auth Data) ->
<- E(IKEsa, Auth data)\ Authenticate <- E(IKEsa, Auth data)\ Authenticate
/ Peers / Peers
In the first round trip, the Initiator offers a set of algorithms and IKE Main Mode handshake (stage 1)
parameters. The Responder picks out the single set that it likes and
responds with that set. It also provides CookieR, which will be used
to prevent DoS attacks. At this point, there is no secure association
but the peers have tentatively agreed upon parameters. These parame-
ters include a Diffie-Hellman group, which will be used in the second
round trip.
In the second round trip, the Initiator sends the key exchange infor- In the first round trip, the Initiator offers a set of algorithms
mation. This generally consists of the Initiator's Diffie-Hellman and parameters. The Responder picks out the single set that it
public share (Yi). He also supplies CookieR, which was provided by likes and responds with that set. It also provides CookieR, which
the responder. The Responder replies with his own DH share (Yr). At will be used to prevent DoS attacks. At this point, there is no
this point, both Initiator and Responder can compute the shared DH secure association but the peers have tentatively agreed upon
key (ZZ). However, there has been no authentication and so they don't parameters. These parameters include a Diffie-Hellman group, which
know with any certainty that the connection hasn't been attacked. will be used in the second round trip.
Note that as long as the peers generate fresh DH shares for each
handshake than PFS will be provided. In the second round trip, the Initiator sends the key exchange
information. This generally consists of the Initiator's Diffie-
Hellman public share (Yi). He also supplies CookieR, which was
provided by the responder. The Responder replies with his own DH
share (Yr). At this point, both Initiator and Responder can compute
the shared DH key (ZZ). However, there has been no authentication
and so they don't know with any certainty that the connection
hasn't been attacked. Note that as long as the peers generate fresh
DH shares for each handshake than PFS will be provided.
Before we move on, let's take a look at the cookie exchange. The Before we move on, let's take a look at the cookie exchange. The
basic anti-DoS measure used by IKE is to force the peer to demon- basic anti-DoS measure used by IKE is to force the peer to
strate that they can receive traffic from you. This foils blind demonstrate that they can receive traffic from you. This foils
attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier blind attacks like SYN floods [SYNFLOOD] and also makes it somewhat
to track down attackers. The cookie exchange serves this role in IKE. easier to track down attackers. The cookie exchange serves this
The Responder can verify that the Initiator supplied a valid CookieR role in IKE. The Responder can verify that the Initiator supplied a
before doing the expensive DH key agreement. This does not totally valid CookieR before doing the expensive DH key agreement. This
eliminate DoS attacks, since an attacker who was willing to reveal does not totally eliminate DoS attacks, since an attacker who was
his location could still consume server resources, but it does pro- willing to reveal his location could still consume server
tect against a certain class of blind attack. resources, but it does protect against a certain class of blind
attack.
In the final round trip, the peers establish their identities. Since Rescorla [Page 16] Internet-Draft Writing Protocol Models 9/2004
they share an (unauthenticated) key, they can send their identities
encrypted, thus providing identity protection from eavesdroppers. The
exact method of proving identity depends on what form of credential
is being used (signing key, encryption key, shared secret, etc.), but
in general you can think of it as a signature over some subset of the In the final round trip, the peers establish their identities.
handshake messages. So, each side would supply its certificate and Since they share an (unauthenticated) key, they can send their
then sign using the key associated with that certificate. If shared identities encrypted, thus providing identity protection from
keys are used, the authentication data would be a key id and a MAC. eavesdroppers. The exact method of proving identity depends on what
Authentication using public key encryption follows similar principles form of credential is being used (signing key, encryption key,
but is more complicated. Refer to the IKE document for more details. shared secret, etc.), but in general you can think of it as a
signature over some subset of the handshake messages. So, each side
would supply its certificate and then sign using the key associated
with that certificate. If shared keys are used, the authentication
data would be a key id and a MAC. Authentication using public key
encryption follows similar principles but is more complicated.
Refer to the IKE document for more details.
At the end of the Main Mode handshake, the peers share: At the end of the Main Mode handshake, the peers share:
(1) A set of algorithms for encryption of further IKE traffic. (1) A set of algorithms for encryption of further IKE traffic.
(2) Traffic encryption and authentication keys. (2) Traffic encryption and authentication keys.
(3) Mutual knowledge of the peer's identity. (3) Mutual knowledge of the peer's identity.
7.2.1.2. Aggressive Mode 7.2.1.2. Aggressive Mode
Although IKE Main Mode provides the required services, there was con- Although IKE Main Mode provides the required services, there was
cern that the large number of round trips required added excessive concern that the large number of round trips required added
latency. Accordingly, an Aggressive Mode was defined. Aggressive mode excessive latency. Accordingly, an Aggressive Mode was defined.
packs more data into fewer messages and thus reduces latency. How- Aggressive mode packs more data into fewer messages and thus
ever, it does not provide protection against DoS or identity protec- reduces latency. However, it does not provide protection against
tion. DoS or identity protection.
Initiator Responder Initiator Responder
--------- --------- --------- ---------
Algorithms, Nonce, Algorithms, Nonce,
Key Exchange, -> Key Exchange, ->
<- Algorithms, Nonce, <- Algorithms, Nonce,
Key Exchange, Auth Data Key Exchange, Auth Data
Auth Data -> Auth Data ->
After the first round trip, the peers have all the required proper- IKE Aggressive Mode handshake (stage 1)
ties except that the Initiator has not authenticated to the Respon-
der. The third message closes the loop by authenticating the Initia-
tor. Note that since the authentication data is sent in the clear, no
identity protection is provided and since the Responder does the DH
key agreement without a round trip to the Initiator, there is no DoS
protection
7.2.2. Stage 2 After the first round trip, the peers have all the required
properties except that the Initiator has not authenticated to the
Responder. The third message closes the loop by authenticating the
Initiator. Note that since the authentication data is sent in the
clear, no identity protection is provided and since the Responder
does the DH key agreement without a round trip to the Initiator,
there is no DoS protection
Stage 1 on its own isn't very useful. The purpose of IKE, after all, 7.2.2. Stage 2
is to establish associations to be used to protect other traffic, not
just to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is
used for this purpose. The basic Stage 2 handshake is shown below.
Rescorla [Page 16] Internet-Draft Writing Protocol Models 5/2004 Stage 1 on its own isn't very useful. The purpose of IKE, after
all, is to establish associations to be used to protect other
traffic, not just to establish IKE SAs. Stage 2 (what IKE calls
"Quick Mode") is used for this purpose. The basic Stage 2 handshake
is shown below.
Initiator Responder Initiator Responder
--------- --------- --------- ---------
AH/ESP parameters, AH/ESP parameters,
Algorithms, Nonce, Algorithms, Nonce,
Handshake Hash -> Handshake Hash ->
<- AH/ESP parameters, <- AH/ESP parameters,
Algorithms, Nonce, Algorithms, Nonce,
Handshake Hash Handshake Hash
Handshake Hash -> Handshake Hash ->
The basic IKE Quick Mode (stage 2)
As with quick mode, the first two messages establish the algorithms As with quick mode, the first two messages establish the algorithms
and parameters while the final message is a check over the previous and parameters while the final message is a check over the previous
messages. In this case, the parameters also include the transforms to messages. In this case, the parameters also include the transforms
be applied to the traffic (AH or ESP) and the kinds of traffic which to be applied to the traffic (AH or ESP) and the kinds of traffic
are to be protected. Note that there is no key exchange information which are to be protected. Note that there is no key exchange
shown in these messages. information shown in these messages.
In this version of Quick Mode, the peers use the pre-existing Stage 1 In this version of Quick Mode, the peers use the pre-existing Stage
keying material to derive fresh keying material for traffic protec- 1 keying material to derive fresh keying material for traffic
tion (with the nonces to ensure freshness). Quick mode also allows protection (with the nonces to ensure freshness). Quick mode also
for a new Diffie-Hellman handshake for per-traffic key PFS. In that allows for a new Diffie-Hellman handshake for per-traffic key PFS.
case, the first two messages shown above would also include Key In that case, the first two messages shown above would also include
Exchange payloads, as shown below. Key Exchange payloads, as shown below.
Rescorla [Page 18] Internet-Draft Writing Protocol Models 9/2004
Initiator Responder Initiator Responder
--------- --------- --------- ---------
AH/ESP parameters, AH/ESP parameters,
Algorithms, Nonce, Algorithms, Nonce,
Key Exchange, -> Key Exchange, ->
Handshake Hash Handshake Hash
<- AH/ESP parameters, <- AH/ESP parameters,
Algorithms, Nonce, Algorithms, Nonce,
Key Exchange, Key Exchange,
Handshake Hash Handshake Hash
Handshake Hash -> Handshake Hash ->
A variant of Quick Mode with PFS (stage 2)
7.3. Other Considerations 7.3. Other Considerations
There are a number of features of IKE that deserve special considera- There are a number of features of IKE that deserve special
tion. These are discussed here. consideration. These are discussed here.
7.3.1. Cookie Generation 7.3.1. Cookie Generation
As mentioned previously, IKE uses cookies as a partial defense As mentioned previously, IKE uses cookies as a partial defense
against DoS attacks. When the responder receives Main Mode message 3 against DoS attacks. When the responder receives Main Mode message
containing the Key Exchange data and the cookie, it verifies that the 3 containing the Key Exchange data and the cookie, it verifies that
the cookie is correct. However, this verification must not involve
cookie is correct. However, this verification must not involve having having a list of valid cookies. Otherwise, an attacker could
a list of valid cookies. Otherwise, an attacker could potentially potentially consume arbitrary amounts of memory by repeatedly
consume arbitrary amounts of memory by repeatedly requesting cookies requesting cookies from a responder. The recommended way to
from a responder. The recommended way to generate a cookie, suggested generate a cookie, suggested by Phil Karn, is by having a single
by Phil Karn, is by having a single master key and compute a hash of master key and compute a hash of the secret and the initiator's
the secret and the initiator's address information. This cookie can address information. This cookie can be verified by recomputing the
be verified by recomputing the cookie value based on information in cookie value based on information in the third message and seeing
the third message and seeing if it matches. if it matches.
7.3.2. Endpoint Identities 7.3.2. Endpoint Identities
So far we have been rather vague about what sorts of endpoint identi- So far we have been rather vague about what sorts of endpoint
ties are used. In principle, there are three ways a peer might be identities are used. In principle, there are three ways a peer
identified: by a shared key, a pre-configured public key, and a might be identified: by a shared key, a pre-configured public key,
certificate. and a certificate.
7.3.2.1. Shared Key 7.3.2.1. Shared Key
In a shared key scheme, the peers share some symmetric key. This key In a shared key scheme, the peers share some symmetric key. This
is associated with a key identifier which is known to both parties. key is associated with a key identifier which is known to both
It is assumed that the party verifying that identity also has some parties. It is assumed that the party verifying that identity also
sort of table that indicates what sorts of traffic (e.g. what has some sort of table that indicates what sorts of traffic (e.g.
addresses) that identity is allowed to negotiate SAs for.
what addresses) that identity is allowed to negotiate SAs for.
7.3.2.2. Pre-configured public key 7.3.2.2. Pre-configured public key
A pre-configured public key scheme is the same as a shared key scheme A pre-configured public key scheme is the same as a shared key
except that the verifying party has the authenticating party's public scheme except that the verifying party has the authenticating
key instead of a shared key. party's public key instead of a shared key.
7.3.2.3. Certificate 7.3.2.3. Certificate
In a certificate scheme, authenticating party presents a certificate In a certificate scheme, authenticating party presents a
containing their public key. It's straightforward to establish that certificate containing their public key. It's straightforward to
that certificate matches the authentication data provided by the establish that that certificate matches the authentication data
peer. What's less straightforward is to determine whether a given provided by the peer. What's less straightforward is to determine
peer is entitled to negotiate for a given class of traffic. In the- whether a given peer is entitled to negotiate for a given class of
ory, one might be able to determine this from the name in the traffic. In theory, one might be able to determine this from the
certificate (e.g. the subject name contains an IP address that name in the certificate (e.g. the subject name contains an IP
matches the ostensible IP address). In practice, this is not clearly address that matches the ostensible IP address). In practice, this
specified in IKE and therefore not really interoperable. The more is not clearly specified in IKE and therefore not really
likely case at the moment is that there is a configuration table map- interoperable. The more likely case at the moment is that there is
ping certificates to policies, as with the other two authentication a configuration table mapping certificates to policies, as with the
schemes. other two authentication schemes.
References Normative References
There are no normative references for this document.
Informative References
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", [AH] Kent, S., and Atkinson, R., "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
Rescorla [Page 18] Internet-Draft Writing Protocol Models 5/2004
[CCID2] Floyd, S., Kohler, E., "Profile for DCCP Congestion Control ID 2: [CCID2] Floyd, S., Kohler, E., "Profile for DCCP Congestion Control ID 2:
TCP-like Congestion Control", draft-ietf-dccp-ccid2-04.txt, TCP-like Congestion Control", draft-ietf-dccp-ccid2-04.txt,
October 2003. October 2003.
[CCID3] Floyd, S., Kohler, E., Padhye, J. "Profile for DCCP Congestion [CCID3] Floyd, S., Kohler, E., Padhye, J. "Profile for DCCP Congestion
Control ID 3: TFRC Congestion Control", Control ID 3: TFRC Congestion Control",
draft-ietf-dccp-ccid3-05.txt, February 2004. draft-ietf-dccp-ccid3-05.txt, February 2004.
[DCCP] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion [DCCP] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion
Control Protocol (DCCP)", draft-ietf-dccp-spec-06.txt, Control Protocol (DCCP)", draft-ietf-dccp-spec-06.txt,
February 2004. February 2004.
[ECN] Ramakrishnan, K. Floyd, S., Black D., "The Addition of [ECN] Ramakrishnan, K. Floyd, S., Black D., "The Addition of
Explicit Congestion Notification (ECN) to IP", Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Rescorla [Page 20] Internet-Draft Writing Protocol Models 9/2004
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication [KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993. Service (V5)", RFC 1510, September 1993.
skipping to change at page 19, line ? skipping to change at page 21, line ?
[WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D. [WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D.
"HTTP Extensions for Distributed Authoring -- WEBDAV", "HTTP Extensions for Distributed Authoring -- WEBDAV",
RFC 2518, February 1999. RFC 2518, February 1999.
Security Considerations Security Considerations
This document does not define any protocols and therefore has no This document does not define any protocols and therefore has no
security considerations. security considerations.
Full Copyright Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2003). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Author's Address Author's Address
Eric Rescorla <ekr@rtfm.com> Eric Rescorla <ekr@rtfm.com>
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
Phone: (650)-320-8549 Phone: (650)-320-8549
Internet Architecture Board <iab@iab.org> Internet Architecture Board <iab@iab.org>
IAB IAB
Appendix A. IAB Members at the time of this writing Appendix A. IAB Members at the time of this writing
Bernard Aboba Bernard Aboba
 End of changes. 95 change blocks. 
421 lines changed or deleted 536 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/