RFC 4101
Writing Protocol Models
Writing Protocol Models 🎀
okay bestie, this is RFC 4101, called Writing Protocol Models 💅 It's from the Network Working Group and was written by E. Rescorla of RTFM, Inc. and the IAB ✨ It's Informational, dated June 2005 🦋 The header doesn't list any RFCs it obsoletes or updates, so it stands on its own 🧚 This is part 1 of 4, so more is coming 💜
Status of This Memo 🌸
this memo just provides info for the Internet community 📚 It does not specify an Internet standard of any kind, so no vibes of being a rule, lol. Distribution of this memo is unlimited 🔓
Copyright Notice 💜
Copyright (C) The Internet Society (2005).Abstract 🌈
the IETF process runs on peer review, and that's iconic 👑 But IETF docs are usually written to be useful for implementors, not reviewers 🙈 Like, the people writing them are super careful about state machines and bits on the wire, but all that detail tends to get in the way of first understanding 😭 This document describes an approach for making protocol "models" so reviewers can quickly grasp the essence of a system 🔥
1. Introduction 💖
the IETF process depends on peer review, fr fr ✨ But honestly, a lot of submitted docs are extremely hard to review 💀 Reviewers only have so much time, so the reviews end up taking forever, being inadequate, or both 😩 In the author's view, a big part of the problem is that most docs skip presenting an architectural model for how the protocol operates 🧚 They just describe the protocol and let the reviewer figure it out, which is giving "good luck" 🙃
That's fine when you're documenting for implementors, because they have to understand the protocol anyway 🫶 But it seriously increases the strain on reviewers 😭 Reviewers need the big picture first and then can zoom into particular points 🔍 They simply do not have time to give the whole doc the attention an implementor would 💅
One way to lighten this load is to hand the reviewer a MODEL, which is a short description of the system in overview form 🦋 That gives them the context to spot the important or tricky pieces and focus there 🎯 As a bonus, if you write the model first, it can serve as an aid to the detailed protocol design and a focus for early review, before the protocol is finished 🌷 The idea is that the model would either be the first section of the protocol document or a separate doc shipped along with the protocol 📎
2. The Purpose of a Protocol Model 🎀
a protocol model needs to answer three basic questions, and they're non-negotiable 😤
- What problem is the protocol trying to achieve?
- What messages are being transmitted and what do they mean?
- What are the important, but unobvious, features of the protocol?
the basic idea is to give enough info that the reader could design a protocol that's roughly isomorphic to the one being described 🧩 Obviously that doesn't mean the protocol would be identical, just that it would share most of the important features ✨ For example, going with a KDC-based authentication model is an essential feature of Kerberos [KERBEROS] 👑 By contrast, using 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 give a complete or alternate description of the protocol 🚫 It's to give a big picture overview so readers can quickly understand the essential elements of how it works 🌈
3. Basic Principles 🍓
in this section we talk about basic principles that should guide your presentation 🧠
3.1. Less is more 🫧
humans can only keep a very small number of pieces of info in their head at once 🧠💀 Because we want people to get the big picture, we have to dispense with a lot of detail 🗑️ And that's good, not bad 🥰 The simpler you can make things, the better 💖
3.2. Abstraction is good 🦋
a key technique for representing complex systems is to abstract away pieces 🗺️ Like, maps are better than photographs for finding out where you want to go, because they give you an abstract, stylized view of the info you care about 😌 Don't be afraid to squish multiple protocol elements into a single abstract piece for teaching purposes 🎓
3.3. A few well-chosen details sometimes help ✨
the converse of the previous principle is that sometimes details help bring a description into focus 🔍 Lots of people work better with examples, so it's often a good move to talk about the material in the abstract and then give 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 🌷
in our experience, models are easiest to grasp when they're presented visually 🎨 The recommended format is centered around a few key diagrams, each with explanatory text 📊 These diagrams should be simple and typically be "boxes and arrows" 📦➡️ boxes for the major components, arrows for how they relate, and labels for the important features 🏷️
we recommend a presentation structured in three parts to match the three questions from earlier sections 🧁 Each part should contain 1-3 diagrams that illustrate the relevant points 🖼️
4.1. Describe the problem you're trying to solve 🎯
the most critical job of a protocol model is to explain what the protocol is trying to achieve 👑 This gives crucial context for understanding how the protocol works and whether it meets its goals 🤔 Given the goals, an experienced reviewer will usually have an idea of how they'd approach the problem, so they can compare that approach with the one the protocol under review takes 🧐
the "Problem" section of the model should start with a short statement of the environments where the protocol is expected to be used 🏡 It should describe the relevant entities and the likely scenarios in which they'd take part in the protocol 🎭 The Problem section should feature a diagram of the major communicating parties and how they relate to each other 🖼️ It's especially important to lay out the trust relationships between the various parties, because those are often unobvious 🚨
4.1.1. Example: STUN (RFC 3489) 💫
STUN [STUN] is a UNilateral Self-Address Fixing (UNSAF) [UNSAF] protocol that lets a machine behind a NAT figure out what its external apparent IP address is 🌐 Although STUN gives a complete and thorough description of how it works, it doesn't give a brief, up-front overview for a quick understanding 😅 So the rest of this section shows what a suitable overview might look like 🌟
Network Address Translation (NAT) makes it hard to run a bunch of classes of service from behind the NAT gateway 🚧 This is a real problem when protocols need to advertise address/port pairs as part of the application layer protocol 📮 The NAT can be set up to accept data headed for that port, but address translation means the address the application knows about isn't the same one it's reachable on 🙃
check out the scenario in the figure below 👀 A SIP client is starting a session with a SIP server and wants the server to send it some media 🎶 In its Session Description Protocol (SDP) [SDP] request, it gives the IP address and port it's listening on 🎧 But unbeknownst to the client, a NAT is in the way 😱 The NAT translates the IP address in the header, but unless it's SIP aware, it doesn't change the address in the request 💔 Result? The media goes into a black hole 🕳️💀
+-----------+
| 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 let clients detect this situation and determine the address mapping 🕵️♀️ Then they can put the right address in their application-level messages 📝 This is done by using an external STUN server 🛰️ That server can work out the translated address and tell the STUN client, as shown below 🫶
+-----------+
| 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 is described, the next job 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 🪜 The diagram should come with explanatory text describing 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 point of this section isn't to fully describe the protocol, it's to give enough of a map that a person reading the full protocol doc can see where each specific piece fits 🧭
in certain cases it may be helpful to describe the behavior of network elements with a state machine 🔁 But state machines should be kept as minimal as possible 🤏 Remember that the purpose is to promote high-level comprehension, not complete understanding 🧠💖
more parts are coming, so stay tuned 🧚💜
4.2.1. Example: DCCP
Okay bestie, let's talk DCCP 💖 The Datagram Congestion Control Protocol [DCCP] is a protocol for datagram transport with network-friendly congestion avoidance behavior 🦋 The DCCP base protocol document is over 100 pages long 😭 and the congestion control mechanisms are their own separate docs. So an architectural overview that skips the nitty-gritty is literally so helpful, and that's what this section is trying to be ✨
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 one 🙈 Since the review, the DCCP authors have added some overview material, and some of it comes from earlier versions of this document 🫶
Although DCCP is datagram-oriented like UDP, it's stateful like TCP 💅 Connections go through these phases:
- Initiation
- Feature negotiation
- Data transfer
- Termination
4.2.1.1. Initiation
Just like TCP, the initiation phase of DCCP is a three-way handshake 🤝 Here's how it goes:
Client Server
------ ------
DCCP-Request ->
[Ports, Service,
Features]
<- DCCP-Response
[Features,
Cookie]
DCCP-Ack ->
[Features,
Cookie]
DCCP 3-way handshakeSo in the DCCP-Request, the client tells the server the name of the service it wants to talk to, plus the ports it wants to use 📮 Ports aren't tightly bound to services here, unlike what you get with TCP or UDP common practice, so that's a fun difference 🎀 This message also kicks off feature negotiation. For pedagogical reasons, we'll cover feature negotiation separately in the next section, but the early bits of it actually happen at the same time as initiation, so keep that in mind 🧚
In the DCCP-Response, the server basically says "yep, I'm down to accept this connection" and keeps feature negotiation going 🌸 To stop SYN flood-style DOS attacks 😤, DCCP uses an IKE-style cookie exchange. The server can hand the client a cookie that holds all of the negotiation state, and the client must echo that cookie back in the DCCP-Ack. Because the cookie carries everything, the server doesn't have to keep state on its end, which is so iconic 👑
In the DCCP-Ack, the client acknowledges the DCCP-Response and returns the cookie so the server can finish its side of the connection 💜 Like we said above, this message may also carry feature negotiation messages.
4.2.1.2. Feature Negotiation
In DCCP, feature negotiation happens by attaching options to other DCCP packets 🦋 So it can be piggybacked on any other DCCP message! That means feature negotiation can happen during connection initiation and also during data flow. Main character energy 💅
Somewhat unusually (but honestly iconic), DCCP features are one-sided 🌈 That means it's totally possible to have one congestion control regime for data going from client to server and a different one for data going 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, which is where the feature is maintained. 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 answer with a Confirm L, which means "I've changed it." Some features let a Change R option 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 *In the second exchange, the client asks the server to use either CCID 3 or CCID 4, with 3 preferred 🤔 The server picks 4 and sends back its own preference list, "4 2". Easy peasy 🎀
The Change L and Confirm R options are for feature negotiations that the feature location starts. In the next example, the server asks that CCID/Server be set to 3 or 2 (with 3 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
Instead of having one single congestion control regime like TCP does, DCCP offers a bunch of negotiable congestion control regimes 🌈 The DCCP documents describe two of them: additive increase, multiplicative decrease (CCID-2 [CCID2]), and TCP-friendly rate control (CCID-3 [CCID3]). CCID-2 is meant for apps that want maximum throughput 🚀 CCID-3 is meant for real-time apps that want a smooth response to congestion 🧈
4.2.1.3.1. CCID-2
CCID-2's congestion control is extremely similar to TCP's, so if you know TCP, you're already halfway there 🙌 The sender keeps a congestion window and sends packets until that window is full. The receiver Acks the packets. Dropped packets and ECN [ECN] are used to signal congestion. The response to congestion is to halve the congestion window 📉
One subtle difference from TCP: the Acks in DCCP must contain the sequence numbers of all received packets (within a given window), not just the highest sequence number like in TCP 👀
4.2.1.3.2. CCID-3
CCID-3 is an equation-based form of rate control, and it's meant to respond to congestion more smoothly than CCID-2 does 🦋 The sender keeps a "transmit rate." The receiver sends Ack packets that carry its estimate of packet loss, and the sender uses that info to update its transmit rate. CCID-3 acts a bit differently from TCP in its short-term congestion response, but it's designed to play fair with TCP over the long term 🫶
4.2.1.4. Termination
Connection termination in DCCP starts with sending a Close message 👋 Either side can send one. The peer then responds with a Reset message, and that's when the connection closes. The side that sent the Close message must quietly keep the socket in TIMEWAIT state for 2MSL 🌙
Client Server
------ ------
Close ->
<- Reset
[Remains in TIMEWAIT]Also, the server might want to close the connection without sticking around in TIMEWAIT (for example, because it wants to keep server-side state to a minimum) 🧚 To pull that off, the server can make the client send a Close by sending a CloseReq message. That way, the TIMEWAIT state ends up on the client instead 💅
4.3. Describe any important protocol features
The final section (if there is one) should explain any important protocol features that aren't obvious from the previous sections 📚 In the best case, all the important features are obvious from the message flow, but that's not always how it goes 😅 This section is the author's chance to explain those features. Authors should think carefully before writing it. If there aren't any important points to make, they shouldn't fill this section up 🙅♀️
Examples of the kind of feature that belongs here include high-level security considerations, congestion control information, and overviews of the algorithms that network elements are meant to follow ⭐ For instance, if you've got a routing protocol, you might use this section to sketch out the algorithm the router uses to work out the right routes from protocol messages 🗺️
4.3.1. Example: WebDAV COPY and MOVE
WebDAV [WEBDAV] is pretty terse 🙃 It likes to define the required behaviors and let the reader work out the implications. Sometimes explanatory material that spells out those implications really helps the reader get the overall model, so this section covers one such case 💜
WebDAV [WEBDAV] includes both a COPY method and a MOVE method. A MOVE can be thought of as a COPY followed by a DELETE, but COPY+DELETE and MOVE aren't totally equivalent 👀
Using COPY+DELETE as a stand-in for MOVE is a problem because of the intermediate file it creates 😬 Picture a user who's getting close to a quota boundary. A COPY+DELETE should be forbidden because it would temporarily exceed the quota. A simple rename, though, should work just fine in that situation ✨
The second issue is permissions 🔐 The WebDAV permissions model lets the server grant users permission to rename files but not to create new ones. That's unusual for ordinary filesystems, but WebDAV doesn't prevent it. This is clearly not possible if a client uses COPY+DELETE to do a MOVE.
Finally, a COPY+DELETE doesn't produce the same logical result you'd expect from a MOVE 🫠 Since COPY creates a new resource, it's permitted (but not required) to use the time of new file creation as the creation date property. On the flip side, the expectation for MOVE is that the renamed file keeps the same properties as the original 🌸
5. Formatting Issues 🎀
The requirement that Internet-Drafts and RFCs be renderable in ASCII is a real obstacle when you're writing the graphics-heavy kind of document we're describing 🥲 Authors might find it easier to make a separate protocol model document in Postscript or PDF and just make it available at review time, though an archival version would definitely be handy 📎
6. A Complete Example: Internet Key Exchange (IKE) 🔑
Internet Key Exchange (IKE) [IKE] is one of the most complicated security protocols the IETF has ever designed 😵💫 Even though the basic IKE core is a fairly straightforward Diffie-Hellman-based handshake, it can be hard for new readers to get abstractly, apart from the protocol details. The rest of this section gives an overview of IKE that's built for those new readers 🫶
6.1. Operating Environment ✨
okay so IKE (Internet Key Exchange) [IKE] is the key establishment and parameter negotiation protocol for Internet protocols 🔑. Its main job is setting up 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 |
+--------------------+ +--------------------+so the general deployment model looks like the diagram above 👀. The IPsec engines and IKE engines are typically separate modules. When there's no security association for a packet that needs processing (either sent or received), the IPsec engine contacts the IKE engine and asks it to set up an appropriate SA. The IKE engine contacts the right peer and uses IKE to establish the SA. Once the IKE handshake is finished, it registers the SA with the IPsec engine 💅.
Also, IKE traffic between the peers can be used to refresh keying material or adjust operating parameters, like algorithms ✨.
6.1.1. Initiator and Responder 🙃
IPsec is basically symmetrical, but IKE is not. The party who sends the first message is called the INITIATOR. The other party is called the RESPONDER. With TCP connections, the INITIATOR will typically be the peer doing the active open (aka the client) 🎀.
6.1.2. Perfect Forward Secrecy 🔒
One of the big goals in IKE design was that traffic stays protected even if the nodes' keying material gets compromised later, as long as the session had already terminated and the session-specific keying material was gone. This is often called Perfect Forward Secrecy (PFS) or back traffic protection 🌈.
6.1.3. Denial of Service Resistance 😭
Because IKE lets arbitrary peers start 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. IKE needs to be able to set up SAs between a broad range of peers with all kinds of prior relationships, so it 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 🫶
Even though IKE requires the peers to authenticate to each other, the working group thought it was desirable to give the communicating peers some identity protection. 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 👑.
6.2. Protocol Overview 🦋
At a very high level, there are two kinds of IKE handshake:
- Those that establish an IKE security association.
- 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 lets them 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. Here's the schematic form 👇. 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 handshakeIKE terminology is kinda confusing, referring under different circumstances to "phases" and "modes" 🙄. For maximal clarity, we'll refer to establishing the IKE SA as "Stage 1" and establishing the 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 pretty different, because the Stage 2 handshake can, of course, assume that its traffic is being protected with an IKE SA. So we'll discuss Stage 1 first and then Stage 2 🌸.
6.2.1. Stage 1 💜
There are a large number of variants of the IKE Stage 1 handshake, necessitated by the 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'll 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. Here's an overview 👀.
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 ✨.
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:
- A set of algorithms for encryption of further IKE traffic.
- Traffic encryption and authentication keys.
- 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)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 ✨
okay so Stage 1 on its own isn't that useful, bestie 🙈 The whole point of IKE is to set up the associations that protect your other traffic, not just the IKE SAs themselves. That's where Stage 2 comes in (IKE calls it "Quick Mode") 💅 The basic Stage 2 handshake looks like this:
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 set up the algorithms and parameters, and the last message is a check over the earlier ones. This time the parameters also include the transforms to apply to the traffic (AH or ESP) and which kinds of traffic get protected. And notice there's no key exchange info in these messages 👀
In this version, the peers use the Stage 1 keying material that's already around to derive fresh keys for traffic protection, with the nonces making sure everything stays fresh 🦋 Quick mode also lets you do a brand new Diffie-Hellman handshake for per-traffic key PFS 👑 In that case, the first two messages get Key Exchange payloads too, like this:
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 bunch of IKE features that deserve special attention, so we're covering them here 💖
6.3.1. Cookie Generation 🍪
Remember how IKE uses cookies as a partial defense against DoS attacks? When the responder gets Main Mode message 3 with the Key Exchange data and the cookie, it checks that the cookie is correct. But this verification must not involve keeping a list of valid cookies. Otherwise an attacker could eat up memory by repeatedly asking the responder for cookies 💀 The recommended way to generate one, 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. The responder can verify the cookie by recomputing it from the information in the third message and checking whether it matches 🫶
6.3.2. Endpoint Identities 🪪
So far we've been kinda vague about what kinds of endpoint identities get used, so let's fix that 😭 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. The key is tied to a key identifier that both parties know. The party verifying the identity is also assumed to have a table showing which traffic (aka which addresses) that identity is allowed to negotiate SAs for.
6.3.2.2. Pre-Configured Public Key 🌸
It's basically the same vibe as shared key, except 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. Checking that this certificate matches the authentication data from the peer is straightforward. What's less straightforward is figuring out whether a given peer is entitled to negotiate for a given class of traffic. In theory you might be able to tell from the name in the certificate (like if the subject name contains an IP address that matches the ostensible IP address). In practice, IKE doesn't clearly specify this, so it's not really interoperable 🙃 For now, it's likely that a configuration table maps certificates to policies, same as the other two authentication schemes.
7. Security Considerations 🔐
This document doesn't define any protocols, so it has no security issues.
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 RosenbergNormative 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.
[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.orgFull 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. It also doesn't 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, 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.
📦 where this page comes from
- ietf: rfc4101 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms