RFC 4322
Opportunistic Encryption using the Internet Key Exchange (IKE)
RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE) 🦋
okay so this RFC is from December 2005 and it's from the Network Working Group 🌸 It's written by M. Richardson (SSW) and D.H. Redelmeier (Mimosa), and it's Informational, which means it shares info for the Internet community but doesn't set a standard. 💅 It doesn't list anything it obsoletes or updates, so it's a standalone doc bestie 🫶
Status of This Memo ✨
okay, the vibe here is "this is info, not a rule." 💖 It gives information for the Internet community and does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice 🎀
Copyright (C) The Internet Society (2005). 📜
Abstract 🔥
this doc describes opportunistic encryption (OE) the way the Linux FreeS/WAN project designed and built it 🛠️ OE uses the Internet Key Exchange (IKE) and IPsec protocols. the goal is to get encryption working between two systems without any pre-arrangement specific to that pair, which is so iconic ✨ DNS is used to distribute the public keys of each system involved, and this is resistant to passive attacks. 🛡️ DNS Security (DNSSEC) makes the whole system secure against active attackers too, so it's giving full protection 💅
the admin overhead goes from the square of the number of systems to a linear dependence 📈 and it becomes possible to make secure communication the default even when you don't know the partner in advance. main character energy 👑
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Encryption Regimes .........................................4
1.3. Peer Authentication in Opportunistic Encryption ............4
1.4. Use of RFC 2119 Terms ......................................5
2. Overview ........................................................6
2.1. Reference Diagram ..........................................6
2.2. Terminology ................................................6
2.3. Model of Operation .........................................8
3. Protocol Specification ..........................................9
3.1. Forwarding Plane State Machine .............................9
3.2. Keying Daemon -- Initiator ................................12
3.3. Keying Daemon -- Responder ................................20
3.4. Renewal and Teardown ......................................22
4. Impacts on IKE .................................................24
4.1. ISAKMP/IKE Protocol .......................................24
4.2. Gateway Discovery Process .................................24
4.3. Self Identification .......................................24
4.4. Public Key Retrieval Process ..............................25
4.5. Interactions with DNSSEC ..................................25
4.6. Required Proposal Types ...................................25
5. DNS Issues .....................................................26
5.1. Use of KEY Record .........................................26
5.2. Use of TXT Delegation Record ..............................27
5.3. Use of FQDN IDs ...........................................29
5.4. Key Roll-Over .............................................29
6. Network Address Translation Interaction ........................30
6.1. Co-Located NAT/NAPT .......................................30
6.2. Security Gateway behind a NAT/NAPT ........................30
6.3. End System behind a NAT/NAPT ..............................31
7. Host Implementations ...........................................31
8. Multi-Homing ...................................................31
9. Failure Modes ..................................................33
9.1. DNS Failures ..............................................33
9.2. DNS Configured, IKE Failures ..............................33
9.3. System Reboots ............................................34
10. Unresolved Issues .............................................34
10.1. Control of Reverse DNS ...................................34
11. Examples ......................................................34
11.1. Clear-Text Usage (Permit Policy) .........................34
11.2. Opportunistic Encryption .................................36
12. Security Considerations .......................................39
12.1. Configured versus Opportunistic Tunnels ..................39
12.2. Firewalls versus Opportunistic Tunnels ...................40
12.3. Denial of Service ........................................41
13. Acknowledgements ..............................................41
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................421. Introduction ✨
1.1. Motivation 💖
the goal of opportunistic encryption is to allow encryption with no pre-arrangement specific to the two systems involved. 🔐 each system admin adds public key info to DNS records to support OE, then turns the feature on in the node's IPsec stack. once that's done, any two of these nodes can talk securely. it's literally that easy 🥹
this doc describes OE as designed and built by the Linux FreeS/WAN project in revisions up to and including 2.00. ngl, the thing to know is that 2.01 and beyond implements [RFC3445] in a backward compatible way 🙈 a future document [IPSECKEY] will describe a variation that complies with RFC 3445. for project info, check http://www.freeswan.org.
the Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [RFC1984]. the Linux FreeS/WAN project is trying to give us a practical way to make that policy real 💅
the project uses the IPsec, ISAKMP/IKE, DNS, and DNSSEC protocols because they're standardized, widely available, and can often be deployed really easily without changing hardware or software, or retraining users. no notes 🙌
the extensions to support OE are simple. no changes to any on-the-wire formats are needed. the only changes are to the policy decision making system 🧠 which means OE can be added to an existing IPsec implementation with very minimal changes. so efficient 🦋
OE creates a "fax effect" 📠 the fax machine took off because not everyone had to buy one overnight. as each person got one, the value went up because there were more people who could receive faxes. once OE is installed, it automatically recognizes other boxes running OE, with no extra configuration from the network admin. so the more boxes that have it, the more useful it gets ✨
this document describes the infrastructure that lets Opportunistic Encryption be deployed 🌸
the term S/WAN is a trademark of RSA Data Systems, and this project uses it with permission. ⭐
1.2. Encryption Regimes 🌈
to help us understand how security processing and IPsec relate, we split the policies that control network traffic into four categories. 🗂️ the traffic is categorized by destination address using longest prefix match, so each category is listed as a set of network prefixes. the categories are mutually exclusive, meaning a particular prefix should only show up in one category.
- Deny: network prefixes that traffic is always forbidden to.
- Permit: network prefixes that traffic in the clear is permitted to.
- Opportunistic tunnel: network prefixes that traffic is encrypted to if possible, when it otherwise might be sent in the clear.
- Configured tunnel: network prefixes that traffic must be encrypted to, and traffic in the clear is never permitted. A traditionally defined Virtual Private Network (VPN) is a form of configured tunnel.
the first two categories are usually handled by traditional firewall devices, and no authentication is required 🔥 the permit policy is currently the default on the Internet.
this document covers the third category, the opportunistic tunnel, which is proposed as the new default for the Internet 🎀
category four is a super strict "encrypt it or drop it" policy, and it requires authentication of the endpoints 🔒 since the number of endpoints is usually bounded and usually under a single authority, setting up authentication material is hard but doesn't need any new tech. the mechanism here does add another way to distribute that authentication material, though. it's a public key method that doesn't require deploying an X.509 based infrastructure, which is a whole mood 💜
1.3. Peer Authentication in Opportunistic Encryption 🫧
OE creates tunnels between nodes that are basically strangers 👀 this happens without any prior bilateral arrangement. so the tricky question is how you know who you're talking to 😳
one possible answer is that since no useful authentication can be done, none should be tried. this mode of operation is called "anonymous encryption". an active man-in-the-middle attack can be used to break the privacy of this kind of communication, and without peer authentication there's no way to stop that kind of attack 💀
anonymous encryption is a useful mode, but it's not the goal of this project. simpler methods can get you anonymous encryption only, but authenticating the peer is a desirable goal. peer authentication is achieved through key distribution in DNS, leaning on the authentication of DNS that DNSSEC provides 🔐
so peers are authenticated with DNSSEC when it's available. when DNSSEC isn't available, local policy decides how much trust to extend 🧐
here's the key premise for building private connections with strangers: datagrams received through opportunistic tunnels are no more special than datagrams that arrive in the clear. 🫶 unlike in a VPN, these datagrams should not be given any special exceptions when it comes to auditing, further authentication, or firewalling.
when you start outbound OE, local configuration decides what happens if tunnel setup fails. the packet may go out in the clear, or it may be dropped 🙃
1.4. Use of RFC 2119 Terms 📚
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
2. Overview 🧚
2.1. Reference Diagram ✨
Okay bestie, here's the canonical diagram we'll use for the rest of this doc 🗺️ Everything after this points back to it, so keep it open 🫶
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
Figure 1: Reference Network DiagramSo in this diagram, there are four end-nodes: A, B, C, and D 💜 There are three security gateways: SG-A, SG-B, SG-D. A, D, SG-A, and SG-D all belong to the same administrative authority, AS1. SG-A and SG-D sit on two different exit paths from organization 1, which is giving redundancy energy 🛤️ SG-B and B belong to an independent organization, AS2. Nodes Q and R are nodes on the Internet. And PI is the Public Internet, aka "The Wild" 🌍✨
2.2. Terminology
Note: The network numbers used in this document are for illustrative purposes only. This document could not use the reserved example network numbers of [RFC3330] because multiple address ranges were needed. Not a flex, just a necessity 💅
Here's the vocab you need to know:
- Security gateway (or simply gateway): a system that performs IPsec tunnel mode encapsulation/decapsulation. It shows up as
[SG-x]in the diagram 🚪 - Alice: node
[A]in the diagram. When an IP address is needed, this is192.1.0.65. 🎀 - Bob: node
[B]in the diagram. When an IP address is needed, this is192.2.0.66. 🦋 - Carol: node
[C]in the diagram. When an IP address is needed, this is192.1.1.67. 🌸 - Dave: node
[D]in the diagram. When an IP address is needed, this is192.3.0.68. 🧚 - SG-A: Alice's security gateway. Internally it is
192.1.0.1, externally it is192.1.1.4. 💖 - SG-B: Bob's security gateway. Internally it is
192.2.0.1, externally it is192.1.1.5. 💜 - SG-D: Dave's security gateway. It's also Alice's backup security gateway 🫣 Internally it is
192.3.0.1, externally it is192.1.1.6. Two jobs, one gateway, very multitasking 💅 - Configured tunnel: a tunnel that is directly and deliberately hand-configured on participating gateways. Configured tunnels are typically given a higher level of trust than opportunistic tunnels. Think VIP list vs. random DM 👑
- Road warrior tunnel: a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed node cannot know the current address for the road warrior. The traveler has to be the one to text first 📱✈️
- Anonymous encryption: the process of encrypting a session without any knowledge of who the other parties are. No authentication of identities is done. Encrypted, but nobody's checking the ID at the door 🙈
- Opportunistic encryption: the process of encrypting a session with authenticated knowledge of who the other party is without prearrangement. Encryption that just happens once you know who you're talking to, no pre-planning needed 🌈
- Lifetime: the period in seconds (bytes or datagrams) for which a security association will remain alive before rekeying is needed. A timer for when the key gets refreshed ⏳
- Lifespan: the effective time for which a security association remains useful. A security association with a lifespan shorter than its lifetime would be removed when no longer needed. A security association with a lifespan longer than its lifetime would need to be re-keyed one or more times. So lifetime is the limit, lifespan is how long it actually stays useful, and the gap between them decides whether it gets tossed or re-keyed 🫠
- Phase 1 SA: an ISAKMP/IKE security association sometimes referred to as a keying channel. 🔑
- Phase 2 SA: an IPsec security association. 🔐
- Tunnel: another term for a set of phase 2 SA (one in each direction). 🚇
- NAT: Network Address Translation (see [RFC2663]). 🔀
- NAPT: Network Address and Port Translation (see [RFC2663]). 🔀
- AS: an autonomous system. 🏛️
- FQDN: Fully-Qualified Domain Name. 🏷️
- Default-free zone: a set of routers that maintain a complete set of routes to all currently reachable destinations. Having such a list, these routers never make use of a default route. A datagram with a destination address not matching any route will be dropped by such a router. No "I'll just send it to the default gateway and hope" energy here 🙅♀️
2.3. Model of Operation
Now the main event 🎬 The opportunistic encryption security gateway (OE gateway) is a regular gateway node, as described in [RFC0791] section 2.4 and [RFC1812], with the additional capabilities described here and in [RFC2401]. The algorithm described here provides a way to determine, for each datagram, whether or not to encrypt and tunnel the datagram. Two important things that must be determined are whether or not to encrypt and tunnel and, if so, the destination address or name of the tunnel endpoint that should be used. So the gateway has to answer two questions for every packet: do I encrypt this, and if yes, who's the endpoint 🤔✨
2.3.1. Tunnel Authorization
The OE gateway decides whether or not to create a tunnel based on the destination address of each packet. When it gets a packet with a destination address it hasn't recently seen, the OE gateway does a lookup in DNS for an authorization resource record (see Section 5.2). That record is located by using the IP address to search the in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization record is found, the OE gateway reads this as a request for a tunnel to be formed. DNS said "yes, let's tunnel" 📖💕
2.3.2. Tunnel Endpoint Discovery
The authorization resource record also provides the address or name of the tunnel endpoint that should be used. Main character handoff 🎤
The record may also provide the public RSA key of the tunnel endpoint itself. This is provided for efficiency only. If the public RSA key is not present, the OE gateway performs a second lookup to find a KEY resource record for the endpoint address or name. Fewer lookups, more vibes ⚡
Origin and integrity protection of the resource records is provided by DNSSEC (see [RFC4033]). Section 3.2.4.1 documents an optional restriction on the tunnel endpoint if DNSSEC signatures are not available for the relevant records. So if the DNSSEC signatures aren't there, there's an optional restriction you can apply to the endpoint, and Section 3.2.4.1 has the details 🔏
2.3.3. Caching of Authorization Results
The OE gateway keeps a cache, in the forwarding plane, of source/destination pairs for which opportunistic encryption has been attempted. This cache remembers whether or not OE worked out, so later datagrams can be forwarded properly without extra delay 🏃♀️💨
Successful negotiation of OE sets up a new security association. Failed negotiation results in creating a forwarding policy entry that either denies or permits sending future datagrams in the clear. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking up the same information. Nobody wants to re-ask the same question 10 times 🙄
The cache is timed out periodically, as described in Section 3.4. This removes entries that are no longer being used and lets the gateway notice changes in authorization policy. Cache cleanup, but make it fashion 🧹🌸
3. Protocol Specification ✨
The OE gateway is modeled as having a forwarding plane and a control plane. A control channel, such as PF_KEY [RFC2367], connects the two planes 🔌
The forwarding plane does per-datagram operations. The control plane holds a keying daemon, such as ISAKMP/IKE, and handles all authorization, peer authentication, and key derivation functions. Forwarding is the hands-on worker, control is the brain 🧠💅
3.1. Forwarding Plane State Machine
Okay so the gateway keeps a collection of objects. Think of it as a superset of the security policy database (SPD) specified in [RFC2401] 🗂️ For each combination of source and destination address, an SPD object exists in one of the five following states. Before forwarding each datagram, the responder uses the source and destination addresses to pick an entry from the SPD. The SPD then decides if and how the packet is forwarded. Here's the whole flow 👇
.--------------.
| nonexistent |
| policy |
`--------------'
|
| PF_ACQUIRE
|
|<---------.
V | new packet
.--------------. | (maybe resend PF_ACQUIRE)
| hold policy |--'
| |--.
`--------------' \ pass
| | \ msg .---------.
| | \ V | forward
| | .-------------. | packet
create | | | pass policy |--'
IPsec | | `-------------'
SA | |
| \
| \
V \ deny
.---------. \ msg
| encrypt | \
| policy | \ ,---------.
`---------' \ | | discard
\ V | packet
.-------------. |
| deny policy |--'
`-------------'3.1.1. Nonexistent Policy
If the gateway doesn't find an entry, this policy applies. The gateway creates an entry with an initial state of "hold policy" and asks the keying daemon for keying material. The gateway does not forward the datagram. Instead, it SHOULD attach the datagram to the SPD entry as the "first" datagram and keep it around for eventual transmission in a new state. Hold that thought 🤏
3.1.2. Hold Policy
The gateway requests keying material. If the interface to the keying system is lossy (PF_KEY, for instance, can be), the implementation SHOULD include a mechanism to retransmit the keying request at a rate limited to less than 1 request per second. The gateway does not forward the datagram. The gateway SHOULD attach the datagram to the SPD entry as the "last" datagram, where it is kept for eventual transmission. If there is already a datagram stored in this way, then that already-stored datagram is discarded. Only one "last" at a time, the rest get yeeted 💨
The reasoning behind saving the "first" and "last" datagrams goes like this 🧠 The "first" datagram is probably a TCP SYN packet. Once keying is established, the gateway will release this datagram, so the endpoint doesn't have to retransmit it. If the connection wasn't TCP, but was instead a streaming protocol or a DNS request, the "last" datagram that was kept is likely the most recent data. The difference between "first" and "last" may also help the endpoints figure out which data got dropped while negotiation was happening. Little detail, big brain 🍓
3.1.3. Pass-Through Policy
The gateway forwards the datagram using the normal forwarding table. The gateway only enters this state by command from the keying daemon, and when it does, it also forwards the "first" and "last" datagrams. Green light from the daemon, everything moves 🟢
3.1.4. Deny Policy
The gateway discards the datagram. The gateway only enters this state by command from the keying daemon, and upon entering it, discards the "first" and "last" datagrams. An implementation MAY provide the administrator with a control to determine if further datagrams cause ICMP messages to be generated (i.e., ICMP Destination Unreachable, Communication Administratively Prohibited. type=3, code=13). So the admin can optionally decide whether later packets get the type=3, code=13 ICMP message, which is basically a polite "nope, administratively prohibited" 🚫💀
3.1.5. Encrypt Policy
The gateway encrypts the datagram using the indicated security association database (SAD) entry. The gateway only enters this state by command from the keying daemon, and upon entering it, releases and forwards the "first" and "last" datagrams using the new encrypt policy. Locked in and encrypted 🔒✨
If the associated SAD entry expires because of byte, packet or time limits, then the entry returns to the Hold policy, and an expire message is sent to the keying daemon. Expired? Back to hold, and the daemon gets a heads-up 🔄
All states may be created directly by the keying daemon while acting as a gateway. The daemon can skip the line and make any of these states itself 👑
More parts are coming, so keep your seat belt on 🎢💜
3.2. Keying Daemon -- Initiator ✨
okay so the keying daemon keeps a collection of objects called "connections" or "conn"s 🧚 there are two categories: classes and instances 💅 a class is an abstract policy (aka what could be), and an instance is an actual connection (aka what's running right now) 🦋
there are also two subtypes: keying channels (Phase 1 SAs) and data channels (Phase 2 SAs) 🎀 each data channel object may have a matching SPD and SAD entry that the datagram state machine maintains 💜
for opportunistic encryption (OE), there MUST, at least, be connection classes called "deny", "always-clear-text", "OE-permissive", and "OE-paranoid" 🌸 the last two define a set of destination prefixes where OE gets attempted 🔥 the administrator MAY set policy options in a bunch of extra places, and an implementation MAY create more connection classes to refine these policies 💖
the simplest system only needs the "OE-permissive" connection 🌈 it lists its own single IP address as the source address of the policy, and the wild-card address 0.0.0.0/0 as the destination IPv4 address. so the simplest policy is basically "try OE with everyone" 😭 this simplest policy SHOULD be offered as a preconfigured default 🫶
the difference between permissive and paranoid OE ("OE-paranoid" below) will make sense once you see the state transition differences 👑
quick recap: an OE-permissive policy lets traffic flow in the clear when the encryption keys can't be found or used 🙈 it keeps the network working, even if it's kinda insecure 😬 on failure, an OE-paranoid policy installs a drop policy instead 💀 OE-paranoid only lets traffic through when proper security is actually available 🔒
in this description of the keying machine's state transitions, I left out the states of the keying system itself, because those are documented in the keying system specs ([RFC2407], [RFC2408], and [RFC2409] for ISAKMP/IKE) and the details depend on the keying system 🍓 OE isn't tied to any specific keying protocol, but this document does give requirements for anyone using ISAKMP/IKE so implementations interoperate 🤝
also omitted: the state transitions for talking to the forwarding plane 🙅♀️ PF_KEY and similar protocols have their own states for message sends and completion notifications ✨
last thing: the retransmits and recursive lookups that are normal for DNS aren't in this state machine either 🌸
|
| PF_ACQUIRE
|
V
.---------------.
| nonexistent |
| connection |
`---------------'
| | |
send , | \
expired pass / | \ send
conn. msg / | \ deny
^ / | \ msg
| V | do \
.---------------. | DNS \ .---------------.
| clear-text | | lookup `->| deny |--->expired
| connection | | for | connection | connection
`---------------' | destination `---------------'
^ ^ | ^
| | no record | |
| | OE-permissive V | no record
| | .---------------. | OE-paranoid
| `------------| potential OE |---------'
| | connection | ^
| `---------------' |
| | |
| | got TXT record | DNSSEC failure
| | reply |
| V | wrong
| .---------------. | failure
| | authenticate |---------'
| | & parse TXT RR| ^
| repeated `---------------' |
| ICMP | |
| failures | initiate IKE to |
| (short timeout) | responder |
| V |
| phase-2 .---------------. | failure
| failure | pending |---------'
| (normal | OE | ^
| timeout) | |invalid | phase-2 fail (normal
| | |<--.SPI | timeout)
| | | | | ICMP failures (short
| | +=======+ |---' | timeout)
| | | IKE | | ^ |
`----------------| states|---------------'
| +=======+ | |
`---------------' |
| IPsec SA | invalid SPI
| established |
V | rekey time
.--------------. |
| keyed |<---|------------------------------.
| connection |----' |
`--------------' |
| timer |
| |
V |
.--------------. connection still active |
clear-text----->| expired |-----------------------------------'
deny----->| connection |
`--------------'
| dead connection - deleted
V3.2.1. Nonexistent Connection 🫣
there's no connection instance for a given source/destination address pair 💫 when a request for keying material comes in for that pair, the initiator searches through the connection classes to find the best policy 🔍 once it picks a connection class, it creates an instance object of that type 🧁 both of the OE types end up as a potential OE connection 💜
if the initiator can't find a matching connection class, the administrator-defined default kicks in 🙃
either way, when the initiator finds a fitting class for the new flow, it makes an instance connection of the class that matched 🎯
3.2.2. Clear-Text Connection 🫧
the nonexistent connection moves to this state when an always-clear-text class gets instantiated, or when an OE-permissive connection fails 🌷 during that transition, the initiator creates a pass-through policy object in the forwarding plane for the right flow 🦋
the only way out of this state is timing out (see Section 3.2.7) ⏳
3.2.3. Deny Connection 🚫
the empty connection moves to this state when a deny class gets instantiated, or when an OE-paranoid connection fails 🥀 during the transition, the initiator creates a deny policy object in the forwarding plane for the right flow 💅
again, timing out is the only way out (see Section 3.2.7) ⌛
3.2.4. Potential OE Connection 🔎
the empty connection moves here when one of the two OE classes gets instantiated 🌸 on the way in, the initiator creates a hold policy object in the forwarding plane for that flow 🧺
also, when entering this state, a DNS lookup happens in the reverse-map for a TXT delegation resource record (see Section 5.2) 📖 the lookup key is the flow's destination address 🗝️
there are three ways to leave this state:
- DNS lookup finds a TXT delegation resource record.
- DNS lookup does not find a TXT delegation resource record.
- DNS lookup times out.
based on the DNS result, the potential OE connection moves to the pending OE connection state 🚀 the conditions for a successful DNS lookup are:
- DNS finds an appropriate resource record.
- It is properly formatted according to Section 5.2.
- If DNSSEC is enabled, then the signature has been vouched for.
heads up: if the initiator doesn't find the public key in the TXT delegation record, the public key has to be looked up as a sub-state 🔑 only successful completion of all the DNS lookups counts as a success 🏆
if DNS doesn't find a resource record, or DNS times out, the initiator considers the receiver not OE capable 🙅♀️ for an OE-paranoid instance, the potential OE connection moves to the deny connection state 💀 for an OE-permissive instance, it moves to the clear-text connection state 🫶
if the initiator finds a resource record but it isn't properly formatted, or DNSSEC is enabled and reports an authentication failure, the potential OE connection moves to the deny connection state 🚫 this action SHOULD be logged 📝 if the administrator wants to override this transition, an always-clear class can be installed for that flow 🌈 an implementation MAY make this situation a new class 🧚
⚠️ this part matters: if a record is malformed or fails DNSSEC, the flow goes to deny, not clear-text, so check your logs 👀
3.2.4.1. Restriction on Unauthenticated TXT Delegation Records 🛡️
an implementation SHOULD also provide an extra administrative control on delegation records and DNSSEC 💖 this control applies to delegation records (the TXT records in the reverse-map) that are NOT protected by DNSSEC 🙅♀️ records of this type are only permitted to delegate to their own address as a gateway 🎀 when this option is enabled, an active attack on DNS can't redirect packets anywhere other than the original destination 🛑✨
3.2.5. Pending OE Connection
okay so the potential OE connection flips into this state once the initiator has every bit of info it needed from the DNS lookup 🔍✨. The second that happens, the initiator goes "bet" and starts trying to key with the gateway it was handed 🦋.
We leave this state one of two ways: either an IPsec SA gets successfully made, or something fails 💀. A successful SA sends us over to the key connection state 🎀.
Three failures have caused major drama 😭. Just know they're not the only ways keying can flop.
Also, if there are several gateways listed in the TXT delegation records, you can't declare a failure until you've tried every single one 🙈. And making a phase 1 SA doesn't count as winning yet 💅. The real W is a set of phase 2 SAs (a tunnel) 👑.
The first failure is when an ICMP port unreachable keeps showing up with no other communication, or when the remote end is just silent 🦗. That usually means the gateway is down or the keying daemon isn't working 😵. For an OE-permissive connection, the initiator moves to the clear-text connection, but with a low lifespan 🌸. For an OE-pessimistic connection, it goes back to the deny connection, also with a low lifespan 🚫. The lifespan stays low in both cases because the remote gateway could be rebooting or just temporarily unavailable 🔄.
How long to wait for the remote keying daemon to wake up is kind of a hot debate 🔥. If there's a routing failure, 5 minutes is usually enough for the network to re-converge 🌐. Lots of systems can reboot in that time too ⏰. But honestly, 5 minutes is way too long for most users to sit around waiting to find out they can't connect using OE 😩. Implementations SHOULD make this a tunable parameter 🎛️✨.
The second failure happens after a phase 1 SA exists, but either there's no response to the phase 2 proposal, or the initiator gets a negative notify (the notify must be authenticated 🔐). The remote gateway just isn't ready for OE right now 🙅♀️. Same as before, the initiator moves to the clear-text or the deny connection based on the connection class, but this time with a normal lifespan 💖.
The third failure is when signature verification fails while authenticating the remote gateway 🥀. This can happen during a key roll-over when DNS hasn't caught up yet 🕰️. Again, the initiator goes to the clear-text or the deny connection based on the connection class 🦋. The big difference is that the lifespan depends on how much time to live is left in DNS ⏳. (Quick aside: DNSSEC signed resource records have a different expiry time from non-signed records 🧐.)
3.2.6. Keyed Connection
The pending OE connection moves to this state once the session keying material (the phase 2 SAs) gets derived 🗝️✨. The initiator then creates an encrypt policy in the forwarding plane for this flow 🔐💜.
There are three ways out of this state 🚪. The first is getting an authenticated delete message (through the keying channel) from the peer. This is normal teardown, and it sends us to the expired connection state 👋.
The second exit is when the forwarding plane keying material expires ⏰. That kicks off a re-key operation and sends us back to pending OE connection 🔁. Usually the soft expiry happens while there's still plenty of time left to keep using the keys 🌈. A re-key can fail, though, and that might drop the connection down to clear-text or deny, depending on what's appropriate 😬. If that happens, the forwarding plane policy doesn't change until the phase 2 SA (IPsec SA) hits its hard expiry 🧱.
The third exit comes from a negotiation with a remote gateway 📡. If the forwarding plane tells the control plane it got an unknown SPI from the remote gateway, or an ICMP shows up from the remote gateway saying there's an unknown SPI, the initiator should assume the remote gateway has rebooted or restarted 🔄✨. These signals are super easy to forge, so the implementation must take care 🛡️. The initiator should make a cautious (rate-limited) attempt to re-key the connection 🐢.
3.2.7. Expiring Connection
The initiator will periodically drop each of the deny, clear-text, and keyed connections into this sub-state ⏳. See Section 3.4 for more details on how often that happens 📅. The initiator asks the forwarding plane for the last use time of the appropriate policy 🕵️♀️. If the last use time is pretty recent, the connection goes back to its previous deny, clear-text, or keyed connection state 🔙. If not, it enters the expired connection state 💀.
The DNS query and answer that led to the expiring connection state also get checked 🔎. The DNS query might be stale 🥱. (A negative answer, meaning no such record, is valid for the period of time given by the MINIMUM field in an attached SOA record. See [RFC1034] section 4.3.4 📚.) If the DNS query is stale, a new one gets made 🆕. If the results change, the connection transitions to a new state as described in the potential OE connection state 💫.
Heads up: when figuring out how stale a connection is, both outgoing SPD and incoming SAD must be queried 👀, because some flows can be one-way for a while 🦋.
Also, the policy at the forwarding plane doesn't get updated unless there's a conclusion that something should change 🙅♀️✨.
3.2.8. Expired Connection
This state kicks in when no datagrams have been forwarded recently through the appropriate SPD and SAD objects 💤. The objects in the forwarding plane get removed (logging any final byte and packet counts, if appropriate 📝), and the connection instance in the keying plane gets deleted 🗑️.
The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs, as described in Section 3.4 🧹.
Whether to delete the phase 1 SAs at this point is a local implementation issue 🏠. Implementations that do delete the phase 1 SAs MUST send authenticated delete messages to say they're doing it 📣. There is an advantage to keeping the phase 1 SAs until they expire, though: they might come in clutch again in the near future 🦸♀️💜.
3.3. Keying Daemon -- Responder
The responder has a set of objects that are identical to the initiator's 👯♀️.
The responder gets an invitation to create a keying channel from an initiator 💌.
|
| IKE main mode
| phase 1
V
.-----------------.
| unauthenticated |
| OE peer |
`-----------------'
|
| lookup KEY RR in in-addr.arpa
| (if ID_IPV4_ADDR)
| lookup KEY RR in forward
| (if ID_FQDN)
V
.-----------------. RR not found
| received DNS |---------------> log failure
| reply |
`----+--------+---'
phase 2 | \ misformatted
proposal | `------------------> log failure
V
.----------------.
| authenticated | identical initiator
| OE peer |--------------------> initiator
`----------------' connection found state machine
|
| look for TXT record for initiator
|
V
.---------------.
| authorized |---------------------> log failure
| OE peer |
`---------------'
|
|
V
potential OE
connection in
initiator state
machine3.3.1. Unauthenticated OE Peer
As soon as the responder lands in this state, it starts a DNS lookup for a KEY record for the initiator 🔭. It checks the reverse-map for a KEY record if the initiator offered an ID_IPV4_ADDR, and the forward map if the initiator offered an ID_FQDN type 🗺️. (See [RFC2407] section 4.6.2.1 📖.)
The responder leaves this state once it successfully gets a KEY from DNS and uses that key to verify the initiator's signature 🔑✅.
If the peer authenticates successfully, it moves to the authenticated OE Peer state 🎉.
Just a note: the unauthenticated OE peer state usually shows up in the middle of the key negotiation protocol 🥪. It's really a form of pseudo-state 👻.
3.3.2. Authenticated OE Peer
The peer will eventually propose one or more phase 2 SAs 💬. The responder uses the source and destination address in the proposal to finish setting up the connection state, using the connection class table 🗂️. The responder MUST search for an identical connection object at this point 🔍.
If an identical connection is found, the responder deletes the old instance, and the new object transitions to the pending OE connection state 🔄. This means new ISAKMP connections with a given peer will always use the latest instance, which is the right one if the peer rebooted in the meantime 🥰.
If an identical connection is not found, the responder makes the transition using the same rules as the initiator. It installs the appropriate policy: clear, drop, or OE 🛠️.
If it's OE, and the phase 2 ID (source IP) is different from the phase 1 ID, then extra authorization is needed 🛂. A TXT record tied to the proposed phase 2 source IP gets requested 📜. That's used to confirm that the phase 1 identity is allowed to encrypt on behalf of the phase 2 🤝. A successful retrieval moves things to "Authorized OE Peer" ✨.
Note that if the initiator is in OE-paranoid mode and the responder is in either always-clear-text or deny, then no communication is possible under policy 🚫. An implementation is permitted to create new types of policies, like "accept OE but do not initiate it" 🧩. That's a local matter 🏡.
3.3.3. Authorized OE Peer
This state is entered from the Authenticated OE Peer state once the TXT record has been retrieved successfully 📥. The contents of the record get confirmed. Any failures lead to errors, as indicated in Section 3.2.4 ❌.
3.4. Renewal and Teardown
3.4.1. Aging ⏳
okay so, a tunnel count has no real upper limit 🌸, but in practice only a few tunnels are actually in use at any given time, so unused tunnels MUST, therefore, be torn down 🧹. This section is all about figuring out when a tunnel has stopped being used. It's the vibe check of the whole thing 💅.
There are two ways to remove a tunnel: explicit deletion or expiry ✨.
Explicit deletion needs an IKE delete message. The deletes MUST be authenticated, so both ends have to keep the keying channel (phase 1 ISAKMP SA) alive 🔐. An implementation that refuses to either maintain or recreate the keying channel SA won't be able to use this method 🙈.
Expiry is simpler. The IKE daemon just lets the tunnel expire normally and doesn't try to re-key it 🥀.
No matter which method you pick, the implementation MUST use a method to determine if the tunnel is still in use 👀. The specifics are a local matter, but the FreeS/WAN project uses the following criteria. These are currently implemented in the key management daemon, but they could also live at the SPD layer using an idle timer 🧚.
Here's how the FreeS/WAN criteria go 🎀:
Set a short initial (soft) lifespan of 1 minute, since many net flows only last a few seconds ⏱️.
At the end of that lifespan, check whether the tunnel was used by traffic in either direction during the last 30 seconds. If it was, assign a longer tentative lifespan of 20 minutes, after which you look again. If the tunnel is not in use, close it 🚪.
The expiring state in the key management system (see Section 3.2.7) handles these timeouts. The timer above may be in the forwarding plane, but then it must be resettable.
The tentative lifespan is independent of re-keying. It's just the moment when the tunnel's future is next considered. (The term lifespan is used here rather than lifetime for this reason.) Unlike re-keying, this tunnel use check is not costly and should happen reasonably frequently 🔁.
A multi-step back-off algorithm is not considered worth the effort here 🙅.
If the security gateway and the client host are the same, and it's not a Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown decisions MAY pay attention to TCP connection status as reported by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is coming. Closing the only TCP connection through a tunnel is a strong hint that no more traffic is expected 🌈.
3.4.2. Teardown and Cleanup 🧼
Teardown should always be coordinated between the two ends of the tunnel by interpreting and sending delete notifications. There's a detailed sub-state in the expired connection state of the key manager that handles retransmits of the delete notifications, but that's considered a keying system detail 🤓.
When you get a delete for the outbound SAs of a tunnel (or some subset of them), tear down the inbound ones too and notify the remote end with a delete. If the local system receives a delete for a tunnel that no longer exists, then two delete messages have crossed paths. Ignore it, because the operation has already been completed. Do not generate any messages in this situation 🙅♀️.
Tunnels are bidirectional entities, even though the low-level protocols don't treat them that way 💜.
When the deletion starts locally instead of as a response to a received delete, send a delete for (all) the inbound SAs of a tunnel. If the local system doesn't receive a responding delete for the outbound SAs, try re-sending the original delete. Three tries spaced 10 seconds apart seems like a reasonable level of effort. If the other end still doesn't respond after 3 attempts, further communication is unlikely. Remove the outgoing SAs. (The remote system may be a mobile node that's no longer present or powered on 📴.)
After re-keying, transmission should switch to the new outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs should be cleared out promptly (a delete should be sent for the outgoing SAs) rather than waiting for them to expire. This reduces clutter and minimizes confusion for the operator doing diagnostics 🧹✨.
4. Impacts on IKE 🔥
4.1. ISAKMP/IKE Protocol 🗝️
The IKE wire protocol needs no modifications. The major changes are implementation issues about how proposals are interpreted and who they may come from 💌.
Opportunistic encryption is designed to be useful between peers without any prior operator configuration, so an IKE daemon must be prepared to negotiate phase 1 SAs with any node. That can take a large amount of resources to maintain cookie state, plus large amounts of entropy for nonces, cookies, and so on 🫠.
The major changes to support opportunistic encryption happen at the IKE daemon level. They cover handling of key acquisition requests, lookup of public keys and TXT records, and interactions with firewalls and other security facilities that may be co-resident on the same gateway 🛡️.
4.2. Gateway Discovery Process 🗺️
In a typical configured tunnel, the address of SG-B is provided via configuration. The mapping of an SPD entry to a gateway is usually 1:1. When the 0.0.0.0/0 SPD entry technique is used, the mapping to a gateway is determined by the reverse DNS records 🔍.
The need to do a DNS lookup and wait for a reply will typically introduce a new state and a new event source (DNS replies) to IKE. A synchronous DNS request can be implemented for proof of concept, but experience shows it can cause very high latencies when a queue of queries has to all time out in series 😵.
An asynchronous DNS lookup also lets DNS lookups overlap with some of the protocol steps 🏃.
4.3. Self Identification 🪪
SG-A will have to establish its identity. Use an IPv4 (IPv6) ID in phase 1.
There are lots of situations where the administrator of SG-A can't control the reverse DNS records for SG-A's public IP address. Typical ones are dialup connections and most residential-type broadband Internet access (ADSL, cable-modem) 🏠. In these cases, a fully qualified domain name that's under the control of SG-A's administrator may be used, but only when acting as an initiator. The FQDN ID should be used in phase 1. See Section 5.3 for more details and restrictions 📝.
4.4. Public Key Retrieval Process 🔑
When a phase 1 SA proposal arrives with either an IPv4 (IPv6) ID or an FQDN ID, the IKE daemon needs to check local caches and configuration files to see if it's part of a configured tunnel. If no configured tunnels are found, the implementation should attempt to retrieve a KEY record from the reverse DNS in the case of an IPv4/IPv6 ID, or from the forward DNS in the case of an FQDN ID 🔎.
It's reasonable for other non-local sources of policy (COPS, LDAP) to be consulted concurrently, but some clear ordering of policy should be provided. Because latency varies, implementations must wait for positive or negative replies from all sources of policy before making any decisions ⏳.
4.5. Interactions with DNSSEC 🔐
The implementation described (FreeS/WAN 1.98) doesn't use DNSSEC directly to explicitly verify the authenticity of zone information, and it doesn't use the NSEC records to authenticate the absence of a TXT or KEY record. Instead, this implementation uses a trusted path to a DNSSEC-capable caching resolver 🤝.
To tell an authenticated DNS resource record apart from an unauthenticated one, a stub resolver capable of returning DNSSEC information MUST be used 💅.
4.6. Required Proposal Types 📜
4.6.1. Phase 1 Parameters
Main mode MUST be used 🎯.
The initiator MUST offer at least one proposal using some combination of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be proposed first. (See [RFC3526])
The initiator MAY offer additional proposals, but the cipher MUST not be weaker than 3DES. The initiator SHOULD limit the number of proposals so that the IKE datagrams don't need to be fragmented 📦.
The responder MUST accept one of the proposals. If any configuration of the responder is required, then the responder is not acting in an opportunistic way 🙌.
The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external interface of the initiator for phase 1. (There is an exception, see Section 5.3.) The authentication method MUST be RSA public key signatures. The RSA key for the initiator SHOULD be placed into a DNS KEY record in the reverse space of the initiator (i.e., using in-addr.arpa or ip6.arpa) 🗂️.
4.6.2. Phase 2 Parameters
The initiator MUST propose a tunnel between the ultimate sender ("Alice" or "A") and the ultimate recipient ("Bob" or "B") using 3DES-CBC mode, MD5, or SHA1 authentication. Perfect Forward Secrecy MUST be specified 🌸.
Tunnel mode MUST be used 🚇.
Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32 🎀.
Authorization for the initiator to act on Alice's behalf is determined by looking for a TXT record in the reverse-map at Alice's IP address 🕵️.
Compression SHOULD NOT be mandatory. It MAY be offered as an option 🫶.
5. DNS Issues 🌐
5.1. Use of KEY Record 🗝️
In order to establish their own identities, security gateways SHOULD publish their public keys in their reverse DNS via DNSSEC's KEY record. See section 3 of RFC 2535 [RFC2535] 📖.
For example, here's a KEY record 👇:
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8Let's break down what each piece means 🧩:
0x4200: the flag bits. They say this key is prohibited for confidentiality use (it only authenticates the peer, since a separate Diffie-Hellman exchange handles confidentiality). They also say this key belongs to the non-zone entity whose name is the RR owner name. No other flags are set 🚫.4: this means the key is for use by IPsec 🔒.1: an RSA key is present 🔑.AQNJjkKlIk9...nYyUkKK8: the public key of the host, as described in [RFC3110] 💖.
Using several KEY records lets you do key roll-over 🔄. The SIG Payload in IKE phase 1 SHOULD be accepted if the public key given by any KEY RR validates it ✨.
5.2. Use of TXT Delegation Record ✨
okay so, if machine Alice wants SG-A to act on her behalf, she publishes a TXT record that authorizes SG-A to do it 💅. Bob and SG-B do the exact same thing 🫶.
These records live in the reverse DNS (in-addr.arpa or ip6.arpa) for their own IP addresses 🌸. The reverse DNS SHOULD be secured by DNSSEC. DNSSEC is required to defend against active attacks, so this is not a "maybe later" situation 😭.
Bestie, do not skip DNSSEC. It is required to defend against active attacks 💀.
If Alice's address is P.Q.R.S, then she can authorize another node to act on her behalf by publishing records at:
S.R.Q.P.in-addr.arpaThe contents of the resource record are expected to be a string that uses the following syntax, as suggested in RFC1464 [RFC1464]. (Note that the reply to query may include other TXT resource records used by other applications.) 🧚
X-IPsec-Server(P)=A.B.C.D public-key
Figure 2: Format of reverse delegation recordHere's the breakdown 🎀:
P: Specifies a precedence for this record. This is similar to MX record preferences. Lower numbers have stronger preference.A.B.C.D: Specifies the IP address of the Security Gateway for this client machine.public-key: Is the encoded RSA Public key of the Security Gateway. The public-key is provided here to avoid a second DNS lookup. If this field is absent, then a KEY resource record should be looked up in the reverse-map of A.B.C.D. The key is transmitted in base64 format.
The fields of the record MUST be separated by whitespace. This MAY be: space, tab, newline, or carriage return. A space is preferred ✨.
In the case where Alice is located at a public address behind a security gateway that has no fixed address (or no control over its reverse-map), then Alice may delegate to a public key by domain name. Main character problem solved 🦋.
X-IPsec-Server(P)=@FQDN public-key
Figure 3: Format of reverse delegation record (FQDN version)P: Is as above.FQDN: Specifies the FQDN that the Security Gateway will identify itself with.public-key: Is the encoded RSA Public key of the Security Gateway.
If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records 🎲.
5.2.1. Long TXT Records 🌈
When packed into wire-format, TXT records that are longer than 255 characters are divided into smaller <character-strings>. (See [RFC1035] section 3.3 and 3.3.14.) These MUST be reassembled into a single string for processing. Whitespace characters in the base64 encoding are to be ignored 🧁.
5.2.2. Choice of TXT Record 🤔
People have suggested using the KEY, OPT, CERT, or KX records instead of a TXT record. Honestly? None of them is satisfying 😭.
The KEY RR has a protocol field that could be used to indicate a new protocol, and an algorithm field that could be used to indicate different contents in the key data. However, the KEY record is clearly not intended for storing what are really authorizations, it is just for identities. Other uses have been discouraged 🙅♀️.
OPT resource records, as defined in [RFC2671], are not intended to be used for storage of information. They are not to be loaded, cached or forwarded. They are, therefore, inappropriate for use here 💀.
CERT records [RFC2538] can encode almost any set of information. A custom type code could be used permitting any suitable encoding to be stored, not just X.509. According to the RFC, the certificate RRs are to be signed internally, which may add undesirable and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers 🙈.
At the time of protocol design, the CERT RR was not widely deployed and could not be counted upon. Use of CERT records will be investigated, and may be proposed in a future revision of this document 👀.
KX records are ideally suited for use instead of TXT records, but had not been deployed at the time of implementation. So close, yet so far 💜.
5.3. Use of FQDN IDs 🎀
Unfortunately, not every administrator has control over the contents of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, the authorization record present in the reverse-map of Alice may refer to a FQDN instead of an IP address 🧚.
In this case, the client's TXT record gives the fully qualified domain name (FQDN) in place of its security gateway's IP address. The initiator should use the ID_FQDN ID-payload in phase 1. A forward lookup for a KEY record on the FQDN must yield the initiator's public key 🔑.
This method can also be used when the external address of SG-A is dynamic 🌸.
If SG-A is acting on behalf of Alice, then Alice must still delegate authority for SG-A to do so in her reverse-map. When Alice and SG-A are one and the same (i.e., Alice is acting as an end-node) then there is no need for this when initiating only 💅.
However, Alice must still delegate to herself if she wishes others to initiate OE to her. See Figure 3 ✨.
5.4. Key Roll-Over 🔄
Good cryptographic hygiene says that one should replace public/private key pairs periodically. Some administrators may wish to do this as often as daily 😳.
Typical DNS propagation delays are determined by the SOA Resource Record MINIMUM parameter, which controls how long DNS replies may be cached. For reasonable operation of DNS servers, administrators usually want this value to be at least several hours, sometimes as a long as a day. This presents a problem: a new key MUST not be used prior to its propagation through DNS 🥲.
This problem is dealt with by having the Security Gateway generate a new public/private key pair, at least MINIMUM seconds in advance of using it. It then adds this key to the DNS (both as a second KEY record and in additional TXT delegation records) at key generation time. Note: only one key is allowed in each TXT record 📝.
When authenticating, all gateways MUST have available all public keys that are found in DNS for this entity. This permits the authenticating end to check both the key for "today" and the key for "tomorrow" 🌅🌙. Note that it is the end which is creating the signature (possesses the private key) that determines which key is to be used 🫶.
6. Network Address Translation Interaction 🌐
There are no fundamentally new issues for implementing opportunistic encryption in the presence of network address translation. Rather, there are only the regular IPsec issues with NAT traversal 🦋.
There are several situations to consider for NAT 👀.
6.1. Co-Located NAT/NAPT 🏠
If a security gateway is also performing network address translation on behalf of an end-system, then the packet should be translated prior to being subjected to opportunistic encryption. This is in contrast to typically configured tunnels, which often exist to bridge islands of private network address space. The security gateway will use the translated source address for phase 2, and so the responding security gateway will look up that address to confirm SG-A's authorization ✨.
In the case of NAT (1:1), the address space into which the translation is done MUST be globally unique, and control over the reverse-map is assumed. Placing of TXT records is possible 💖.
In the case of NAPT (m:1), the address will be the security gateway itself. The ability to get KEY and TXT records in place will again depend upon whether or not there is administrative control over the reverse-map. This is identical to situations involving a single host acting on behalf of itself. For initiators (but not responders), an FQDN-style ID can be used to get around a lack of a reverse-map 🙌.
6.2. Security Gateway behind a NAT/NAPT 🧱
If there is a NAT or NAPT between the security gateways, then normal IPsec NAT traversal problems occur. In addition to the transport problem, which may be solved by other mechanisms, there is the issue of what phase 1 and phase 2 IDs to use. While FQDN could be used during phase 1 for the security gateway, there is no appropriate ID for phase 2. Due to the NAT, the end systems live in different IP address spaces 😵💫.
6.3. End System behind a NAT/NAPT 🙃
If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for another end system to address a packet to this end system. Not only is opportunistic encryption impossible, but it is also impossible for any communication to be initiated to the end system. It may be possible for this end system to initiate such communication. This creates an asymmetry, but this is common for NAPT 🥀.
7. Host Implementations 🖥️
When Alice and SG-A are components of the same system, they are considered to be a host implementation. The packet sequence scenario remains unchanged 🫧.
Components marked Alice are the upper layers (TCP, UDP, the application), and SG-A is the IP layer 🍓.
Note that tunnel mode is still required 👑.
As Alice and SG-A are acting on behalf of themselves, no TXT based delegation record is necessary for Alice to initiate. She can rely on FQDN in a forward map. This is particularly attractive to mobile nodes such as notebook computers at conferences 💻✨. To respond, Alice/SG-A will still need an entry in Alice's reverse-map 🫶.
8. Multi-Homing ✨
okay so if there are multiple paths between Alice and Bob (like the SG-D one in the diagram), then additional DNS records are required to set up authorization 💅
In Figure 1, Alice has two ways out of her network: SG-A and SG-D. Until now we've basically ignored SG-D 🙈 Let's assume there are routers between Alice and her security gateways (the + signs, plus the autonomous system number marking Alice's network). So datagrams can totally head to SG-A or SG-D on their way to Bob 🦋
As long as all the network connections are behaving, it doesn't matter which way the datagrams leave Alice's network. Whichever security gateway they hit, that gateway finds the TXT delegation record in Bob's reverse-map and sets up an SA with SG-B 🔥
SG-B has no problem figuring out that either SG-A or SG-D can speak for Alice, because Alice published two equally weighted TXT delegation records:
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
Figure 4: Multiple gateway delegation example for AliceAlice's routers can now do whatever load sharing they need 🎀 Both SG-A and SG-D send datagrams addressed to Bob through their tunnel to SG-B.
Alice's use of non-equal weights to show she prefers one gateway over another only matters when SG-B is the one initiating to Alice 🧚
If the precedences are the same, SG-B has a harder time 😭 It has to decide which of the two tunnels to use. SG-B has no info about which link is less loaded, or which security gateway has more crypto resources free. Honestly, SG-B doesn't even know whether both gateways are reachable 💀
The Public Internet's default-free zone may well know a good route to Alice, but the datagrams SG-B creates have to be addressed to either SG-A or SG-D. They can not be addressed to Alice directly 🙅♀️
SG-B has a few choices:
- It can ignore the problem and round robin among the tunnels. This causes losses during times when one or the other security gateway is unreachable. If this worries Alice, she can change the weights in her TXT delegation records.
- It can send to the gateway from which it most recently received datagrams. This assumes that routing and reachability are symmetrical.
- It can listen to BGP information from the Internet to decide which system is currently up. This is clearly much more complicated, but if SG-B is already participating in the BGP peering system to announce Bob, the results data may already be available to it.
- It can refuse to negotiate the second tunnel. (It is unclear whether or not this is even an option.)
- It can silently replace the outgoing portion of the first tunnel with the second one while still retaining the incoming portions of both. Thus, SG-B can accept datagrams from either SG-A or SG-D, but send only to the gateway that most recently re-keyed with it.
Local policy decides which choice SG-B makes 🌸 Also, even if SG-B has perfect knowledge about whether SG-A and SG-D are reachable, Alice may still not be reachable from either of them because of internal reachability issues.
FreeS/WAN implements option 5 ✨ A different option is being considered. The multi-homing aspects of OE aren't well developed yet and may be the subject of a future document 🦋
9. Failure Modes
9.1. DNS Failures
okay this one is important 🫶 If a DNS server fails to respond, local policy decides whether or not to allow communication in the clear, as shown in the connection classes in Section 3.2. It is super easy to mount a denial of service attack on the DNS server responsible for a particular network's reverse-map 😬 Such an attack may cause all communication with that network to go in the clear if the policy is permissive, or fail completely if the policy is paranoid. Please note that this is an active attack ⚠️
There are still lots of networks that don't have properly configured reverse-maps 💀 Also, if the policy is not to communicate, the denial of service attack above isolates the target network. So the decision of whether or not to permit communication in the clear MUST be a matter of local policy 🔥
9.2. DNS Configured, IKE Failures
the DNS records claim that opportunistic encryption should occur, but the target gateway either doesn't respond on port 500, or refuses the proposal 😭 This may be because of a crash or reboot, a faulty configuration, or a firewall filtering port 500.
Getting ICMP port, host or network unreachable messages indicates a potential problem, but they MUST NOT cause communication to fail immediately 🙈 ICMP messages are easily forged by attackers. If a forgery caused immediate failure, an active attacker could easily stop any encryption from ever happening, possibly blocking all communication. Not it 💅
In these situations a log should be produced, and local policy should dictate whether communication is then permitted in the clear 🌈
9.3. System Reboots
Tunnels sometimes go down because the remote end crashes, disconnects, or has a network link break 💔 Usually there's no notification of this. Even after a crash and successful reboot, other SGs don't hear about it unless the rebooted SG has a specific reason to talk to them right away. Over-quick response to temporary network outages is undesirable 🙃 Note that a tunnel can be torn down and then re-established with no effect visible to the user except a pause in traffic. On the other hand, if one end reboots, the other end can't get datagrams to it at all (except via IKE) until the situation is noticed. So a bias toward quick response is appropriate, even at the cost of occasional false alarms 🚨
A mechanism for recovery after reboot is a topic of current research and is not specified in this document 🔬
A deliberate shutdown should include an attempt, using delete messages, to notify all other SGs currently connected by phase 1 SAs that communication is about to fail. Again, a remote SG will assume this is a teardown. Attempts by the remote SGs to negotiate new tunnels as replacements should be ignored. When possible, SGs should try to keep information about currently-connected SGs in non-volatile storage, so that after a crash, an Initial-Contact can be sent to previous partners to indicate loss of all previously established connections 🧠
10. Unresolved Issues
10.1. Control of Reverse DNS
the method of getting information by reverse DNS lookup causes problems for people who can't control their reverse DNS bindings 😩 This is an unresolved problem in this version and is out of scope 🦋
11. Examples
11.1. Clear-Text Usage (Permit Policy)
Two example scenarios follow ✨ In the first one, GW-A (Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second they have an OE policy. The clear-text policy is the reference for what happens in TCP/IP when there's no Opportunistic Encryption 🎀
Alice wants to talk to Bob. Maybe she wants to grab a web page from Bob's web server 🌸 Without opportunistic encryptors, these events happen:
Alice SG-A DNS SG-B Bob
Human or application
'clicks' with a name.
(1)
------(2)-------------->
Application looks up
name in DNS to get
IP address.
<-----(3)---------------
Resolver returns "A" RR
to application with IP
address.
(4)
Application starts a TCP session
or UDP session and OS sends
first datagram
Alice SG-A DNS SG-B Bob
----(5)----->
Datagram is seen at first gateway
from Alice (SG-A).
----------(6)------>
Datagram traverses
network.
------(7)----->
Datagram arrives
at Bob, is provided
to TCP.
<------(8)------
A reply is sent.
<----------(9)------
Datagram traverses
network.
<----(10)-----
Alice receives
answer.
Alice SG-A DNS SG-B Bob
(11)----------->
A second exchange
occurs.
----------(12)----->
-------------->
<---------------
<-------------------
<-------------
Figure 5: Timing of regular transaction11.2. Opportunistic Encryption 🦋
okay so, when you've got properly configured opportunistic encryptors around 💅, the event list gets extended. Only the changes are annotated, so you don't have to reread everything 🫶
The time-sequence diagram uses these symbols:
-a single dash is for clear-text datagrams 🌸=an equals sign is for phase 2 (IPsec) cipher-text datagrams 💖~a single tilde is for clear-text phase 1 datagrams ✨#a hash sign is for phase 1 (IKE) cipher-text datagrams 🔮
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->+
----(5B)->
<---(5C)--
~~~~~~~~~~~~~(5D)~~~>
<~~~~~~~~~~~~(5E)~~~~
~~~~~~~~~~~~~(5F)~~~>
<~~~~~~~~~~~~(5G)~~~~
#############(5H)###>
<----(5I)---
-----(5J)-->
<############(5K)####
#############(5L)###>
<----(5M)---
-----(5N)-->
<############(5O)####
#############(5P)###>
============(6)====>
------(7)----->
<------(8)------
<==========(9)======
<-----(10)----
(11)----------->
==========(12)=====>
-------------->
<---------------
<===================
<-------------
Figure 6: Timing of opportunistic encryption transactionOkay, so for this section we're only spilling the tea on what changes between Figure 5 and Figure 6 🍓 That lines up with time points 5, 6, 7, 9, and 10 on the list above.
At point (5), SG-A catches the datagram because this source/destination pair has no policy yet (that's the nonexistent policy state, bestie 💀). SG-A makes a hold policy, buffers the datagram, and asks the keying daemon for keys ✨
- (5B) DNS query for TXT record.
- (5C) DNS response for TXT record.
- (5D) Initial IKE message to responder.
- (5E) Message 2 of phase 1 exchange. SG-B receives the message, and a new connection instance gets created in the unauthenticated OE peer state 🧚
- (5F) Message 3 of phase 1 exchange. SG-A sends a Diffie-Hellman exponent. This is an internal state of the keying daemon.
- (5G) Message 4 of phase 1 exchange. SG-B responds with a Diffie-Hellman exponent. This is an internal state of the keying protocol.
- (5H) Message 5 of phase 1 exchange. SG-A uses the phase 1 SA to send its identity under encryption. The choice of identity is discussed in Section 4.6.1. This is an internal state of the keying protocol 🔐
- (5I) Responder lookup of initiator key. SG-B asks DNS for the public key of the initiator. DNS looks for a KEY record by IP address in the reverse-map. That means a KEY resource record gets queried for
4.1.1.192.in-addr.arpa(recall that SG-A's external address is192.1.1.4). SG-B uses the resulting public key to authenticate the initiator. See Section 5.1 for further details. - (5J) DNS replies with public key of initiator. Once the peer is successfully authenticated, the connection instance transitions to authenticated OE peer on SG-B. The format of the TXT record returned is described in Section 5.2. Then the responder replies with ID and authentication. SG-B sends its ID along with authentication material, which completes the phase 1 negotiation 👑
- (5L) IKE phase 2 negotiation. Having set up mutually agreeable authentications (via KEY) and authorizations (via TXT), SG-A proposes creating an IPsec tunnel for datagrams going from Alice to Bob. This tunnel is established only for the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B 🦋
- (5M) Authorization for SG-A to speak for Alice. The identity of SG-A has been established, but its authority to speak for Alice hasn't been confirmed yet. SG-B does a reverse lookup on Alice's address for a TXT record 🔍
- (5N) Responder determines initiator's authority. A TXT record is returned, and it confirms that SG-A is authorized to speak for Alice. Once SG-B gets this specific proposal, its connection instance transitions into the potential OE connection state. SG-B may already have an instance, and the check is made as described above.
- (5O) Responder agrees to proposal. SG-B, satisfied that SG-A is authorized, goes ahead with the phase 2 exchange. The responder MUST setup the inbound IPsec SAs before sending its reply. 💅
- (5P) Final acknowledgement from initiator. The initiator agrees with the responder's choice of proposal and sets up the tunnel. The initiator sets up the inbound and outbound IPsec SAs. Once this message is received, the responder may now setup the outbound IPsec SAs.
- (6) IPsec succeeds and sets up a tunnel for communication between Alice and Bob 🎀
SG-A sends the datagram saved at step (5) through the newly created tunnel to SG-B, where it gets decrypted and forwarded. Bob receives it at (7) and replies at (8). SG-B already has a tunnel up with G1 and uses it. At (9), SG-B has already set up an SPD entry mapping Bob->Alice via a tunnel, so this tunnel just gets applied. The datagram is encrypted to SG-A, decrypted by SG-A, and handed to Alice at (10) 💜
12. Security Considerations 🚨
12.1. Configured versus Opportunistic Tunnels 🔐
Configured tunnels get set up using bilateral mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that live in known places (distinguished name from LDAP, DNS). Those keys are then used to configure a specific tunnel.
A pre-configured tunnel may be on all the time, or it may only get keyed when it's needed. The endpoints of the tunnel aren't necessarily static, and lots of mobile applications (road warrior) are considered to be configured tunnels 🚗
The main thing is that configured tunnels are assigned specific security properties. They may be trusted in different ways, like exceptions to firewall rules, exceptions to NAT processing, and bandwidth or other quality of service restrictions.
Opportunistic tunnels aren't inherently trusted in any strong way. They get created without prior arrangement. Since the two parties are strangers, there MUST be no confusion of datagrams that arrive from opportunistic peers and those that arrive from configured tunnels. A security gateway MUST take care that an opportunistic peer cannot impersonate a configured peer. 😤
Ingress filtering MUST be used to make sure that only datagrams authorized by negotiation (and the concomitant authentication and authorization) are accepted from a tunnel. This is to prevent one peer from impersonating another.
An implementation suggestion is to treat opportunistic tunnel datagrams as if they arrive on a logical interface distinct from other configured tunnels. The number of opportunistic tunnels that can get created automatically on a system is potentially very high, so careful attention to scaling should be taken into account 📈
As with any IKE negotiation, opportunistic encryption cannot be secure without authentication. Opportunistic encryption relies on DNS for its authentication information and, therefore, cannot be fully secure without a secure DNS. Without secure DNS, opportunistic encryption can protect against passive eavesdropping but not against active man-in-the-middle attacks. This is a big deal, bestie, so don't skip it 🙈
12.2. Firewalls versus Opportunistic Tunnels 🧱
Typical usage of per datagram access control lists is to implement various kinds of security gateways. These are typically called "firewalls".
Typical usage of a virtual private network (VPN) within a firewall is to bypass all or part of the access controls between two networks. Additional trust (as outlined in the previous section) is given to datagrams that arrive in the VPN.
Datagrams that arrive via opportunistically configured tunnels MUST not be trusted. Any security policy that would apply to a datagram arriving in the clear SHOULD also be applied to datagrams arriving opportunistically. 🚫
12.3. Denial of Service 🌊
There are several different forms of denial of service that an implementor should be concerned with. Most of these problems are shared with security gateways that have large numbers of mobile peers (road warriors).
The design of ISAKMP/IKE, and its use of cookies, defends against many kinds of denial of service. Opportunism changes the assumption that if the phase 1 (ISAKMP) SA is authenticated, it was worthwhile creating. Because the gateway will communicate with any machine, it is possible to form phase 1 SAs with any machine on the Internet. Bestie, that's a whole vibe shift 😭
13. Acknowledgements 🫶
Substantive portions of this document are based upon previous work by Henry Spencer. [OEspec]
Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore, and John Denker for their comments and constructive criticism 💖
Sandra Hoffman and Bill Dickie did the detailed proof reading and editing 🌈
14. References 📚
14.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.14.2. Informative References ✨
okay so these are the "good to know" pile 💅 not required reading to implement, but they're the receipts behind the ideas, and they're really worth a peek 🦋
[IPSECKEY] Richardson, M., "A Method for Storing IPsec keying
Material in DNS", RFC 4025, March 2005.
[OEspec] H. Spencer and Redelmeier, D., "Opportunistic Encryption",
paper, http://www.freeswan.org/
oeid/opportunism-spec.txt, May 2001.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG
Statement on Cryptographic Technology and the Internet",
RFC 1984, August 1996.
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management
API, Version 2", RFC 2367, July 1998.
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.Authors' Addresses 🎀
these are the people who wrote it, so you know exactly who to thank (or question) 🌸
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
D. Hugh Redelmeier
Mimosa Systems Inc.
29 Donino Avenue
Toronto, ON M4N 2W6
CA
EMail: hugh@mimosa.comFull Copyright Statement ⭐
the legal bit, but it's still part of the doc so here it is in full 🫶
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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's whole vibe on patents and rights, in its own words 🍓
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 🧚
and last but not least, who keeps the lights on ✨
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc4322 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms