doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc4101.txt b/doc/rfc/rfc4101.txt
new file mode 100644
index 0000000..f97b129
--- /dev/null
+++ b/doc/rfc/rfc4101.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                        E. Rescorla
+Request for Comments: 4101                                    RTFM, Inc.
+Category: Informational                                              IAB
+                                                               June 2005
+
+                        Writing Protocol Models
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The IETF process depends on peer review.  However, IETF documents are
+   generally written to be useful for implementors, not reviewers.  In
+   particular, while great care is generally taken to provide a complete
+   description of the state machines and bits on the wire, this level of
+   detail tends to get in the way of initial understanding.  This
+   document describes an approach for providing protocol "models" that
+   allow reviewers to quickly grasp the essence of a system.
+
+1.  Introduction
+
+   The IETF process depends on peer review.  However, in many cases, the
+   documents submitted for publication are extremely difficult to
+   review.  Because reviewers have only limited amounts of time, this
+   leads to extremely long review times, inadequate reviews, or both.
+   In our 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,
+   because they need to understand the protocol in any case; but it
+   dramatically increases the strain on reviewers.  Reviewers need to
+   get the big picture of the system and then focus on particular
+   points.  They simply do not have time to give the entire document the
+   attention an implementor would.
+
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 1]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   One way to reduce this load is to present the reviewer with a
+   MODEL -- a short description of the system in overview form.  This
+   provides the reviewer with the context to identify the important or
+   difficult pieces of the system and focus on them for review.  As a
+   side benefit, if the model is done first, it can be serve as an aid
+   to the detailed protocol design and a focus for early review, prior
+   to protocol completion.  The intention is that the model would either
+   be the first section of the protocol document or be a separate
+   document provided with the protocol.
+
+2.  The Purpose of a Protocol Model
+
+   A protocol model needs to answer three basic questions:
+
+   1. What problem is the protocol trying to achieve?
+   2. What messages are being transmitted and what do they mean?
+   3. What are the important, but unobvious, features of the protocol?
+
+   The basic idea is to provide enough information that the reader could
+   design a protocol which was roughly isomorphic to the protocol being
+   described.  Of course, this doesn't mean that the protocol would be
+   identical, but merely that it would share most important features.
+   For instance, the decision to use a KDC-based authentication model is
+   an essential feature of Kerberos [KERBEROS].  By contrast, the use of
+   ASN.1 is a simple implementation decision.  S-expressions -- or XML,
+   had it existed at the time -- would have served equally well.
+
+   The purpose of a protocol model is explicitly not to provide a
+   complete or alternate description of the protocol being discussed.
+   Instead, it is to provide a big picture overview of the protocol so
+   that readers can quickly understand the essential elements of how it
+   works.
+
+3.  Basic Principles
+
+   In this section we discuss basic principles that should guide your
+   presentation.
+
+3.1.  Less is more
+
+   Humans are only capable of keeping a very small number of pieces of
+   information in their head at once.  Because we're interested in
+   ensuring that people get the big picture, we have to dispense with a
+   lot of detail.  That's good, not bad.  The simpler you can make
+   things the better.
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 2]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+3.2.  Abstraction is good
+
+   A key technique for representing complex systems is to try to
+   abstract away pieces.  For instance, maps are better than photographs
+   for finding out where you want to go because they provide an
+   abstract, stylized, view of the information you're interested in.
+   Don't be afraid to compress multiple protocol elements into a single
+   abstract piece for pedagogical purposes.
+
+3.3.  A few well-chosen details sometimes help
+
+   The converse of the previous principle is that sometimes details 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
+   material in the abstract and then provide a concrete description of
+   one specific piece to bring it into focus.  Authors should focus on
+   the normal path.  Error cases and corner cases should only be
+   discussed where they help illustrate an important point.
+
+4.  Writing Protocol Models
+
+   Our experience indicates that it is easiest to grasp protocol models
+   when they are presented in visual form.  We recommend a presentation
+   format centered around a few key diagrams, with explanatory text for
+   each.  These diagrams should be simple and typically consist of
+   "boxes and arrows" -- boxes representing the major components, arrows
+   representing their relationships, and labels indicating important
+   features.
+
+   We recommend a presentation structured in three parts to match the
+   three questions mentioned in the previous sections.  Each part should
+   contain 1-3 diagrams intended to illustrate the relevant points.
+
+4.1.  Describe the problem you're trying to solve
+
+   The most critical task that a protocol model must perform is to
+   explain what the protocol is trying to achieve.  This provides
+   crucial context for understanding how the protocol works, and whether
+   it meets its goals.  Given the desired goals, an experienced reviewer
+   will usually have an idea of how they would approach the problem and,
+   thus, be able to compare that approach with the approach taken by the
+   protocol under review.
+
+   The "Problem" section of the model should start with a short
+   statement of the environments in which the protocol is expected to be
+   used.  This section should describe the relevant entities and the
+   likely scenarios under which they would participate in the protocol.
+   The Problem section should feature a diagram of the major
+
+
+
+Rescorla                     Informational                      [Page 3]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   communicating parties and their inter-relationships.  It is
+   particularly important to lay out the trust relationships between the
+   various parties, as these are often unobvious.
+
+4.1.1.  Example: STUN (RFC 3489)
+
+   STUN [STUN] is a UNilateral Self-Address Fixing (UNSAF) [UNSAF]
+   protocol that allows a machine located behind a NAT to determine what
+   its external apparent IP address is.  Although STUN provides a
+   complete and thorough description of the operation of the protocol,
+   it does not provide a brief, up-front overview suitable for a quick
+   understanding of its operation.  The rest of this section shows what
+   a suitable overview might look like.
+
+   Network Address Translation (NAT) makes it difficult to run a number
+   of classes of service from behind the NAT gateway.  This is
+   particularly a problem when protocols need to advertise address/port
+   pairs as part of the application layer protocol.  Although the NAT
+   can be configured to accept data destined for that port, address
+   translation means the address that the application knows about is not
+   the same as the one on which it is reachable.
+
+   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
+   server to send it some media.  In its Session Description Protocol
+   (SDP) [SDP] request it provides the IP address and port on which it
+   is listening.  However, unbeknownst to the client, a NAT is in the
+   way.  The NAT 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 media goes into a black hole.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 4]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+                   +-----------+
+                   |    SIP    |
+                   |  Server   |
+                   |           |
+                   +-----------+
+                        ^
+                        | [FROM: 198.203.2.1:8954]
+                        | [MSG: SEND MEDIA TO 10.0.10.5:6791]
+                        |
+                        |
+                   +-----------+
+                   |           |
+                   |    NAT    |
+     --------------+  Gateway  +----------------
+                   |           |
+                   +-----------+
+                        ^
+                        | [FROM: 10.0.10.5:6791]
+                        | [MSG: SEND MEDIA TO 10.0.10.5:6791]
+                        |
+                     10.0.10.5
+                   +-----------+
+                   |    SIP    |
+                   |  Client   |
+                   |           |
+                   +-----------+
+
+   The purpose of STUN is to allow clients to detect this situation and
+   determine the address mapping.  They can then place the appropriate
+   address in their application-level messages.  This is done by using
+   an external STUN server.  That server is able to determine the
+   translated address and tell the STUN client, as shown below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 5]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+                               +-----------+
+                               |   STUN    |
+                               |  Server   |
+                               |           |
+                               +-----------+
+                                   ^   |
+   [IP HDR FROM: 198.203.2.1:8954] |   | [IP HDR TO: 198.203.2.1:8954]
+   [MSG: WHAT IS MY ADDRESS?]      |   | [MSG: YOU ARE 198.203.2.1:8954]
+                                   |   v
+                               +-----------+
+                               |           |
+                               |    NAT    |
+                 --------------+  Gateway  +----------------
+                               |           |
+                               +-----------+
+                                  ^    |
+   [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]
+                                  |    v
+                                 10.0.10.5
+                               +-----------+
+                               |    SIP    |
+                               |  Client   |
+                               |           |
+                               +-----------+
+
+4.2.  Describe the protocol in broad overview
+
+   Once the problem has been described, the next task is to give a broad
+   overview of the protocol.  This means showing, either in "ladder
+   diagram" or "boxes and arrows" form, the protocol messages that flow
+   between the various networking agents.  This diagram should be
+   accompanied with explanatory text that describes the purpose of 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 section is not to provide a complete
+   description of the protocol, but to provide enough of a
+   map that a person reading the full protocol document can see
+   where each specific piece fits.
+
+   In certain cases, it may be helpful to provide a state machine
+   description of the behavior of network elements.  However, such
+   state machines should be kept as minimal as possible.  Remember that
+   the purpose is to promote high-level comprehension, not complete
+   understanding.
+
+
+
+Rescorla                     Informational                      [Page 6]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+4.2.1.  Example: DCCP
+
+   Datagram Congestion Control Protocol [DCCP] is a protocol for
+   providing datagram transport with network-friendly congestion
+   avoidance behavior.  The DCCP base protocol document is over 100
+   pages long and the congestion control mechanisms themselves are
+   separate.  Therefore, it is very helpful to have a an architectural
+   overview of DCCP that abstracts away the details.  The remainder of
+   this section is an attempt to do so.
+
+   NOTE: The author of this document was on the DCCP review team and
+   his experience with that document was one of the motivating factors
+   for this document.  Since the review, the DCCP authors have added
+   some overview material, some of which derives from earlier versions
+   of this document.
+
+   Although DCCP is datagram-oriented like UDP, it is stateful
+   like TCP.  Connections go through the following phases:
+
+      1. Initiation
+      2. Feature negotiation
+      3. Data transfer
+      4. Termination
+
+4.2.1.1.  Initiation
+
+   As with TCP, the initiation phase of DCCP involves a three-way
+   handshake, shown below.
+
+   Client                                      Server
+   ------                                      ------
+   DCCP-Request            ->
+   [Ports, Service,
+   Features]
+                           <-           DCCP-Response
+                                           [Features,
+                                              Cookie]
+   DCCP-Ack                ->
+   [Features,
+   Cookie]
+
+                           DCCP 3-way handshake
+
+   In the DCCP-Request message, the client tells the server the name of
+   the service it wants to talk to and the ports it wants to communicate
+   on.  Note that ports are not tightly bound to services, as they are
+   in TCP or UDP common practice.  It also starts feature negotiation.
+   For pedagogical reasons, we will present feature negotiation
+
+
+
+Rescorla                     Informational                      [Page 7]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   separately in the next section.  However, 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
+   willing to accept the connection and continues feature negotiation.
+   In order to prevent SYN flood-style DOS attacks, DCCP incorporates an
+   IKE-style cookie exchange.  The server can provide the client with a
+   cookie that contains all of 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
+   and returns the cookie to permit the server to complete its side of
+   the connection.  As indicated above, this message may also include
+   feature negotiation messages.
+
+4.2.1.2.  Feature Negotiation
+
+   In DCCP, feature negotiation is performed by attaching options to
+   other DCCP packets.  Thus, feature negotiation can be piggybacked on
+   any other DCCP message.  This allows feature negotiation during
+   connection initiation as well as 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 the Change and Confirm options.
+   There are four feature negotiation options in all: Change L, Confirm
+   L, Change R, and Confirm R.  The "L" options are sent by the feature
+   location, where the feature is maintained, and the "R" options are
+   sent by the feature remote.
+
+   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
+          ------                                        ------
+          Change R(CCID, 2) -->
+                                        <-- Confirm L(CCID, 2)
+                     * agreement that CCID/Server = 2 *
+
+          Change R(CCID, 3 4) -->
+                                   <-- Confirm L(CCID, 4, 4 2)
+                     * agreement that CCID/Server = 4 *
+
+
+
+
+Rescorla                     Informational                      [Page 8]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   In the second exchange, the client requests that the server use
+   either CCID 3 or CCID 4, with 3 preferred.  The server chooses 4 and
+   supplies its preference list, "4 2".
+
+   The Change L and Confirm R options are used for feature negotiations
+   that are initiated by the feature location.  In the following
+   example, the server requests that CCID/Server be set to 3 or 2 (with
+   3 being preferred), and the client agrees.
+
+          Client                                       Server
+          ------                                       ------
+                                      <-- Change L(CCID, 3 2)
+          Confirm R(CCID, 3, 3 2)  -->
+                     * agreement that CCID/Server = 3 *
+
+4.2.1.3.  Data Transfer
+
+   Rather than have a single congestion control regime, as in TCP, DCCP
+   offers a variety of negotiable congestion control regimes.  The DCCP
+   documents describe two congestion control regimes: additive increase,
+   multiplicative decrease (CCID-2 [CCID2]), and TCP-friendly rate
+   control (CCID-3 [CCID3]).  CCID-2 is intended for applications that
+   want maximum throughput.  CCID-3 is intended for real-time
+   applications that want smooth response to congestion.
+
+4.2.1.3.1.  CCID-2
+
+   CCID-2's congestion control is extremely similar to that of TCP.  The
+   sender maintains a congestion window and sends packets until that
+   window is full.  Packets are Acked by the receiver.  Dropped packets
+   and ECN [ECN] are used to indicate congestion.  The response to
+   congestion is to halve the congestion window.  One subtle difference
+   between DCCP and TCP is that the Acks in DCCP must contain the
+   sequence numbers of all received packets (within a given window), not
+   just the highest sequence number, as in TCP.
+
+4.2.1.3.2.  CCID-3
+
+   CCID-3 is an equation-based form of rate control, intended to provide
+   smoother response to congestion than CCID-2.  The sender maintains a
+   "transmit rate".  The receiver sends Ack packets that contain
+   information about the receiver's estimate of packet loss.  The sender
+   uses this information to update its transmit rate.  Although CCID-3
+   behaves somewhat differently than TCP in its short-term congestion
+   response, it is designed to operate fairly with TCP over the long
+   term.
+
+
+
+
+
+Rescorla                     Informational                      [Page 9]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+4.2.1.4.  Termination
+
+   Connection termination in DCCP is initiated by sending a Close
+   message.  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, keep the TIMEWAIT
+   state on the client.
+
+4.3.  Describe any important protocol features
+
+   The final section (if there is one) should contain an explanation of
+   any important protocol features that are not obvious from the
+   previous sections.  In the best case, all the important features of
+   the protocol would be obvious from the message flow.  However, this
+   isn't always the case.  This section is an opportunity for the author
+   to explain those features.  Authors should think carefully before
+   writing this section.  If there are no important points to be made,
+   they should not populate this section.
+
+   Examples of the kind of feature that belongs in this section include:
+   high-level security considerations, congestion control information,
+   and overviews of the algorithms that the network elements are
+   intended to follow.  For instance, if you have a routing protocol,
+   you might use this section to sketch out the algorithm that the
+   router uses to determine the appropriate routes from protocol
+   messages.
+
+4.3.1.  Example: WebDAV COPY and MOVE
+
+   The WebDAV standard [WEBDAV] is fairly terse, preferring to define
+   the required behaviors and let the reader work out the implications.
+   In some situations, explanatory material that details those
+   implications can help the reader understand the overall model.  The
+   rest of this section describes one such case.
+
+
+
+
+
+Rescorla                     Informational                     [Page 10]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   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 substitute for MOVE is problematic
+   because of the creation of the intermediate file.  Consider the case
+   where the user is approaching a quota boundary.  A COPY+DELETE should
+   be forbidden because it would temporarily exceed the quota.  However,
+   a 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
+   create 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
+   creation as the creation date property.  By contrast, the expectation
+   for MOVE is that the renamed file will have the same properties as
+   the original.
+
+5.  Formatting Issues
+
+   The requirement that Internet-Drafts and RFCs be renderable in ASCII
+   is a significant obstacle when writing the sort of graphics-heavy
+   document being described here.  Authors may find it more convenient
+   to do a separate protocol model document in Postscript or PDF and
+   simply make it available at review time -- though an archival version
+   would certainly be handy.
+
+6.  A Complete Example: Internet Key Exchange (IKE)
+
+   Internet Key Exchange (IKE) [IKE] is one of the most complicated
+   security protocols ever designed by the IETF.  Although the basic IKE
+   core is a fairly straightforward Diffie-Hellman-based handshake, this
+   can often be difficult for new readers to understand abstractly,
+   apart from the protocol details.  The remainder of this section
+   provides overview of IKE suitable for those new readers.
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 11]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+6.1.  Operating Environment
+
+   Internet key Exchange (IKE) [IKE] is a key establishment and
+   parameter negotiation protocol for Internet protocols.  Its primary
+   application is for establishing security associations (SAs) [IPSEC]
+   for IPsec AH [AH] and ESP [ESP].
+
+   +--------------------+                       +--------------------+
+   |                    |                       |                    |
+   |   +------------+   |                       |   +------------+   |
+   |   |    Key     |   |         IKE           |   |    Key     |   |
+   |   | Management | <-+-----------------------+-> | Management |   |
+   |   |  Process   |   |                       |   |  Process   |   |
+   |   +------------+   |                       |   +------------+   |
+   |         ^          |                       |         ^          |
+   |         |          |                       |         |          |
+   |         v          |                       |         v          |
+   |   +------------+   |                       |   +------------+   |
+   |   |   IPsec    |   |        AH/ESP         |   |   IPsec    |   |
+   |   |   Stack    | <-+-----------------------+-> |   Stack    |   |
+   |   |            |   |                       |   |            |   |
+   |   +------------+   |                       |   +------------+   |
+   |                    |                       |                    |
+   |                    |                       |                    |
+   |     Initiator      |                       |     Responder      |
+   +--------------------+                       +--------------------+
+
+   The general deployment model for IKE is shown above.  The IPsec
+   engines and IKE engines typically are separate modules.  When no
+   security association exists for a packet that needs to be processed
+   (either sent or received), the IPsec engine contacts the IKE engine
+   and asks it to establish an appropriate SA.  The IKE engine contacts
+   the appropriate peer and uses IKE to establish the SA.  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
+   keying material or adjust operating parameters, such as algorithms.
+
+6.1.1.  Initiator and Responder
+
+   Although IPsec is basically symmetrical, IKE is not.  The party who
+   sends the first message is called the INITIATOR.  The other party is
+   called the RESPONDER.  In the case of TCP connections, the INITIATOR
+   will typically be the peer doing the active open (i.e., the client).
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 12]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+6.1.2.  Perfect Forward Secrecy
+
+   One of the major concerns in IKE design was that traffic be protected
+   even if the keying material of the nodes was later compromised,
+   provided that the session in question had terminated and so the
+   session-specific keying material was gone.  This property is often
+   called Perfect Forward Secrecy (PFS) or back traffic protection.
+
+6.1.3.  Denial of Service Resistance
+
+   Because IKE allows arbitrary peers to initiate computationally-
+   expensive cryptographic operations, it potentially allows resource
+   consumption denial of service (DoS) attacks to be mounted against the
+   IKE engine.  IKE includes countermeasures designed to minimize this
+   risk.
+
+6.1.4.  Keying Assumptions
+
+   Because Security Associations are essentially symmetric, both sides
+   must, in general, be authenticated.  Because IKE needs to be able to
+   establish SAs between a broad range of peers with various kinds of
+   prior relationships, IKE supports a very flexible keying model.
+   Peers can authenticate via shared keys, digital signatures (typically
+   from keys vouched for by certificates), or encryption keys.
+
+6.1.5.  Identity Protection
+
+   Although IKE requires the peers to authenticate to each other, it was
+   considered desirable by the working group to provide some identity
+   protection for the communicating peers.  In particular, the peers
+   should be able to hide their identity from passive observers and one
+   peer should be able to require the author to authenticate before they
+   self-identity.  In this case, the designers chose to make the party
+   who speaks first (the INITIATOR) identify first.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 13]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+6.2.  Protocol Overview
+
+   At a very high level, there are two kinds of IKE handshake:
+
+   (1) Those that establish an IKE security association.
+   (2) Those that establish an AH or ESP security association.
+
+   When two peers that have never communicated before need to establish
+   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
+   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
+   E(SA,XXXX) is used to indicate that traffic is encrypted under a
+   given SA.
+
+   Initiator                               Responder
+   ---------                               ---------
+
+   Handshake MSG           ->                        \  Stage 1:
+                           <-         Handshake MSG   \ Establish IKE
+                                                      / SA (IKEsa)
+                          [...]                      /
+
+                                                     \  Stage 2:
+   E(IKEsa, Handshake MSG) ->                         \ Establish AH/ESP
+                           <- E(IKEsa, Handshake MSG) / SA
+
+                      The two kinds of IKE handshake
+
+   IKE terminology is somewhat confusing, referring under different
+   circumstances to "phases" and "modes".  For maximal clarity we will
+   refer to the Establishment of the IKE SA as "Stage 1" and the
+   Establishment of AH/ESP SAs as "Stage 2".  Note that it's quite
+   possible for there to be more than one Stage 2 handshake, once Stage
+   1 has been finished.  This might be useful for establishing multiple
+   AH/ESP SAs with different cryptographic properties.
+
+   The Stage 1 and Stage 2 handshakes are actually rather different,
+   because the Stage 2 handshake can, of course, assume that its traffic
+   is being protected with an IKE SA.  Accordingly, we will first
+   discuss Stage 1 and then Stage 2.
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 14]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+6.2.1.  Stage 1
+
+   There are a large number of variants of the IKE Stage 1 handshake,
+   necessitated by use of different authentication mechanisms.  However,
+   broadly speaking Stage 1 handshakes fall into one of two basic
+   categories: MAIN MODE, which provides identity protection and DoS
+   resistance, and AGGRESSIVE MODE, which does not.  We will cover MAIN
+   MODE first.
+
+6.2.1.1.  Main Mode
+
+   Main Mode is a six message (3 round trip) handshake, which offers
+   identity protection and DoS resistance.  An overview of the handshake
+   is below.
+
+   Initiator                                   Responder
+   ---------                                   ---------
+   CookieI, Algorithms      ->                          \  Parameter
+                            <-      CookieR, Algorithms /  Establishment
+
+   CookieR,
+   Nonce, Key Exchange      ->
+                            <-       Nonce, Key Exchange\  Establish
+                                                        /  Shared key
+
+   E(IKEsa, Auth Data)      ->
+                            <-       E(IKEsa, Auth data)\  Authenticate
+                                                        /      Peers
+
+                     IKE Main Mode handshake (Stage 1)
+
+   In the first round trip, the Initiator offers a set of algorithms and
+   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 parameters include a Diffie-Hellman (DH) group, which will be
+   used in the second round trip.
+
+   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, therefore, 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, PFS will be provided.
+
+
+
+Rescorla                     Informational                     [Page 15]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   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
+   demonstrate that it can receive traffic from you.  This foils blind
+   attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier
+   to track down attackers.  The cookie exchange serves this role in
+   IKE.  The Responder can verify that the Initiator supplied a valid
+   CookieR before doing the expensive DH key agreement.  This does not
+   totally eliminate DoS attacks, because an attacker who was willing to
+   reveal his location could still consume server resources; but it does
+   protect against a certain class of blind attack.
+
+   In the final round trip, the peers establish their identities.
+   Because 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 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:
+
+      (1) A set of algorithms for encryption of further IKE traffic.
+      (2) Traffic encryption and authentication keys.
+      (3) Mutual knowledge of the peer's identity.
+
+6.2.1.2.  Aggressive Mode
+
+   Although IKE Main Mode provides the required services, there was
+   concern that the large number of round trips required added,
+   excessive latency.  Accordingly, an Aggressive Mode was defined.
+   Aggressive mode packs more data into fewer messages, and thus reduces
+   latency.  However, it does not provide identity protection or
+   protection against DoS.
+
+   Initiator                                   Responder
+   ---------                                   ---------
+   Algorithms, Nonce,
+   Key Exchange,            ->
+                            <-         Algorithms, Nonce,
+                                  Key Exchange, Auth Data
+   Auth Data                ->
+
+                  IKE Aggressive Mode Handshake (Stage 1)
+
+
+
+Rescorla                     Informational                     [Page 16]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   After the first round trip, the peers have all the required
+   properties, but 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 because the Responder does the
+   DH key agreement without a round trip to the Initiator, there is no
+   DoS protection
+
+6.2.2.  Stage 2
+
+   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
+   merely 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
+      ---------                                    ---------
+      AH/ESP parameters,
+      Algorithms, Nonce,
+      Handshake Hash           ->
+                               <-          AH/ESP parameters,
+                                           Algorithms, Nonce,
+                                               Handshake Hash
+      Handshake Hash           ->
+
+                      The Basic IKE Quick Mode (Stage 2)
+
+   As with quick mode, the first two messages establish the algorithms
+   and parameters while the final message is a check over the previous
+   messages.  In this case, the parameters also include the transforms
+   to be applied to the traffic (AH or ESP) and the kinds of traffic
+   that are to be protected.  Note that there is no key exchange
+   information shown in these messages.
+
+   In this version of Quick Mode, the peers use the preexisting Stage 1
+   keying material to derive fresh keying material for traffic
+   protection (with the nonces to ensure freshness).  Quick mode also
+   allows for a new Diffie-Hellman handshake for per-traffic key PFS.
+   In that case, the first two messages shown above would also include
+   Key Exchange payloads, as shown below.
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 17]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+      Initiator                                    Responder
+      ---------                                    ---------
+      AH/ESP parameters,
+      Algorithms, Nonce,
+      Key Exchange,            ->
+      Handshake Hash
+                               <-          AH/ESP parameters,
+                                           Algorithms, Nonce,
+                                                Key Exchange,
+                                               Handshake Hash
+      Handshake Hash           ->
+
+                  A Variant of Quick Mode with PFS (Stage 2)
+
+6.3.  Other Considerations
+
+   There are a number of features of IKE that deserve special
+   consideration.  They are discussed here.
+
+6.3.1.  Cookie Generation
+
+   As mentioned previously, IKE uses cookies as a partial defense
+   against DoS attacks.  When the responder receives Main Mode message 3
+   containing the Key Exchange data and the cookie, it verifies that the
+   cookie is correct.  However, this verification must not involve
+   having a list of valid cookies.  Otherwise, an attacker could
+   potentially consume arbitrary amounts of memory by repeatedly
+   requesting cookies from a responder.  The recommended way to generate
+   a cookie, as suggested by Phil Karn, is to have a single master key
+   and compute a hash of the secret and the initiator's address
+   information.  This cookie can be verified by recomputing the cookie
+   value based on information in the third message, and seeing if it
+   matches.
+
+6.3.2.  Endpoint Identities
+
+   So far we have been rather vague about what kinds of endpoint
+   identities are used.  In principle, there are three ways a peer might
+   be identified: by a shared key, a pre-configured public key, or a
+   certificate.
+
+6.3.2.1.  Shared Key
+
+   In a shared key scheme, the peers share a symmetric key.  This key is
+   associated with a key identifier, which is known to both parties.  It
+   is assumed that the party verifying that identity also has a table
+   that indicates for which traffic (i.e., what addresses) that identity
+   is allowed to negotiate SAs.
+
+
+
+Rescorla                     Informational                     [Page 18]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+6.3.2.2.  Pre-Configured Public Key
+
+   A pre-configured public key scheme is the same as a shared key scheme
+   except that the verifying party has the authenticating party's public
+   key instead of a shared key.
+
+6.3.2.3.  Certificate
+
+   In a certificate scheme, the authenticating party presents a
+   certificate containing their public key.  It is straightforward to
+   establish that this certificate matches the authentication data
+   provided by the peer.  What is less straightforward is to determine
+   whether a given peer is entitled to negotiate for a given class of
+   traffic.  In theory, one might be able to determine this from the
+   name in the certificate (e.g., the subject name contains an IP
+   address that matches the ostensible IP address).  In practice, this
+   is not clearly specified in IKE and, therefore, is not really
+   interoperable.  Currently, it is likely that a configuration table
+   maps certificates to policies, as in the other two authentication
+   schemes.
+
+7.  Security Considerations
+
+   This document does not define any protocols and therefore has no
+   security issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 19]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+A.  Appendix: IAB Members at the Time of This Writing
+
+   Bernard Aboba
+   Harald Alvestrand
+   Rob Austein
+   Leslie Daigle
+   Patrik Falstrom
+   Sally Floyd
+   Jun-ichiro Itojun Hagino
+   Mark Handley
+   Bob Hinden
+   Geoff Huston
+   Eric Rescorla
+   Pete Resnick
+   Jonathan Rosenberg
+
+Normative References
+
+   There are no normative references for this document.
+
+Informative References
+
+   [AH]       Kent, S., and R. Atkinson, "IP Authentication Header", RFC
+              2402, November 1998.
+
+   [CCID2]    Floyd, S. and E. Kohler, "Profile for DCCP Congestion
+              Control ID 2: TCP-like Congestion Control", Work in
+              Progress, October 2003.
+
+   [CCID3]    Floyd, S., Kohler, E., and J. Padhye, "Profile for DCCP
+              Congestion Control ID 3: TFRC Congestion Control", Work in
+              Progress, February 2004.
+
+   [DCCP]     Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", Work in Progress,
+              November 2004.
+
+   [ECN]      Ramakrishnan, K. Floyd, S., and D. Black, "The Addition of
+              Explicit Congestion Notification (ECN) to IP", RFC 3168,
+              September 2001.
+
+   [ESP]      Kent, S. and R. Atkinson, "IP Encapsulating Security
+              Payload (ESP)", RFC 2406, November 1998.
+
+   [IKE]      Harkins, D. and D. Carrel, "The Internet Key Exchange
+              (IKE)", RFC 2409, November 1998.
+
+
+
+
+
+Rescorla                     Informational                     [Page 20]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+   [IPSEC]    Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
+
+   [KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510, September 1993.
+
+   [SDP]      Handley, M. and V. Jacobson, "SDP: Session Description
+              Protocol" RFC 2327, April 1998.
+
+   [STUN]     Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
+              "STUN - Simple Traversal of User Datagram Protocol (UDP)",
+              RFC 3489, March 2003.
+
+   [SYNFLOOD] CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing
+              Attacks <http://www.cert.org/advisories/CA-1996-21.html>,
+              September 19, 1996.
+
+   [UNSAF]    Daigle, L. and IAB, "IAB Considerations for UNilateral
+              Self-Address Fixing (UNSAF) Across Network Address
+              Translation", RFC 3424, November 2002.
+
+   [WEBDAV]   Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
+              Jensen, "HTTP Extensions for Distributed Authoring --
+              WEBDAV", RFC 2518, February 1999.
+
+Authors' Addresses
+
+   Eric Rescorla
+   RTFM, Inc.
+   2064 Edgewood Drive
+   Palo Alto, CA 94303
+
+   Phone: (650)-320-8549
+   EMail: ekr@rtfm.com
+
+
+   Internet Architecture Board
+   IAB
+
+   EMail: iab@iab.org
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 21]
+
+RFC 4101                Writing Protocol Models                June 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Rescorla                     Informational                     [Page 22]
+