draft-iab-model-00.txt   draft-iab-model-01.txt 
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
INTERNET-DRAFT IAB INTERNET-DRAFT IAB
draft-iab-model-00.txt October 2003 (Expires April 2004) draft-iab-model-01.txt May 2004 (Expires November 2004)
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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 3, line ? skipping to change at page 3, line ?
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 could
design a protocol which was roughly isomorphic to the protocol being design a protocol which was roughly isomorphic to the protocol being
described. This doesn't, of course, mean that the protocol would be described. This doesn't, of course, mean that the protocol would be
identical, but merely that it would share most important features. identical, but merely that it would share most important features.
For instance, the decision to use a KDC-based authentication model is For instance, the decision to use a KDC-based authentication model is
an essential feature of Kerberos [REF]. By constrast, the use of an essential feature of Kerberos [KERBEROS]. By constrast, the use of
ASN.1 is a simple implementation decision. S-expressions--or XML, had ASN.1 is a simple implementation decision. S-expressions--or XML, had
it existed at the time--would have served equally well. 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 ensuring
that people get the big picture, we therefore have to dispense with a that people get the big picture, we therefore have to dispense with a
lot of detail. That's good, not bad. The simpler you can make things lot of detail. That's good, not bad. The simpler you can make things
Rescorla [Page 2] Internet-Draft Writing Protocol Models 10/2003 Rescorla [Page 2] Internet-Draft Writing Protocol Models 5/2004
the better. 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 photographs
for finding out where you want to go because they provide an for finding out where you want to go because they provide an
abstract, stylized, view of the information you're interested in. abstract, stylized, view of the information you're interested in.
Don't be afraid to compress multiple protocol elements into a single Don't be afraid to compress multiple protocol elements into a single
skipping to change at page 3, line ? skipping to change at page 3, line ?
3.3. A few well-chosen detail sometimes helps 3.3. A few well-chosen detail sometimes helps
The converse of the the previous principle is that sometimes details The converse of the 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 when
given examples. Thus, it's often a good approach to talk about the given examples. Thus, it's often a good approach to talk about the
material in the abstract and then provide a concrete description of material in the abstract and then provide a concrete description of
one specific piece to bring it into focus. Authors should focus on one specific piece to bring it into focus. Authors should focus on
the normal path. Error cases and corner cases should only be dis- the normal path. Error cases and corner cases should only be dis-
cussed where they help illustrate some important point. cussed where they help illustrate some important point.
[QUESTION: Would it help to explicitly indicate use of these techniques
in the examples that follow?]
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 consist
of "boxes and arrows"--boxes representing the major components, of "boxes and arrows"--boxes representing the major components,
arrows representing their relationships and labels indicating impor- arrows representing their relationships and labels indicating impor-
tant features. tant 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 should
contain 1-3 diagrams intended to illustrate the relevant points. 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
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 perform
is to explain what the protocol is trying to achieve. This provides is to explain what the protocol is trying to achieve. This provides
crucial context for understanding how the protocol works and whether crucial context for understanding how the protocol works and whether
it meets its goals. Given the desired goals, in most cases an it meets its goals. Given the desired goals, in most cases an experi-
enced reviewer will have an idea of how they would approach the prob-
lem and be able to compare that to the approach taken by the protocol
experienced reviewer will have an idea of how they would approach the under review.
problem and be able to compare that to the approach taken by the pro-
tocol 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 be
used. This section should describe the relevant entities and the 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 communi-
cating parties and their inter-relationships. It is particularly cating parties and their inter-relationships. It is particularly
important to lay out the trust relationships between the various par- important to lay out the trust relationships between the various par-
ties as these are often un-obvious. ties as these are often un-obvious.
skipping to change at page 5, line ? skipping to change at page 5, line ?
of classes of service from behind the NAT gateway. This is a particu- of classes of service from behind the NAT gateway. This is a particu-
lar problem when protocols need to advertise address/port pairs as lar problem when protocols need to advertise address/port pairs as
part of the application layer protocol. Although the NAT can be con- part of the application layer protocol. Although the NAT can be con-
figured to accept data destined for that port, address translation figured to accept data destined for that port, address translation
means that the address that the application knows about is not the means that the address that the application knows about is not the
same as the one that it is reachable on. 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) [REF] request it provides the IP and port on which it is lis- (SDP) [SDP] request it provides the IP and port on which it is lis-
tening. However, unbeknownst to the client, a NAT is in the way. It tening. However, unbeknownst to the client, a NAT is in the way. It
translates the IP address in the header, but unless it is SIP aware, translates the IP address in the header, but unless it is SIP aware,
it doesn't change the address in the request. The result is that the it doesn't change the address in the request. The result is that the
media goes into a black hole. media goes into a black hole.
Rescorla [Page 4] Internet-Draft Writing Protocol Models 10/2003 Rescorla [Page 4] Internet-Draft Writing Protocol Models 5/2004
+-----------+ +-----------+
| SIP | | SIP |
| Server | | Server |
| | | |
+-----------+ +-----------+
^ ^
| [FROM: 198.203.2.1:8954] | [FROM: 198.203.2.1:8954]
| [MSG: SEND MEDIA TO 10.0.10.5:6791] | [MSG: SEND MEDIA TO 10.0.10.5:6791]
| |
skipping to change at page 5, line ? skipping to change at page 5, line ?
| [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 is to allow clients to detect this situation and The purpose of STUN [STUN] is to allow clients to detect this situation
determine the address mapping. They can then place the appropriate and determine the address mapping. They can then place the appropriate
address in their application-level messages. This is done by making use address in their application-level messages. This is done by making use
of an external STUN server. That server is able to determine the trans- of an external STUN server. That server is able to determine the trans-
lated address and tell the STUN client, as shown below. lated address and tell the STUN client, as shown below.
+-----------+ +-----------+
| STUN | | STUN |
| Server | | Server |
| | | |
+-----------+ +-----------+
^ | ^ |
skipping to change at page 7, line ? skipping to change at page 7, line ?
and the MAJOR data elements. and the MAJOR data elements.
This section SHOULD NOT contain detailed descriptions of the protocol This section SHOULD NOT contain detailed descriptions of the protocol
messages or of each data element. In particular, bit diagrams, ASN.1 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- 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- 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 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 reading the full protocol document can see where each specific piece
fits. fits.
Rescorla [Page 6] Internet-Draft Writing Protocol Models 10/2003 Rescorla [Page 6] Internet-Draft Writing Protocol Models 5/2004
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 state
machines should be kept as minimal as possible. Remember that the machines should be kept as minimal as possible. Remember that the
purpose is to promote high-level comprehension, not complete under- purpose is to promote high-level comprehension, not complete under-
standing. standing.
4.4. Example: DCCP 4.4. Example: DCCP
Although DCCP is datagram oriented like UDP, it is stateful like TCP. Although DCCP [DCCP] is datagram oriented like UDP, it is stateful
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 hand-
shake, shown in Figure 1. shake, shown in Figure 1.
Client Server Client Server
skipping to change at page 9, line ? skipping to change at page 9, line ?
Client Server Client Server
------ ------ ------ ------
Change(CC,3,4) -> Change(CC,3,4) ->
<- Prefer(CC,1,2,5) <- Prefer(CC,1,2,5)
Change(CC,5) -> Change(CC,5) ->
<- Confirm(CC,5) <- Confirm(CC,5)
In this exchange, the client requests CC values 3 and 4. Note that 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 the client can offer multiple values. The server doesn't like any of
Rescorla [Page 8] Internet-Draft Writing Protocol Models 10/2003 Rescorla [Page 8] Internet-Draft Writing Protocol Models 5/2004
these and offers 1, 2, and 5. The client chooses 5 and the server these and offers 1, 2, and 5. The client chooses 5 and the server
agrees. agrees.
Since features are one-sided, if a party wants to change one of his Since features are one-sided, if a party wants to change one of his
own options, he must ask the peer to issue a Change. This is done own options, he must ask the peer to issue a Change. This is done
using a Prefer, as shown below, where the client gets the server to using a Prefer, as shown below, where the client gets the server to
request that the client change the value of CC to 3. request that the client change the value of CC to 3.
Client Server Client Server
------ ------ ------ ------
Prefer(CC,3,4) -> Prefer(CC,3,4) ->
<- Change(CC,3) <- Change(CC,3)
Confirm(CC,3) -> Confirm(CC,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 increase,
multiplicative decrease (CCID-2 [REF]) and TCP-friendly rate control multiplicative decrease (CCID-2 [CCID2]) and TCP-friendly rate con-
(CCID-3 [REF]). CCID-2 is intended for applications which want maxi- trol (CCID-3 [CCID3]). CCID-2 is intended for applications which want
mum throughput. CCID-3 is intended for real-time applications which maximum throughput. CCID-3 is intended for real-time applications
want smooth response to congestion. 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. The
sender maintains a congestion window and sends packets until that sender maintains a congestion window and sends packets until that
window is full. Packets are Acked by the receiver. Dropped packets window is full. Packets are Acked by the receiver. Dropped packets
and ECN [REF] are used to indicate congestion. The response to con- and ECN [ECN] are used to indicate congestion. The response to con-
gestion is to halve the congestion window. One subtle diference gestion is to halve the congestion window. One subtle diference
between DCCP and TCP is that the Acks in DCCP must contain the between DCCP and TCP is that the Acks in DCCP must contain the
sequence numbers of all received packets (within a given window) not sequence numbers of all received packets (within a given window) not
just the highest sequence number as in TCP. 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 to
provide smoother response to congestion than CCID-2. The sender main- provide smoother response to congestion than CCID-2. The sender main-
tains a "transmit rate". The receiver sends ACK packets which also tains a "transmit rate". The receiver sends ACK packets which also
contain information about the receiver's estimate of packet loss. The contain information about the receiver's estimate of packet loss. The
sender uses this information to update its transmit rate. Although sender uses this information to update its transmit rate. Although
CCID-3 behaves somewhat differently from TCP in its short term con- CCID-3 behaves somewhat differently from TCP in its short term con-
gestion response, it is designed to operate fairly with TCP over the gestion response, it is designed to operate fairly with TCP over the
long term. long term.
4.4.4. Termination 4.4.4. Termination
[Still working on this one]. Connection termination in DCCP is initiated by sending a Close mes-
sage. Either side can send a Close message. The peer then responds
with a Reset message, at which point the connection is closed. The
side that sent the Close message must quietly preserve the socket in
TIMEWAIT state for 2MSL.
Client Server
------ ------
Close ->
<- Reset
[Remains in TIMEWAIT]
Note that the server may wish to close the connection but not remain
in TIMEWAIT (e.g., due to a desire to minimize server-side state.) In
order to accomplish this, the server can elicit a Close from the
client by sending a CloseReq message and thus keeping the 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 of
any important protocol features which are not obvious from the previ- any important protocol features which are not obvious from the previ-
ous sections. In the best case, all the important features of the ous sections. In the best case, all the important features of the
protocol would be obvious from the message flow. However, this isn't protocol would be obvious from the message flow. However, this isn't
always the case. This section is an opportunity for the author to always the case. This section is an opportunity for the author to
explicate those features. Authors should think carefully before writ- explicate those features. Authors should think carefully before writ-
ing this section. If there are no important points to be made they ing this section. If there are no important points to be made they
should not populate this section. 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 include:
high-level security considerations, congestion control information high-level security considerations, congestion control information
and overviews of the algorithms that the network elements are and overviews of the algorithms that the network elements are
intended to follow. For instance, if you have a routing protocol you intended to follow. For instance, if you have a routing protocol you
might use this section to sketch out the algorithm that the router might use this section to sketch out the algorithm that the router
uses to determine the appropriate routes from protocol messages. uses to determine the appropriate routes from protocol messages.
5.1. Example: XXX 5.1. Example: WebDAV COPY and MOVE
[TODO: Suggested targets welcome] WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While
a MOVE can be thought of as a COPY followed by DELETE, 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
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 to cre-
ate new ones--this is unusual in ordinary filesystems but nothing
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
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-
ation as the creation date property. By contrast, the expectation for
move is that the renamed file will have the same 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 ASCII
is a significant obstacle when writing the sort of graphics-heavy is a significant obstacle when writing the sort of graphics-heavy
document being described here. Authors may find it more convenient to document being described here. Authors may find it more convenient to
do a separate protocol model document in Postscript or PDF and simply do a separate protocol model document in Postscript or PDF and simply
make it available at review time--though an archival version would make it available at review time--though an archival version would
certainly be handy. 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) [REF] is a key establishment and parame- Internet key Exchange (IKE) [IKE] is a key establishment and parame-
ter negotiation protocol for Internet protocols. Its primary applica- ter negotiation protocol for Internet protocols. Its primary applica-
tion is for establishing security associations (SAs) [REF] for IPsec tion is for establishing security associations (SAs) [IPSEC] for
AH [REF] and ESP [REF]. IPsec AH [AH] and ESP [ESP].
Rescorla [Page 10] Internet-Draft Writing Protocol Models 10/2003
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | 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 ?
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 protected
even if they keying material of the nodes was later compromised, pro- even if they keying material of the nodes was later compromised, pro-
vided that the session in question had terminated and so the session- vided that the session in question had terminated and so the session-
specific keying material was gone. This property is often called PER- specific keying material was gone. This property is often called PER-
FECT FORWARD SECRECY (PFS) or BACK TRAFFIC PROTECTION. FECT FORWARD SECRECY (PFS) or BACK TRAFFIC PROTECTION.
Rescorla [Page 12] Internet-Draft Writing Protocol Models 5/2004
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 expen-
sive cryptographic operations, it potentially allows resource con- sive cryptographic operations, it potentially allows resource con-
sumption denial of service attacks to be mounted against the IKE sumption 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
skipping to change at page 13, line ? skipping to change at page 15, line ?
(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 establish
an AH/ESH SA, they must first establish an IKE SA. This allows them an AH/ESH SA, they must first establish an IKE SA. This allows them
to exchange an arbitrary amount of protected IKE traffic. They can to exchange an arbitrary amount of protected IKE traffic. They can
then use that SA to do a second handshake to establish SAs for AH and then use that SA to do a second handshake to establish SAs for AH and
ESP. This process is shown in schematic form below. The notation ESP. This process is shown in schematic form below. The notation
E(SA,XXXX) is used to indicate that traffic is encrypted under a E(SA,XXXX) is used to indicate that traffic is encrypted under a
given SA. given SA.
Rescorla [Page 12] Internet-Draft Writing Protocol Models 10/2003
Initiator Responder Initiator Responder
--------- --------- --------- ---------
Handshake MSG -> \ Handshake MSG -> \
<- Handshake MSG \ Establish IKE <- Handshake MSG \ Establish IKE
/ SA (IKEsa) / SA (IKEsa)
[...] / [...] /
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA <- E(IKEsa, Handshake MSG) / SA
skipping to change at page 15, line ? skipping to change at page 15, line ?
broadly speaking they fall into one of two basic categories: MAIN broadly speaking they fall into one of two basic categories: MAIN
MODE, which provides identity protection and DoS resistance, and MODE, which provides identity protection and DoS resistance, and
AGGRESSIVE MODE, which does not. We will cover MAIN MODE first. 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 handshake
is below. 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
skipping to change at page 15, line ? skipping to change at page 17, line ?
eliminate DoS attacks, since an attacker who was willing to reveal eliminate DoS attacks, since an attacker who was willing to reveal
his location could still consume server resources, but it does pro- his location could still consume server resources, but it does pro-
tect against a certain class of blind attack. tect against a certain class of blind attack.
In the final round trip, the peers establish their identities. Since In the final round trip, the peers establish their identities. Since
they share an (unauthenticated) key, they can send their identities they share an (unauthenticated) key, they can send their identities
encrypted, thus providing identity protection from eavesdroppers. The encrypted, thus providing identity protection from eavesdroppers. The
exact method of proving identity depends on what form of credential exact method of proving identity depends on what form of credential
is being used (signing key, encryption key, shared secret, etc.), but is being used (signing key, encryption key, shared secret, etc.), but
Rescorla [Page 14] Internet-Draft Writing Protocol Models 10/2003
in general you can think of it as a signature over some subset of the 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 handshake messages. So, each side would supply its certificate and
then sign using the key associated with that certificate. If shared 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. keys are used, the authentication data would be a key id and a MAC.
Authentication using public key encryption follows similar principles Authentication using public key encryption follows similar principles
but is more complicated. Refer to the IKE document for more details. 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.
skipping to change at page 17, line ? skipping to change at page 17, line ?
key agreement without a round trip to the Initiator, there is no DoS key agreement without a round trip to the Initiator, there is no DoS
protection protection
7.2.2. Stage 2 7.2.2. Stage 2
Stage 1 on its own isn't very useful. The purpose of IKE, after all, 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 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 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. used for this purpose. The basic Stage 2 handshake is shown below.
Rescorla [Page 16] Internet-Draft Writing Protocol Models 5/2004
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 ->
skipping to change at page 17, line ? skipping to change at page 19, line ?
There are a number of features of IKE that deserve special considera- There are a number of features of IKE that deserve special considera-
tion. These are discussed here. tion. 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 3
containing the Key Exchange data and the cookie, it verifies that the containing the Key Exchange data and the cookie, it verifies that the
Rescorla [Page 16] Internet-Draft Writing Protocol Models 10/2003
cookie is correct. However, this verification must not involve having cookie is correct. However, this verification must not involve having
a list of valid cookies. Otherwise, an attacker could potentially a list of valid cookies. Otherwise, an attacker could potentially
consume arbitrary amounts of memory by repeatedly requesting cookies consume arbitrary amounts of memory by repeatedly requesting cookies
from a responder. The recommended way to generate a cookie, suggested from a responder. The recommended way to generate a cookie, suggested
by Phil Karn, is by having a single master key and compute a hash of by Phil Karn, is by having a single master key and compute a hash of
the secret and the initiator's address information. This cookie can the secret and the initiator's address information. This cookie can
be verified by recomputing the cookie value based on information in be verified by recomputing the cookie value based on information in
the third message and seeing if it matches. the third message and seeing if it matches.
7.3.2. Endpoint Identities 7.3.2. Endpoint Identities
skipping to change at page 18, line 4 skipping to change at page 19, line ?
peer is entitled to negotiate for a given class of traffic. In the- peer is entitled to negotiate for a given class of traffic. In the-
ory, one might be able to determine this from the name in the ory, one might be able to determine this from the name in the
certificate (e.g. the subject name contains an IP address that certificate (e.g. the subject name contains an IP address that
matches the ostensible IP address). In practice, this is not clearly matches the ostensible IP address). In practice, this is not clearly
specified in IKE and therefore not really interoperable. The more specified in IKE and therefore not really interoperable. The more
likely case at the moment is that there is a configuration table map- likely case at the moment is that there is a configuration table map-
ping certificates to policies, as with the other two authentication ping certificates to policies, as with the other two authentication
schemes. schemes.
References References
[AH] Kent, S., and Atkinson, R., "IP Authentication Header",
RFC 2402, November 1998.
[TODO] Rescorla [Page 18] Internet-Draft Writing Protocol Models 5/2004
[CCID2] Floyd, S., Kohler, E., "Profile for DCCP Congestion Control ID 2:
TCP-like Congestion Control", draft-ietf-dccp-ccid2-04.txt,
October 2003.
[CCID3] Floyd, S., Kohler, E., Padhye, J. "Profile for DCCP Congestion
Control ID 3: TFRC Congestion Control",
draft-ietf-dccp-ccid3-05.txt, February 2004.
[DCCP] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion
Control Protocol (DCCP)", draft-ietf-dccp-spec-06.txt,
February 2004.
[ECN] Ramakrishnan, K. Floyd, S., Black D., "The Addition of
Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[SDP] Handley, M., Jacobson, V., "SDP: Session Description Protocol"
RFC 2327, April 1998.
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R.,
"STUN - Simple Traversal of User Datagram Protocol (UDP)",
RFC 3489, March 2003.
[WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D.
"HTTP Extensions for Distributed Authoring -- WEBDAV",
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.
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
skipping to change at page 18, line 32 skipping to change at page 20, line 22
Appendix A. IAB Members at the time of this writing Appendix A. IAB Members at the time of this writing
Bernard Aboba Bernard Aboba
Harald Alvestrand Harald Alvestrand
Rob Austein Rob Austein
Leslie Daigle Leslie Daigle
Patrik Falstrom Patrik Falstrom
Sally Floyd Sally Floyd
Jun-ichiro Itojun Hagino Jun-ichiro Itojun Hagino
Mark Handley Mark Handley
Bob Hinden
Geoff Huston Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla Eric Rescorla
Mike St. Johns Pete Resnick
Jonathon Rosenberg
 End of changes. 33 change blocks. 
41 lines changed or deleted 117 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/