3 Network Working Group M. Richardson
5 Expires: August 22, 2002 D. Redelmeier
12 A method for doing opportunistic encryption with IKE
13 draft-richardson-ipsec-opportunistic-06.txt
17 This document is an Internet-Draft and is in full conformance with
18 all provisions of Section 10 of RFC2026.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at http://
31 www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on August 22, 2002.
40 Copyright (C) The Internet Society (2002). All Rights Reserved.
55 Richardson, et al. Expires August 22, 2002 [Page 1]
57 Internet-Draft opportunistic February 2002
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6
63 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
64 1.2 Types of network traffic . . . . . . . . . . . . . . . . 6
65 1.3 Peer authentication in Opportunistic Encryption . . . . 7
66 1.4 Use of RFC2119 terms . . . . . . . . . . . . . . . . . . 8
67 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
68 2.1 Reference diagram . . . . . . . . . . . . . . . . . . . 9
69 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . 9
70 2.3 Model of Operation . . . . . . . . . . . . . . . . . . . 11
71 2.3.1 Tunnel Authorization . . . . . . . . . . . . . . . . . . 11
72 2.3.2 Tunnel End-point discovery . . . . . . . . . . . . . . . 11
73 2.3.3 Caching of authorization results . . . . . . . . . . . . 12
74 3. Specification . . . . . . . . . . . . . . . . . . . . . 13
75 3.1 Datagram State Machine . . . . . . . . . . . . . . . . . 13
76 3.1.1 Nonexistent policy . . . . . . . . . . . . . . . . . . . 13
77 3.1.2 Hold policy . . . . . . . . . . . . . . . . . . . . . . 13
78 3.1.3 Pass-through policy . . . . . . . . . . . . . . . . . . 13
79 3.1.4 Deny policy . . . . . . . . . . . . . . . . . . . . . . 14
80 3.1.5 Encrypt policy . . . . . . . . . . . . . . . . . . . . . 14
81 3.2 Keying State Machine - Initiator . . . . . . . . . . . . 14
82 3.2.1 Nonexistent connection . . . . . . . . . . . . . . . . . 15
83 3.2.2 clear-text connection . . . . . . . . . . . . . . . . . 15
84 3.2.3 Deny connection . . . . . . . . . . . . . . . . . . . . 16
85 3.2.4 Potential OE connection . . . . . . . . . . . . . . . . 16
86 3.2.4.1 Restriction on unauthentication TXT delegation records . 17
87 3.2.5 Pending OE connection . . . . . . . . . . . . . . . . . 17
88 3.2.6 Keyed connection . . . . . . . . . . . . . . . . . . . . 18
89 3.2.7 Expiring connection . . . . . . . . . . . . . . . . . . 19
90 3.2.8 Expired connection state . . . . . . . . . . . . . . . . 19
91 3.3 Keying State Machine - Responder . . . . . . . . . . . . 19
92 3.3.1 Unauthenticated OE peer state . . . . . . . . . . . . . 20
93 3.3.2 Authenticated OE Peer . . . . . . . . . . . . . . . . . 20
94 3.4 Renewal and Teardown . . . . . . . . . . . . . . . . . . 20
95 3.4.1 Aging . . . . . . . . . . . . . . . . . . . . . . . . . 20
96 3.4.2 Teardown and Cleanup . . . . . . . . . . . . . . . . . . 22
97 4. Impacts on IKE . . . . . . . . . . . . . . . . . . . . . 23
98 4.1 ISAKMP/IKE protocol . . . . . . . . . . . . . . . . . . 23
99 4.2 Gateway discovery process . . . . . . . . . . . . . . . 23
100 4.3 Self identification . . . . . . . . . . . . . . . . . . 23
101 4.4 Public key Retrieval process . . . . . . . . . . . . . . 24
102 4.5 Interactions with DNSSEC . . . . . . . . . . . . . . . . 24
103 4.6 Recommended proposal types . . . . . . . . . . . . . . . 24
104 4.6.1 Phase 1 parameters . . . . . . . . . . . . . . . . . . . 24
105 4.6.2 Phase 2 parameters . . . . . . . . . . . . . . . . . . . 25
106 5. DNS issues . . . . . . . . . . . . . . . . . . . . . . . 26
107 5.1 Use of KEY record . . . . . . . . . . . . . . . . . . . 26
111 Richardson, et al. Expires August 22, 2002 [Page 2]
113 Internet-Draft opportunistic February 2002
116 5.2 Use of TXT delegation record . . . . . . . . . . . . . . 26
117 5.2.1 Choice of TXT record . . . . . . . . . . . . . . . . . . 28
118 5.3 Use of FQDN IDs . . . . . . . . . . . . . . . . . . . . 28
119 6. Network Address Translation interaction . . . . . . . . 30
120 6.1 Colocated NAT/NAPT . . . . . . . . . . . . . . . . . . . 30
121 6.2 SG-A behind NAT/NAPT . . . . . . . . . . . . . . . . . . 30
122 6.3 Bob is behind a NAT/NAPT . . . . . . . . . . . . . . . . 30
123 7. Host implementations . . . . . . . . . . . . . . . . . . 32
124 8. Multihoming . . . . . . . . . . . . . . . . . . . . . . 33
125 9. Failure modes . . . . . . . . . . . . . . . . . . . . . 35
126 9.1 DNS failures . . . . . . . . . . . . . . . . . . . . . . 35
127 9.2 DNS configured, IKE failures . . . . . . . . . . . . . . 35
128 9.3 System reboots . . . . . . . . . . . . . . . . . . . . . 35
129 10. Unresolved issues . . . . . . . . . . . . . . . . . . . 37
130 10.1 Control of reverse DNS . . . . . . . . . . . . . . . . . 37
131 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 38
132 11.1 Clear-text usage (permit policy) . . . . . . . . . . . . 38
133 11.2 Opportunistic Encryption . . . . . . . . . . . . . . . . 39
134 11.2.1 (5) IPsec packet interception . . . . . . . . . . . . . 41
135 11.2.2 (5B) DNS lookup for TXT record . . . . . . . . . . . . . 41
136 11.2.3 (5C) DNS returns TXT record(s) . . . . . . . . . . . . . 41
137 11.2.4 (5D) Initial IKE Main Mode Packet goes out . . . . . . . 41
138 11.2.5 (5E1) Message 2 of phase 1 exchange . . . . . . . . . . 41
139 11.2.6 (5E2) Message 3 of phase 1 exchange . . . . . . . . . . 42
140 11.2.7 (5E3) Message 4 of phase 1 exchange . . . . . . . . . . 42
141 11.2.8 (5E4) Message 5 of phase 1 exchange . . . . . . . . . . 42
142 11.2.9 (5F1) Responder lookup of initiator key . . . . . . . . 42
143 11.2.10 (5F2) DNS replies with public key of initiator . . . . . 42
144 11.2.11 (5E5) Responder replies with ID and authentication . . . 42
145 11.2.12 (5G) IKE phase 2 . . . . . . . . . . . . . . . . . . . . 42
146 11.2.12.1 (5G1) Initiator proposes tunnel . . . . . . . . . . . . 42
147 11.2.12.2 (5H1) Responder determines initiator's authority . . . . 43
148 11.2.12.3 (5H2) DNS replies with TXT record . . . . . . . . . . . 43
149 11.2.12.4 (5G2) Responder agrees to proposal . . . . . . . . . . . 43
150 11.2.12.5 (5G3) Final acknowledgement from initiator . . . . . . . 43
151 11.2.13 (6) IPsec succeeds, sets up tunnel for communication
152 between Alice and Bob . . . . . . . . . . . . . . . . . 43
153 11.2.14 (9) SG-B already has tunnel up with G1, uses it . . . . 43
154 12. Security Considerations . . . . . . . . . . . . . . . . 45
155 12.1 Configured vs Opportunistic Tunnels . . . . . . . . . . 45
156 12.2 Firewalls vs Opportunistic Tunnels . . . . . . . . . . . 46
157 12.3 Denial of Service . . . . . . . . . . . . . . . . . . . 46
158 13. IANA Considerations . . . . . . . . . . . . . . . . . . 47
159 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 48
160 References . . . . . . . . . . . . . . . . . . . . . . . 49
161 Authors' Addresses . . . . . . . . . . . . . . . . . . . 50
162 Full Copyright Statement . . . . . . . . . . . . . . . . 52
167 Richardson, et al. Expires August 22, 2002 [Page 3]
169 Internet-Draft opportunistic February 2002
174 This document describes opportunistic encryption using IKE and IPsec.
175 The objective is to allow encryption without any pre-arrangement
176 specific to the pair of gateways involved. Each gateway
177 administrator makes local arrangements to support opportunistic
178 encryption. Once that is done, any two such gateways can communicate
181 There are two large payoffs. First, if many machines must
182 communicate securely, this approach reduces administrative overhead
183 to order N (number of gateways), rather than the N squared cost to
184 configure each tunnel separately. Second, it becomes possible to
185 make secure communication the default, even when the partner is not
188 There are naturally some risks and some costs, which are described.
190 This document is offered up as an Informational RFC.
223 Richardson, et al. Expires August 22, 2002 [Page 4]
225 Internet-Draft opportunistic February 2002
232 The objective of opportunistic encryption is to allow encryption
233 without any pre-arrangement specific to the pair of gateways
234 involved. Each gateway administrator makes local arrangements --
235 specifically, adds public key information to DNS records -- to
236 support opportunistic encryption and then enables this feature in the
237 nodes' IPsec stack. Once that is done, any two such nodes can
238 communicate securely.
240 This document describes opportunistic encryption as designed and (to
241 date, partially) implemented by the Linux FreeS/WAN project. For
242 project information, see www.freeswan.org.
244 The Internet Architecture Board (IAB) and Internet Engineering
245 Steering Group have taken a strong stand that the Internet should
246 use powerful encryption to provide security and privacy [4]. This
247 project attempts to put this policy into practice by providing
248 practical means to implement them.
250 The project believes that the IPsec protocols are the best chance to
251 do that, because they are standardized, widely available and can
252 often be deployed very easily, without changing hardware or software
253 or retraining of users. However, the extension to opportunistic
254 encryption seems necessary, both to help control administrative
255 overheads and to get IPsec more widely used.
257 The use of "opportunistic encryption" offers the "fax effect". As
258 each person installs one for their own use, it becomes more valuable
259 for their neighbors to install one too, because there's one more
260 person to use it with. The software automatically notices each newly
261 installed box, and doesn't require a network administrator to
264 This document describes the infrastructure needed to support this
267 The term S/WAN is a trademark of RSA Data Systems, and is used with
268 permission by this project.
270 1.2 Types of network traffic
272 To aid in understand the relationship between security processing and
273 IPsec we divide network traffic into four categories:
275 deny networks to which traffic is always forbidden
279 Richardson, et al. Expires August 22, 2002 [Page 5]
281 Internet-Draft opportunistic February 2002
284 permit networks to which traffic in the clear is desired
286 opportunistic tunnel networks to which encryption should be done
287 if possible, but communication is done in the clear otherwise
289 configured tunnel networks to which encryption must be done, and
290 communication is never in the clear
292 This document describes the third category. The first two categories
293 are provided by traditional firewall devices. The fourth category is
294 presently the offering of many Virtual Private Network (VPN) devices.
296 Category one, denied traffic by IP address, requires no
299 Category two, permitted traffic by IP address, requires no
300 authentication. This is the normal default on the Internet.
302 Category four, encrypt traffic or drop it, requires authentication of
303 the end points. As the number of end points is typically bounded and
304 is typically under the a single authority, arranging for distribution
305 of authentication material, while difficult, does not require any new
308 The mechanism described here provides an additional way to distribute
309 the authentication materials, notably a public key method that does
310 not require deployment of an X.509 based infrastructure.
312 1.3 Peer authentication in Opportunistic Encryption
314 Opportunistic encryption involves creating tunnels with other nodes
315 that are essentially strangers. This is done without any prior
316 bilateral arrangement. There is therefore the difficult question of
317 how does one know who one is talking to.
319 One possible answer is that one does not know who one is talking to.
320 No useful authentication can be done, so do not even try. This mode
321 of operation has been given the name "anonymous encryption". A man-
322 in-the-middle attack can be used to thwart the privacy of this
323 communication. This would be an active attack. Without peer
324 authentication, there is no way to prevents this kind of attack.
326 Although a useful mode, it is not the goal of this project. It is a
327 useful starting point, but the system should permit additional layers
328 of trust to be built upon this system. In the described system, the
329 anonymous encryption case is what results without DNSSEC. Were
330 anonymous encryption the end goal, simpler methods are available to
335 Richardson, et al. Expires August 22, 2002 [Page 6]
337 Internet-Draft opportunistic February 2002
340 However, an essential premise of building private connections with
341 strangers is that datagrams received through these opportunistic
342 tunnels are no more special than datagrams that arrived in the clear.
344 Unlike in a VPN scenario, these datagrams should not be given any
345 special exceptions when it comes to auditing, further authentication
348 On the outbound side, when initiating opportunistic encryption, it
349 becomes a local matter what to do if one fails to setup a tunnel. It
350 may be that the packet goes out in the clear, or it may be dropped.
351 This is a local configuration matter.
353 In sum, we gain wider privacy (for the Internet at large) at minimal
354 cost: the cost is the need to reassess assumptions about the
355 relationship between IPsec authentication and further local access
358 1.4 Use of RFC2119 terms
360 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
361 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
362 document, are to be interpreted as described in [5]
391 Richardson, et al. Expires August 22, 2002 [Page 7]
393 Internet-Draft opportunistic February 2002
398 2.1 Reference diagram
400 ---------------------------------------------------------------------
402 The following network diagram is used in the rest of this document as
403 the canonical diagram
407 [A]----+----[SG-A]...+....+....[SG-B]-------[B]
409 [D]----+----[SG-D]...+ +....[C] AS3
413 Figure 1: Reference Network Diagram
415 ---------------------------------------------------------------------
417 In this diagram, there are four end-nodes: A, B, C and D. There are
418 three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part of
419 the same administrative authority. SG-A and SG-D are on two
420 different exit paths from organization 1. SG-B/B is an independent
421 organizations. Nodes Q and R are nodes that are on the Internet. PI
422 is the Public Internet ("The Wild").
426 The following terminology is used in this document:
428 security gateway: a system that performs IPsec tunnel mode
429 encapsulation/decapsulation. [SGx] in the diagram
431 Alice: node [A] in the diagram. When an IP address is needed,
434 Bob: node [B] in the diagram. When an IP address is needed, this
437 Carol: node [C] in the diagram. When an IP address is needed,
440 Dave: node [D] in the diagram. When an IP address is needed, this
443 SG-A Alice's security gateway. Internally it is 192.1.0.1,
447 Richardson, et al. Expires August 22, 2002 [Page 8]
449 Internet-Draft opportunistic February 2002
452 externally it is 192.1.1.4.
454 SG-B Bob's security gateway. Internally it is 192.2.0.1,
455 externally it is 192.1.1.5.
457 SG-D Dave's security gateway. Also Alice's backup security
458 gateway. Internally it is 192.3.0.1, externally it is
461 - a single dash represents clear-text datagrams
463 = an equals sign represents phase 2 (IPsec) cipher-text datagrams
465 # a hash sign represents phase 1 (IKE) cipher-text datagrams
467 . a period represents an untrusted network of unknown type
469 configured tunnel: Contrast with opportunistic tunnel. A tunnel
470 that is directly/deliberately/hand configured on participating
471 gateways. Configured tunnel are typically given a higher level
472 of trust than opportunistic tunnels.
474 road warrior tunnel: a configured tunnel connecting one node with
475 a fixed IP address and one node with a variable IP address. A
476 road warrior (RW) connection must be initiated by the variable
477 node, since the fixed node does not know what the address for
478 the "road warrior" currently is.
480 anonymous encryption: The process of encrypting a session without
481 any knowledge of who the other parities are. That is, no
482 authentication of identities is done.
484 opportunistic encryption: The process of encrypting a session with
485 authenticated knowledge of who the other parties are.
487 lifetime: The negotiated period in seconds (bytes or datagrams)
488 which a security association will remain alive before needing
491 lifespan: The effective time which a security association remains
492 useful. A security association with a lifespan shorter than
493 its lifetime would be removed when no longer needed. A
494 security association with a lifespan longer than its lifetime
495 would need to be re-keyed one or more times.
497 phase 1 SA an ISAKMP/IKE security association, sometimes also
498 referred to as a keying channel.
503 Richardson, et al. Expires August 22, 2002 [Page 9]
505 Internet-Draft opportunistic February 2002
508 phase 2 SA an IPsec security association
510 tunnel another term for a set of phase 2 SA (one in each
513 NAT Network Address Translation (see [20])
515 NAPT Network Address and Port Translation (see [20])
517 default-free zone The set of routers that maintain a complete set
518 of routes to all currently reachable destinations. Having such
519 a list, these routers never make use of a default route. A
520 datagram with a destination address not matching any route will
521 be dropped by such a router.
524 2.3 Model of Operation
526 The Opportunistic Encryption security gateway ("OE gateway") is a
527 regular gateway node as described in [2] section 2.4 and [3] with
528 additional capabilities described here and in [7]. The algorithm
529 described here provides a way to determine, for each datagram,
530 whether or not to apply an encrypting tunnel transformation to the
531 datagram. Thus, two important things that must be determined are
532 whether or not to tunnel and, if so, to which destination.
534 The OE gateway must also be capable of responding to other OE
535 gateways as a receiver.
537 2.3.1 Tunnel Authorization
539 The decision as to whether or not to create a tunnel is determined on
540 a per-destination address basis. Upon receiving a packet with a
541 destination address not recently seen, the OE gateway performs a
542 lookup in DNS for an authorization record (see Section 5.2). This
543 record is located using the IP address to perform a search in the in-
544 addr.arpa (IPv4) or ip6.arpa (IPv6) maps. The presence of an
545 authorization record indicates the desire for a tunnel to be formed.
547 2.3.2 Tunnel End-point discovery
549 The record further provides the address or name of the end-point
550 which should be used.
552 The record may also provide the public RSA key of the tunnel end
553 point itself. This is provided for efficiency only - if this is not
554 present, then the address or name provided is used to perform a
555 second lookup to find a KEY Resource Record.
559 Richardson, et al. Expires August 22, 2002 [Page 10]
561 Internet-Draft opportunistic February 2002
564 DNSSEC ([16]) SHOULD be used to provide origin and integrity
565 protection of the Resource Records involved. Section Section 3.2.4.1
566 documents a restriction on the tunnel end point if DNSSEC signatures
567 are not available for the relevant records.
569 2.3.3 Caching of authorization results
571 The OE gateway MUST maintain a list of source/destination pairs for
572 which Opportunistic Encryption has been attempted for a period of
573 time. Successful discovery of a tunnel end point SHOULD result in
574 creation of a new security association bundle between the OE gateway
575 and the discovered tunnel end point.
577 Failure to discover an appropriate authorization MUST result in
578 creation of a forwarding policy entry to either drop or transmit in
579 the clear future datagrams. This negative cache is necessary so as
580 to avoid repeatedly looking up the same information, a possibly
583 OE gateways MUST time out all cache entries (both positive and
584 negative ones) periodically. This is done both to remove entries
585 which are no longer necessary, and to permit changes in authorization
586 policy to be discovered.
615 Richardson, et al. Expires August 22, 2002 [Page 11]
617 Internet-Draft opportunistic February 2002
622 The OE gateway is modeled to have a forwarding plane and a control
623 plane. They are connected by a control channel such as PF_KEY. (See
624 [6]) The forwarding plane performs per-datagram operations. The
625 control plane contains a keying daemon such as ISAKMP/IKE and
626 performs all authorization, authentication and key derivation
629 3.1 Datagram State Machine
631 Let the OE gateway maintain a collection of objects -- a superset of
632 the Security Policy Database specific in [7]. For each combination
633 of source and destination address, one may find an SPD object in one
634 of six states. Prior to forwarding each datagram, the source and
635 destination addresses are used to pick an entry from the SPD. The
636 SPD then determines how, and if, the packet is forwarded.
638 3.1.1 Nonexistent policy
640 If there is no entry found, then this policy applies. An entry is
641 created with an initial state of "Hold policy". A request for keying
642 material is sent to the keying daemon. The datagram is not
643 forwarded, rather it is attached to the SPD entry as the "first"
644 datagram and retained for eventual transmission in a new state.
648 A request for keying has been previously made. If the interface to
649 the keying system is lossy (PF_KEY, for instance, can be) a mechanism
650 to retransmit the keying request, rate limited to less than 1 request
651 per second SHOULD be made. The datagram is not forward. The
652 datagram is attached to the SPD entry as the "last" datagram and
653 retained for eventual transmission. If there was previously a
654 datagram so stored, then it is discarded.
656 The retention of the first attempts to avoid waiting for a TCP
657 retransmit, as the first datagram is probably a TCP SYN packet. The
658 retention of the last datagram as well applies to streaming
659 protocols, where it is useful to know how much data has been lost.
660 These are recommendations.
662 3.1.3 Pass-through policy
664 The datagram is forwarded using the normal forwarding table. This
665 state is entered only via command from the keying daemon. Upon
666 entering this state, the "first" and "last" datagrams are forwarded.
671 Richardson, et al. Expires August 22, 2002 [Page 12]
673 Internet-Draft opportunistic February 2002
678 The datagram is discarded. This state is entered only via command
679 from the keying daemon. Upon entering this state, the "first" and
680 "last" datagrams are discarded. It is a local matter if further
681 datagrams cause ICMP messages to be generated (i.e. ICMP
682 Administratively denied).
686 The datagram is encrypted using the indicated Security Association
687 Database (SAD) entry. This state is entered only via command from
688 the keying daemon. Upon entering this state, the "first" and "last"
689 datagrams are using the new encrypt policy.
691 If the associated SAD entry expires (due to byte, packet or time
692 limits) then the entry returns to the Hold policy, causing an expire
693 message to communicated to the keying daemon. All states may be
694 created directly by the keying daemon while acting as a responder.
696 3.2 Keying State Machine - Initiator
698 Let the keying daemon maintain a collection of objects -- let them be
699 called "connections" (or "conn"s for short). There are two
700 categories of connection objects: classes and instances. A class
701 connection represents an abstract policy - what could be. An
702 instance represents an actual connection, what is in fact implemented
705 Let there be two further subtypes of connections: keying channels
706 (aka Phase 1 SAs) and data channels (aka Phase 2 SAs). Each data
707 channel object may have a corresponding SPD and SAD entry maintained
708 by the Datagram State Machine.
710 For the purposes of Opportunistic Encryption, there MUST at least be
711 connection classes known as "deny", "always-clear-text", "OE-
712 permissive", "OE-paranoid". The later two connection classes defines
713 a set of source and/or destination addresses for which Opportunistic
714 Encryption will be attempted. There are a number of additional
715 places where the administrator MAY set policy options. An
716 implementation MAY create additional connection classes so that these
717 policies may be enacted in a more fine grained fashion.
719 {should the additional classes be given names here? - ed.}
721 The simplest system may need only the "OE-permissive" connection, and
722 would list its own (single) IP address as the source address of this
723 policy, and the wild-card address 0.0.0.0/0 as the destination IPv4
727 Richardson, et al. Expires August 22, 2002 [Page 13]
729 Internet-Draft opportunistic February 2002
732 address. That is, the simplest policy is to try Opportunistic
733 Encryption with all destinations.
735 The distinction between permissive and paranoid OE use will become
736 clear in the state transition differences. In general, a permissive
737 OE will, on failure, install a pass-through policy, while a paranoid
738 OE will, on failure, install a drop policy.
740 In this description of the keying machines state transitions, the
741 states associated with the keying system itself are omitted. This is
742 done for two reasons: they are best documented in the keying system
743 ([8], [9] and [10] for ISAKMP/IKE), and the details are keying system
744 specific. Opportunistic Encryption is not dependent upon any
745 specific keying protocol, but this document does provide requirements
746 for those using ISAKMP/IKE to assure inter-operability.
748 The state transitions that may be involved in communicating with the
749 forwarding plane are omitted. PF_KEY and similar protocols have
750 their own state of states required for message sends and completion
753 Finally, the retransmits and recursive lookups that are normal for
754 DNS are not included in this state machine.
756 3.2.1 Nonexistent connection
758 There is no connection for a given source/destination address pair.
759 Upon receipt of a request for keying material for this particular
760 source/destination pair, a search is made through the connection
761 classes to determine the most appropriate policy. Upon determining
762 an appropriate connection class, then an instance object is created
763 of that type. Both of the OE types results in a Potential OE
766 Failure to find an appropriate connection class results in an
767 administrator defined default.
769 In each case, when an appropriate class is found for the new flow
770 then an instance connection is made of the type which matched.
772 3.2.2 clear-text connection
774 A transition is made from the empty connection to this state when an
775 instance of the always-clear-text class is instantiated, or when an
776 OE-permissive connection fails. During the transition, a pass-
777 through policy object is created in the forwarding plane for the
783 Richardson, et al. Expires August 22, 2002 [Page 14]
785 Internet-Draft opportunistic February 2002
788 The only way to leave this state is due to a timeout; see expiry
791 3.2.3 Deny connection
793 A transition is made from the empty connection to this state when an
794 instance of the deny class is instantiated, or when an OE-paranoid
795 connection fails. During the transition, a deny policy object is
796 created in the forwarding plane for the appropriate flow.
798 The only way to leave this state is due to a timeout; see expiry
801 3.2.4 Potential OE connection
803 A transition is made from the empty connection to this state when an
804 instance of either OE class is instantiated. During the transition
805 to this state, a hold policy object is created in the forwarding
806 plane for the appropriate flow.
808 In addition, when transitioning into this state, DNS lookup(s) are
809 done in the reverse map for a TXT delegation resource record. (see
810 Section 5.2) The destination address of the flow is used as the
813 There are three ways to exit this state: due a timeout in the DNS
814 lookup, and via positive or negative replies as to the existence of
815 the TXT delegation resource record.
817 If there is a resource record found, and it is properly formatted,
818 and if DNSSEC is enabled - the signature has been vouches for (either
819 through local confirmation or via trusted path to a recursive DNSSEC
820 server), then there is a transition to the Pending OE connection
821 state. (Note that if the public key is not presented in the TXT
822 delegation record, then it must be looked up as well as a sub-state.
823 The DNS lookups are not considered a success until all have completed
826 If there is no resource record found, or DNS times out then it is to
827 be considered that this is not an OE capable receiver. If this was
828 an OE-paranoid instance, then there is a transition to the deny
829 connection. If this was an OE-permissive instance, then there is a
830 transition to the clear-text connection.
832 If the resource record is found but is misformed, or if DNSSEC has
833 been enabled and reports a failure to authenticate, then there should
834 be a transition to the deny connection. This fact should be logged.
835 If the administrator wishes to override this, then an always-clear
839 Richardson, et al. Expires August 22, 2002 [Page 15]
841 Internet-Draft opportunistic February 2002
844 class can be installed for this flow. An implementation MAY make
845 this situation a new class.
847 3.2.4.1 Restriction on unauthentication TXT delegation records
849 An implementation SHOULD also provide an additional administrative
850 control on delegation records and DNSSEC. This control would apply
851 to delegation records (the TXT records in the reverse map) that are
852 not protected by DNSSEC. Records of this type are only permitted to
853 delegate to their own address as a gateway. When this option is
854 enabled, an active attack on DNS will be unable to redirect packets
855 to other than the original destination.
857 3.2.5 Pending OE connection
859 A transition is made from the Potential OE connection to this state
860 when it has been determined that we have all the information from DNS
861 we would need, and should make an attempt to do keying for this
862 connection. Upon entering this state, an attempt to initiate keying
863 to the gateway provided is started.
865 One exits from this state either with a successfully created IPsec
866 SA, or with a failure of some kind. Successful SA creation results
867 in a transition to the Key connection state.
869 There are three failures which are distinguished. They are clearly
870 not the only possible failures from keying, but these are the ones
871 that have caused the most problems.
873 Note that if there were multiple gateways available in the TXT
874 delegation records, then a failure can only be declared after all
875 have been tried. Further, creation of a phase 1 SA does not
876 constitute success - a set of phase 2 SAs (a tunnel) is considered
879 The first failure is when an ICMP port unreachable is consistently
880 received without any other communication, or when there is silence
881 from the remote end. This likely means that the gateway is either
882 not alive, or that the keying daemon is not functional. For an OE-
883 permissive connection, transition to the clear-text connection, but
884 with a rather low lifespan. The gateway may be in the process of
885 rebooting, etc. For an OE-pessimistic connection, transition to the
886 deny connection, again with a low lifespan.
888 How long is long enough to wait for the remote keying daemon to wake
889 up is a matter of some debate. 5 minutes is usually long enough for
890 the network to reconverge if there is a routing failure. Many
891 systems can reboot in that time as well. However, 5 minutes is far
895 Richardson, et al. Expires August 22, 2002 [Page 16]
897 Internet-Draft opportunistic February 2002
900 too long for most users to wait to hear that they can not connect
901 with OE. Implementations SHOULD make this a tuneable parameter.
903 If a phase 1 SA is created, but there is either no response to the
904 phase 2 proposal, or a negative notify (the notify must be
905 authenticated) is received, then the remote gateway is not prepared
906 to do OE at this time. As before transition to clear-text/deny based
907 upon connection class, but this time with a normal lifespan.
909 The third type of failure is when there is signature failure
910 authenticating the remote gateway. In this case, again transition to
911 clear-text/deny based upon the connection class, but make the timeout
912 depend upon the remaining time to live in the DNS. (Note that DNSSEC
913 signed resource records have a different expiry time from non-signed
914 records) One possibility is that there has been a key roll-over, but
915 that DNS has not caught up.
917 3.2.6 Keyed connection
919 A transition is made from the Pending OE connection to this state
920 when session keying material (aka the phase 2 SA) has been formed.
921 An Encrypt Policy is created in the forwarding plane for this flow.
923 There are three ways to exit this state. The first is by receipt of
924 an authenticated delete message (via the keying channel) from the
925 peer. This is normal teardown, and results in a transition to
928 The second way is by expiry of the forwarding plane keying material.
929 This causes a re-key operation to be started with a transition back
930 to Pending OE connection. In general, the soft expiry will occur
931 with sufficient time left for the keys to continue to be used. Note
932 that a re-key can fail, which may result in the connection failing to
933 clear-text or deny as appropriate. Note that the forwarding plane
934 policy does not change until the rekeying attempt has failed or
937 The third way is via respond to a negotiation from a remote gateway,
938 via receipt of a indication from the forwarding plane of having
939 received unknown SPI from the gateway, or an ICMP from the remote
940 gateway indicating an unknown SPI. Each of these things should be
941 considered a hint that the remote gateway has rebooted or restarted.
942 Since these can easily be forged, care muyst be exercised. A
943 cautious (rate-limited) attempt to re-key the connection should be
951 Richardson, et al. Expires August 22, 2002 [Page 17]
953 Internet-Draft opportunistic February 2002
956 3.2.7 Expiring connection
958 Each of the deny, clear-text, and keyed connections will periodically
959 be placed into this sub-state. See Section 3.4 for more details of
960 how often this occurs. The forwarding plane is queried for last use
961 time of the appropriate policy. If the use time is relatively
962 recent, then the state returns to the previous deny, clear-text or
963 keyed connection state. If not, then it enters the expired
966 The DNS query and answer that lead to the state in question is also
967 examined. It may have become stale. (A negative, i.e. no such
968 record answer is valid for the period of time given by the MINIMUM
969 field in an attached SOA record. See [13] section 4.3.4) If it has
970 become stale, then a new query is made. If a change in the results
971 are seen, then a transition to a new state is made as described in
972 Potential OE connection state.
974 Note that both outgoing SPD and incoming SAD must be queried as some
975 flows may be unidirectional for some time.
977 Note that the policy at the forwarding plane is not updated unless
978 there is a conclusion that there should be a change.
980 3.2.8 Expired connection state
982 Entry to this state is due to no datagrams being forwarded recently
983 via the appropriate SPD and SAD objects. The objects in the
984 forwarding plane are removed (logging any final byte and packet
985 counts if appropriate) and the connection instance in the keying
988 An ISAKMP/IKE Delete is sent to clean up the phase 2 SAs as described
991 A difficult question has been whether or not to also delete the phase
992 1 SAs at this time. This is left as a local implementation issue.
993 Implementations that do delete the phase 1 SAs MUST send
994 authenticated Delete messages to indicate that they are doing so.
995 There is some advantage to simply keeping the phase 1 SAs around
996 until they expire - they may prove useful again in the near future.
998 3.3 Keying State Machine - Responder
1000 The responder has an identical set of objects as the initiator.
1002 The responder gets its first indication that something is happening
1003 when it receives an invitation to create a keying channel from an
1007 Richardson, et al. Expires August 22, 2002 [Page 18]
1009 Internet-Draft opportunistic February 2002
1014 3.3.1 Unauthenticated OE peer state
1016 Upon entering this state, a DNS lookup is done for a KEY record for
1017 the initiator. This is done in the reverse map for a KEY record for
1018 the initiator if the initiator has offered an ID_IPV4_ADDR, and in
1019 the forward map if the initiator has offered an ID_FQDN type. (See
1020 [8] section 4.6.2.1.)
1022 This state is exited upon successful receipt of a KEY from DNS, and
1023 use of it to verify the signature of the initiator.
1025 Successful authentication of the peer results in a transition to
1026 Authenticated OE Peer.
1028 Note that this state generally occurs in the middle of the key
1029 negotiation protocol. It is really a form of pseudo-state.
1031 3.3.2 Authenticated OE Peer
1033 The peer will eventually propose one or more phase 2 SAs. The source
1034 and destination address in the proposal are used to initialize the
1035 still empty connection state using the connection class table. A
1036 search for an identical connection object MUST be made at this point.
1038 If an identical connection is found, then delete the old instance
1039 that had been created, and transition this new object to the Pending
1040 OE connection state. This means that new ISAKMP connections with a
1041 given peer will always use the latest instance, which is the correct
1042 one if the peer has rebooted in the interim.
1044 If an identical connection is not found, then transition according to
1045 the rules given for the initiator.
1047 Note that if the initiator is in OE-paranoid mode and the responder
1048 is in either always-clear-text or deny, then no communication is
1049 possible according to policy. An implementation is permitted to
1050 create new types of policies, such as "accept OE, but do not initiate
1051 it". This is a local matter.
1053 3.4 Renewal and Teardown
1057 A potentially unlimited number of tunnels may exist. In practice,
1058 only a few tunnels are used during a period of time. Unused tunnels
1059 MUST therefore be torn down. Detecting when they are no longer in
1063 Richardson, et al. Expires August 22, 2002 [Page 19]
1065 Internet-Draft opportunistic February 2002
1068 use is the subject of this section.
1070 There are two methods in which the tunnel may be removed: by expiring
1071 or with explicit deletion.
1073 Explicit deletion is done with an IKE Delete message. To do this
1074 requires that both ends maintain the key channel (phase 1 ISAKMP SA),
1075 as the deletes MUST be authenticated. An implementation which
1076 refuses to either maintain or recreate the keying channel SA will be
1077 unable to use this method.
1079 In the expiry method, the tunnel is simply allowed by the IKE daemon
1080 to expire normally, without attempting to re-key it.
1082 Regardless of which method is used, a method is required to determine
1083 if the tunnel is still in use. This is a local matter, but the
1084 following criteria are what is used by the FreeSWAN project. This
1085 criteria is currently implemented in the key management daemon, but
1086 could also be implemented at the SPD layer using an idle timer.
1088 + a short initial (soft) lifespan of 1 minute is set. This is
1089 done since many net flows in fact last only a few seconds.
1091 + at the end of the lifespan, a check is made to see if the
1092 tunnel was used by traffic in either direction during the last
1093 half of this period. If so, assign a longer tentative
1094 lifespan, of 20 minutes, after which, look again. If the
1095 tunnel is not in use then close the tunnel.
1097 These timeouts are implemented by the Expiring state in the key
1098 management system (see Section 3.2.7). The timer given above may in
1099 fact be present in the forwarding plane, but it must, in this case be
1102 The tentative lifespan is independent of re-keying; it is just the
1103 time when the tunnel's future is next considered. (The term lifespan
1104 is used here rather than lifetime for this reason.) This should
1105 happen reasonably frequently, unlike re-keying, which is costly and
1106 shouldn't be too frequent.
1108 A multi-step back-off algorithm is not considered worth the effort
1111 If the security gateway and the client host are one and the same (and
1112 not a Bump-in-the-Stack or Bump-in-the-Wire implementation), tunnel
1113 teardown decisions MAY pay attention to TCP connection status, as
1114 reported by the local TCP layer. A still-open TCP connection is
1115 almost a guarantee that more traffic is coming, while the demise of
1119 Richardson, et al. Expires August 22, 2002 [Page 20]
1121 Internet-Draft opportunistic February 2002
1124 the only TCP connection through a tunnel is a strong hint that no
1125 more traffic will transit.
1127 3.4.2 Teardown and Cleanup
1129 Teardown should always be coordinated with the other end. This means
1130 interpreting and sending Delete notifications. There is some
1131 detailed state in the Expired Connection state of the key manager
1132 that relates to retransmits of the Delete notifications, but this is
1133 considered to be a keying system detail.
1135 On receiving a Delete for the outbound SAs of a tunnel (or some
1136 subset of them), tear down the inbound ones too, and notify the other
1137 end with a Delete. If a Delete is received for a tunnel which is no
1138 longer in existence, then two Delete messages have crossed paths.
1139 Ignore the Delete - the operation has already been done. Do not
1140 generate any messages in this situation.
1142 Tunnels need to be considered as bidirectional entities, even though
1143 the low-level protocols don't think of them that way.
1145 When the deletion is initiated locally, rather than as a response to
1146 a received Delete, send a Delete for (all) the inbound SAs of a
1147 tunnel. If no responding Delete is received for the outbound SAs,
1148 try re-sending the original Delete. Three tries spaced 10s apart
1149 seems a reasonable level of effort. A failure for the other end to
1150 respond at this point likely indicates that no further communication
1151 will be possible in any case. (Likely, it was a mobile node and it
1152 is not present or powered on anymore)
1154 After re-keying, transmission should switch to using the new outgoing
1155 SAs (ISAKMP or IPsec) immediately, and the old leftover SAs should be
1156 cleared out promptly (and Deletes sent) rather than waiting for them
1157 to expire. This reduces clutter and minimizes confusion for the
1158 operator doing diagnostics.
1175 Richardson, et al. Expires August 22, 2002 [Page 21]
1177 Internet-Draft opportunistic February 2002
1182 4.1 ISAKMP/IKE protocol
1184 The IKE wire protocol needs no modifications. The major changes are
1185 implementation issues relating to how the proposals are interpreted,
1186 and from whom they may come.
1188 As Opportunistic Encryption is designed to be useful between peers
1189 without prior operator configuration, an IKE daemon must be prepared
1190 to negotiate phase 1 SAs with any node. This may require a large
1191 amount of resources to maintain cookie state, as well as large
1192 amounts of entropy to for nonces, cookies, etc.
1194 The major changes to support Opportunistic Encryption are at the IKE
1195 daemon level. These changes relate to handling of key acquisition
1196 requests, lookup of public keys and TXT records, and interactions
1197 with firewalls and other security facilities that may be coresident
1198 on the same gateway.
1200 4.2 Gateway discovery process
1202 In a typical configured tunnel situation, the address of SG-B is
1203 provided via configuration. Furthermore, the mapping of SPD entry to
1204 gateway is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry
1205 technique is used, then the mapping to a gateway is determined by the
1206 reverse DNS records.
1208 The need to do a DNS lookup and wait for a reply will typically
1209 introduce a new state and a new event source (DNS replies) to IKE.
1210 Although a synchronous DNS request can be done for proof of concept,
1211 this will not scale very well.
1213 Use of an asynchronous DNS lookup will also permit overlap of DNS
1214 lookups with protocol some steps.
1216 4.3 Self identification
1218 SG-A will have to establish its identity. This is done by use of an
1221 There are many situations where the administrator of SG-A may not be
1222 able to control the reverse DNS records for SG-A's public IP address.
1223 Typical situations include dialup connections and most residential-
1224 type broadband Internet access (ADSL, cable-modem). In these
1225 situations, a fully qualified domain name which is under the control
1226 of SG-A's administrator may be used when acting as an initiator only.
1227 The FQDN ID should be used in phase 1. See Section 5.3 for more
1231 Richardson, et al. Expires August 22, 2002 [Page 22]
1233 Internet-Draft opportunistic February 2002
1236 details and restrictions.
1238 4.4 Public key Retrieval process
1240 Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID,
1241 or an FQDN ID, an IKE daemon will need to examine local caches and
1242 configuration files to determine if this is part of a configured
1243 tunnel. If none is found, then the implementation should attempt to
1244 retrieve a KEY record from the reverse DNS (in the case of an IPv4/
1245 IPv6 ID), or from the forward DNS in the case of FQDN ID.
1247 It is reasonable that if other non-local sources of policy are used
1248 (COPS, LDAP, ...) that they be consulted concurrently, but that some
1249 clear ordering of policy be provided. Note that due to variances in
1250 latency, one must wait for positive or negative replies from all
1251 sources of policy before making any decisions.
1253 4.5 Interactions with DNSSEC
1255 The present implementation does not use DNSSEC to explicitly verify
1256 the authenticity of zone information, or use the NXT records to
1257 provide authentication of the absence of a TXT or KEY record. These
1258 are important considerations for practical use.
1260 In practice the verification of the DNSSEC SIG and NXT records will
1261 typically be done by a trusted DNS server. This process may be co-
1262 located, or reachable via a trusted path.
1264 4.6 Recommended proposal types
1266 4.6.1 Phase 1 parameters
1268 Main mode MUST be used.
1270 The initiator MUST offer at least one proposal using some combination
1271 of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be
1272 proposed first. [12]
1274 The initiator MAY offer additional proposals, but the cipher MUST not
1275 be weaker than 3DES. The initiator SHOULD limit the number of
1276 proposals such that the IKE datagrams do not need to be fragmented.
1278 The responder MUST accept one of the proposals. If any configuration
1279 of the responder is required then the responder is not acting in an
1282 SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6), of the
1283 external interface of SG-A for phase 1. (There is an exception, see
1287 Richardson, et al. Expires August 22, 2002 [Page 23]
1289 Internet-Draft opportunistic February 2002
1292 Section 5.3) The authentication method MUST be RSA public key
1295 The RSA key for SG-A MUST be placed into a DNS KEY record in the
1296 reverse space of SG-A. (i.e. using in-addr.arpa.)
1298 4.6.2 Phase 2 parameters
1300 SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
1301 mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be
1304 Tunnel mode MUST be used.
1306 Authorization for SG-A to act on Alice's behalf is determined by
1307 looking for a TXT record in the reverse map at Alice's address.
1309 Compression SHOULD NOT be mandatory. It may be offered as an option.
1343 Richardson, et al. Expires August 22, 2002 [Page 24]
1345 Internet-Draft opportunistic February 2002
1350 5.1 Use of KEY record
1352 In order to establish their own identity, SG-A and SG-B must publish
1353 their public keys in their reverse DNS. This is just done via
1354 DNSSEC's KEY record. See section 3 of RFC 2535 [16].
1358 KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
1360 0x4200 The flag bits, indicating that this key is prohibited for
1361 use confidentiality (it authenticates the peer only, DH is used
1362 for confidentiality), and that this key is associated with the
1363 non-zone entity whose name is the RR owner name. No other
1366 4 This indicates that this key is for use by IPsec
1368 1 An RSA key is present
1370 AQNJjkKlIk9...nYyUkKK8 the public key of the host as described in
1374 5.2 Use of TXT delegation record
1376 A TXT record is published by Alice (Bob) to provide authorization for
1377 SG-A (SG-B) to act on its behalf. This record is located in the
1378 reverse DNS (in-addr.arpa) for Alice's IP address. The reverse DNS
1379 SHOULD be secured by DNSSEC, when it is deployed. DNSSEC is required
1380 to defend against active attacks.
1382 If Alice's address is P.Q.R.S, then she can authorize another node to
1383 act on her behalf by publishing records at:
1385 S.R.Q.P.in-addr.arpa
1387 The contents of the resource record are expected to be a string that
1388 follows the following syntax, as suggested in [15]. (Note that the
1389 reply to query may include other TXT resource records from other
1390 applications may also be returned.)
1399 Richardson, et al. Expires August 22, 2002 [Page 25]
1401 Internet-Draft opportunistic February 2002
1404 ---------------------------------------------------------------------
1407 X-IPsec-Server(P)=A.B.C.D KEY
1409 Figure 2: Format of reverse delegation record
1411 ---------------------------------------------------------------------
1413 P: the P specifies a precedence for this record. This is similar
1414 to MX record preferences. Lower numbers have stronger
1417 A.B.C.D: specifies the IP address of the Security Gateway for this
1420 KEY: is the encoded RSA Public key of the Security Gateway. This
1421 is provided here to avoid a second DNS lookup. If this field
1422 is absent, then a KEY resource record should be looked up in
1423 the reverse map of A.B.C.D.
1425 In the case where Alice is located at a public address behind a
1426 security gateway that has no fixed address (or no control over its
1427 reverse map), then Alice may delegate to a public key by domain name:
1429 ---------------------------------------------------------------------
1432 X-IPsec-Server(P)=@FQDN KEY
1434 Figure 3: Format of reverse delegation record (FQDN version
1436 ---------------------------------------------------------------------
1440 FQDN specifies the FQDN that the Security Gateway will identify
1441 itself with. Only useful for initiator.
1443 KEY: is the encoded RSA Public key of the Security Gateway.
1445 If there is more than one such TXT record with strongest (lowest
1446 numbered) precedence, one Security Gateway is picked arbitrarily from
1447 those specified in the strongest-preference records. All keys for
1448 that Security Gateway are made available as candidates for signature
1449 checking. This mechanism is required to permit roll-over of
1450 signature keys in a seamless fashion.
1455 Richardson, et al. Expires August 22, 2002 [Page 26]
1457 Internet-Draft opportunistic February 2002
1460 5.2.1 Choice of TXT record
1462 It has been suggested to use the OPT, CERT, KEY or KX records instead
1465 The KEY RR has a Protocol field which could be used to indicate use
1466 for a new protocol, and an Algorithm field which could be used to
1467 indicate different contents in the key data. However, the KEY record
1468 is not clearly intended for storing what are really authorizations,
1469 it is just for identities. Other uses have been discouraged.
1471 OPT resource records, as defined in [14] are not intended to be used
1472 for storage of information. They are not to be loaded, cached or
1473 forwarded. They are therefore inappropriate for use here.
1475 CERT records [18] can encode almost any set of information. A custom
1476 Type code would be used permitting any suitable encoding to be
1477 stored, not just X.509. The certificate RR, according to the RFC,
1478 are to be signed internally, which may add undesirable and
1479 unnecessary bulk. Larger DNS records may require TCP transfers
1480 instead of UDP ones.
1482 At the time of protocol design, the CERT RR was not widely deployed
1483 and could not be counted upon. Use of CERT records will be
1484 investigated, and may result in a future revision of this document.
1486 KX records are ideally suited for this use, but had not been deployed
1487 at the time of implementation.
1491 Unfortunately, not every administrator has control over the contents
1492 of the reverse-map. The only case where we can work around this is
1493 where the initiator (SG-A) has no suitable reverse map. In this
1494 case, the authorization record present in the reverse map of Alice
1495 may refer to a FQDN instead of an IP address.
1497 In this case, the client's TXT record gives the fully qualified
1498 domain name (FQDN) in place of its security gateway's IP address.
1499 The initiator should use the ID_FQDN ID-payload in phase 1. A
1500 forward lookup for a KEY record on the FQDN must yield the
1501 initiator's public key.
1503 This method can also be used when the external address of SG-A is
1506 If SG-A is acting on behalf of Alice, then Alice must still delegate
1507 authority for SG-A to do so in her reverse map. When Alice and SG-A
1511 Richardson, et al. Expires August 22, 2002 [Page 27]
1513 Internet-Draft opportunistic February 2002
1516 are one and the same (i.e. Alice is acting as an end-node) then
1517 there is no need for this when initiating only. Alice must still
1518 delegate to herself if she wishes to others to initiator OE to her.
1567 Richardson, et al. Expires August 22, 2002 [Page 28]
1569 Internet-Draft opportunistic February 2002
1572 6. Network Address Translation interaction
1574 There are no fundamentally new issues for getting opportunistic
1575 encryption to work in the presence of network address translation.
1576 Rather there are just the regular IPsec issues with NAT traversal.
1578 There are several situations to consider for NAT:
1580 6.1 Colocated NAT/NAPT
1582 If SG-A is also performing Network Address Translation on behalf of
1583 Alice, then the packet should be translated prior to being subjected
1584 to opportunistic encryption. This is in contrast to typical
1585 configured tunnel which often exist to bridge islands of private
1586 network address space. SG-A will use the translated source address
1587 for phase 2, and so SG-B will look that address up to confirm SG-A's
1590 In the case of NAT (1:1), the address space into which the
1591 translation is done MUST be globally unique, and control over the
1592 reverse map is assumed to be a given. Placing of TXT records is
1595 In the case of NAPT (m:1), the address will be SG-A. The ability to
1596 get KEY and TXT records in place will again depend upon whether or
1597 not there is administrative control over the reverse map. This is
1598 identical situations involving a single host acting on behalf of
1599 itself. FQDN style can be used to get around a lack of a reverse map
1600 for initiators only.
1602 6.2 SG-A behind NAT/NAPT
1604 If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
1605 NAT traversal rules would apply. In addition to the transport
1606 problem which can be solved via proposals like [11], there is the
1607 issue of what phase 1 and phase 2 IDs to use. While FQDN could be
1608 used during phase 1 for SG-A. An appropriate ID for phase 2 permits
1609 SG-B to determine that SG-A was in fact authorized to speak for
1612 This is only possible if Alice actually has a public IP. It is a
1613 somewhat unusual case where a public network exists behind SG-A,
1614 while SG-A itself is behind a NAPT. This may occur with mobile
1615 networks of various kinds that occasionally wind up behind a NAPT.
1617 6.3 Bob is behind a NAT/NAPT
1619 If Bob is behind a NAT (perhaps SG-B), then there is in fact no way
1623 Richardson, et al. Expires August 22, 2002 [Page 29]
1625 Internet-Draft opportunistic February 2002
1628 for Alice to address a packet to Bob. Not only is opportunistic
1629 encryption impossible, but it is also impossible for Alice to
1630 initiate any communication to Bob. It may be possible for Bob to
1631 initiate in such a situation.
1679 Richardson, et al. Expires August 22, 2002 [Page 30]
1681 Internet-Draft opportunistic February 2002
1684 7. Host implementations
1686 When Alice and SG-A are components of the same system, then this is
1687 considered to be a host implementation. The scenario remains
1688 unchanged with respect to packet sequence.
1690 Components marked Alice are simply the upper layers (TCP, UDP, the
1691 application), and SG-A is the IP layer.
1693 Note that tunnel mode is still recommended.
1695 As Alice/SG-A are acting on behalf of themselves, no TXT based
1696 delegation record is necessary for Alice to initiate. She can rely
1697 on a FQDN in a forward map. To respond, Alice/SG-A will still need
1698 an entry in her reverse map.
1735 Richardson, et al. Expires August 22, 2002 [Page 31]
1737 Internet-Draft opportunistic February 2002
1742 If there are multiple paths between Alice and Bob (such as
1743 illustrated in the diagram with SG-D) then additional DNS records are
1744 required to establish authorization.
1746 In the diagram in Figure 1, Alice has two ways to exit her network:
1747 SG-A and SG-D. Previously SG-D has been ignored. Postulate that
1748 there are routers between Alice and her set of security gateways
1749 (denoted by the + signs and the marking of an autonomous system
1750 number for Alice's network). Datagrams may therefore travel to
1751 either SG-A or SG-D en route to Bob.
1753 As long as all network connections are in good order it does not
1754 matter how datagrams exit Alice's network. When they reach either
1755 security gateway, the security gateway will find the TXT delegation
1756 record in Bob's reverse map, and establish an SA with SG-B.
1758 SG-B has no problem establishing that either of SG-A or SG-D may
1759 speak for Alice, as Alice has published two equally weighted TXT
1762 ---------------------------------------------------------------------
1765 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
1766 X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
1768 Figure 4: Multiple gateway delegation example
1770 ---------------------------------------------------------------------
1772 Alice's routers can now happily do any kind of load sharing that they
1773 might wish to do. SG-A and SG-D will both send datagrams addressed
1774 to Bob through their tunnel to SG-B.
1776 If Alice wishes to prefer one gateway over another, then Bob should,
1777 upon finding that he has connections to two gateways en route to
1778 Alice, prefer the most recently established one - the precedence
1779 values are only valid for an initiator. It may be that the other one
1780 has experienced a failure, which is why Alice has switch to her less
1783 If the precedences are the same, then SG-B has a more difficult time.
1784 It must decide which of the two tunnels to use. SG-B has no
1785 information about which link is less loaded, nor which security
1786 gateway has more cryptographic resources available. SG-B in fact has
1787 no knowledge of whether both gateways are even reachable.
1791 Richardson, et al. Expires August 22, 2002 [Page 32]
1793 Internet-Draft opportunistic February 2002
1796 The Public Internet's default free zone may well know a good route to
1797 Alice, but the datagrams that SG-B creates must be addressed to
1798 either SG-A or SG-D; they can not be addressed to Alice directly.
1800 There are a number of choices which SG-B may make:
1802 1. It can ignore the problem and round robin among the tunnels it
1803 has. This will cause losses during times when one or the
1804 other security gateway is unreachable. If this worries Alice,
1805 she can change the weights in her TXT delegation records.
1807 2. It can always send to the gateway that it most recently
1808 received from. This assumes that routing and reachability is
1811 3. It can listen to BGP information from the Internet to decide
1812 which system is currently up. This is clearly a much more
1813 complicated thing to do, but if SG-B is already doing this
1814 because it is participating in the BGP peering system to
1815 announce Bob, the results data may already be available to it.
1817 4. It can refuse to negotiate the second tunnel. (It is unclear
1818 whether or not this is even an option)
1820 5. It can silently replace the outgoing portion of the first
1821 tunnel with the second one, while still retaining the incoming
1822 portions of both. SG-B can thus be willing willing to accept
1823 datagrams from either SG-A or SG-D, but sending only to the
1824 gateway that most recently rekeyed with it.
1826 These are decisions left to local policy. Note that even if SG-B has
1827 perfect knowledge about reachability of SG-A and SG-D, Alice may not
1828 be reachable from one or other of these security gateways due to
1829 internal reachability issues.
1831 FreeS/WAN implements option 5. Consideration to implementing a
1832 different in being given. The multihoming aspects of this OE, not
1833 well developed and may be a subject of a future document.
1847 Richardson, et al. Expires August 22, 2002 [Page 33]
1849 Internet-Draft opportunistic February 2002
1856 If a DNS server fails to respond, then it is a local policy decision
1857 whether or not to permit communication in the clear. This is
1858 emboddied in the connection classes in Section 3.2. It should be
1859 clear that mounting a denial of service attack on the DNS server
1860 responsible for a particular network's reverse map is an easy thing
1861 to do. Such an attack may cause all communication with that network
1862 to go in the clear for a permissive policy, and for communication to
1863 fail completely if this is a paranoid policy. Please note that this
1864 is an active attack.
1866 At the same time, there are still a very large number of networks
1867 that do not have properly configured reverse maps. Further, the
1868 effect of the above denial of service attack, if the policy is not to
1869 communicate, is that the target network becomes isolated. This is
1870 why this decision MUST be a matter of local policy.
1872 9.2 DNS configured, IKE failures
1874 In this situation, DNS records claim that opportunistic encryption
1875 should occur, but the target gateway either does not respond on port
1876 500, or refuses the proposal. This may be due to a crash/reboot, due
1877 to misconfiguration, or a firewall filtering port 500.
1879 The receipt of ICMP port, host or network unreachable messages should
1880 be taken as a sign that there is a potential problem, but MUST NOT
1881 cause communication to fail immediately. ICMP messages are easily
1882 forged by attackers. If such a forgery caused immediate failure,
1883 then an attacker could easily prevent any encryption from ever
1884 occuring, possibly preventing all communication.
1886 It is recommended that in these situations that a clear log be
1887 produced about the problem. A local policy should dictate if
1888 communication is then permitted in the clear at this point.
1892 Tunnels sometimes go down because the other end crashes, or
1893 disconnects, or has a network link break, and there is no notice
1894 of this in the general case. (Even in the event of a crash and
1895 successful reboot, other SGs don't hear about it unless the rebooted
1896 SG has specific reason to talk to them immediately.) Over-quick
1897 response to temporary network out- ages is undesirable... but note
1898 that a tunnel can be torn down and then re-established without any
1899 user-visible effect except a pause in traffic, whereas if one end
1903 Richardson, et al. Expires August 22, 2002 [Page 34]
1905 Internet-Draft opportunistic February 2002
1908 does reboot, the other end can't get datagrams to it at all
1909 (except via IKE) until the situation is noticed. So a bias toward
1910 quick response is appropriate, even at the cost of occasional
1913 A mechanism for recover after reboot is not specified in this
1914 document as it is a topic of current research.
1916 A deliberate shutdown should include an attempt to notify all other
1917 SGs currently connected by phase 1 SAs, using Deletes, that
1918 communication is about to fail. (Again, these will be taken as
1919 teardowns; attempts by the other SGs to negotiate new tunnels as
1920 replacements should be ignored at this point.) And when
1921 possible, SGs should attempt to preserve information about
1922 currently-connected SGs in non-volatile storage, so that after a
1923 crash, an Initial-Contact can be sent to previous partners to
1924 indicate loss of all previously established connections.
1959 Richardson, et al. Expires August 22, 2002 [Page 35]
1961 Internet-Draft opportunistic February 2002
1964 10. Unresolved issues
1966 10.1 Control of reverse DNS
1968 The method of obtaining information is by reverse DNS lookup causes
1969 problems for people who can not control their reverse DNS bindings.
1970 This is an unresolved problem in this version, and is out of scope.
2015 Richardson, et al. Expires August 22, 2002 [Page 36]
2017 Internet-Draft opportunistic February 2002
2022 11.1 Clear-text usage (permit policy)
2024 What follows are two example scenarios. The first is where Gate1 and
2025 Gate2 have always-cleartext policies, and the second where they have
2028 ---------------------------------------------------------------------
2031 Alice Gate1 DNS Gate2 Bob
2032 Alice Gate1 DNS Gate2 Bob
2034 ------(2)-------------->
2035 <-----(3)---------------
2037 ----------(6)------>
2040 <----------(9)------
2043 ----------(12)----->
2046 <-------------------
2049 Figure 5: Timing of regular transaction
2051 ---------------------------------------------------------------------
2053 Alice wants to send a packet to Bob, say a ping packet. Without the
2054 presence of opportunistic encryptors, the following events occur:
2056 (1) Human or application 'clicks' with a name
2058 (2) Application looks up name in DNS to get IP address
2060 (3) Resolver returns A record to application
2062 (4) Application starts a TCP session or UDP session, OS sends
2065 (5) Packet is seen at first gateway from Alice (SG-A) (Gate1
2066 transitions through Empty connection to always-clear connection
2067 and instantiates a passthrough policy at the forwarding plane)
2071 Richardson, et al. Expires August 22, 2002 [Page 37]
2073 Internet-Draft opportunistic February 2002
2076 (6) Packet is seen at last gateway before Bob (SG-B)
2078 (7) First packet from Alice is seen by Bob
2080 (8) First return packet is sent by Bob
2082 (9) Packet is seen at Bob's gateway (Gate2 transitions through an
2083 Empty connection to always-clear connection and instantites a
2084 passthrough policy at the forwarding plane)
2086 (10) Packet is seen at Alice's gateway
2088 (11) OS hands packet to application, Alice sends another packet
2090 (12) a second packet traverses the Internet
2093 11.2 Opportunistic Encryption
2095 In the presence of properly configured opportunistic encryptors, the
2096 event list is extended.
2098 ---------------------------------------------------------------------
2101 Alice SG-A DNS SG-B Bob
2103 ------(2)-------------->
2104 <-----(3)---------------
2108 -------------(5D)--->
2109 <------------(5E1)---
2110 -------------(5E2)-->
2111 <------------(5E3)---
2112 #############(5E4)##>
2113 <############(5E5)###
2116 #############(5G1)##>
2119 <############(5G2)###
2120 #############(5G3)##>
2121 ============(6)====>
2127 Richardson, et al. Expires August 22, 2002 [Page 38]
2129 Internet-Draft opportunistic February 2002
2132 <==========(9)======
2135 ==========(12)=====>
2138 <===================
2141 Figure 6: Timing of Opportunistic Encryption transaction
2143 ---------------------------------------------------------------------
2145 (1) Human or application clicks with a name
2147 (2) Application initiates DNS mapping.
2149 (3) resolver returns A record to application
2151 (4) Application starts a TCP session or UDP
2153 (5) SG (host or SG) sees packet to target, buffers it.
2155 (5B) SG asks the DNS for TXT record
2157 (5C) DNS returns TXT record(s)
2159 (5D) Initial IKE Main Mode Packet goes out
2161 (5E) IKE ISAKMP phase 1 succeeds
2163 (5F) SG-B asks the DNS for TXT record to prove SG-A agent for
2166 (5G) IKE phase 2 negotiation
2168 (5H) DNS looksup by responder (SG-B)
2170 (6) buffered packet is sent by SG-A
2172 (7) packet is received by SG-B, and decrypted, sent to Bob
2174 (8) Bob replies, packet is seen by SG-B
2176 (9) SG-B already has tunnel up with SG-A, uses it
2178 (10) SG-A decrypts packet and give it to Alice
2183 Richardson, et al. Expires August 22, 2002 [Page 39]
2185 Internet-Draft opportunistic February 2002
2188 (11) Alice receives packet. Sends new packet to Bob
2190 (12) SG-A gets second packet, sees that tunnel is up, uses it
2192 For the purposes of this section, we will describe on the changes
2193 that occur between Figure 5 and Figure 6. This means time points 5,
2196 11.2.1 (5) IPsec packet interception
2198 At point (5), Security Gateway 1 intercepts the packet due to the
2199 lack of a policy (the non-existant policy!) for this source/
2200 destination pair. A hold policy is created, and the packet is
2201 buffered. A request is sent to the keying daemon for keys.
2203 11.2.2 (5B) DNS lookup for TXT record
2205 SG-A's IKE daemon, having looked up the source/destination in the
2206 connection class list, creates a new Potential OE connection
2207 instance. The DNS queries are started.
2209 11.2.3 (5C) DNS returns TXT record(s)
2211 DNS returns properly formed TXT delegation records, and SG-A's IKE
2212 daemon transitions this instance from Potential OE connection to
2213 Pending OE connection.
2215 For the example above, the returned record might contain:
2217 ---------------------------------------------------------------------
2220 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
2222 Figure 7: Example of reverse delegation record
2224 ---------------------------------------------------------------------
2226 with SG-B's IP address and public key listed.
2228 11.2.4 (5D) Initial IKE Main Mode Packet goes out
2230 Upon entering Pending OE connection, SG-A sends the initial ISAKMP
2231 message, with proposals, see Section 4.6.1.
2233 11.2.5 (5E1) Message 2 of phase 1 exchange
2235 SG-B receives the message. A new connection instance is created in
2239 Richardson, et al. Expires August 22, 2002 [Page 40]
2241 Internet-Draft opportunistic February 2002
2244 the Unauthenticated OE Peer state.
2246 11.2.6 (5E2) Message 3 of phase 1 exchange
2248 SG-A sends a Diffie-Hellman exponent. This is an internal state of
2251 11.2.7 (5E3) Message 4 of phase 1 exchange
2253 SG-B responds with a Diffie-Hellman exponent. This is an internal
2254 state of the keying protocol.
2256 11.2.8 (5E4) Message 5 of phase 1 exchange
2258 SG-A uses the phase 1 SA to send its identity under encryption. The
2259 choice of identity is discussed in Section 4.6.1. This is an
2260 internal state of the keying protocol.
2262 11.2.9 (5F1) Responder lookup of initiator key
2264 Security Gateway 2 asks DNS for the public key of the initiator.
2265 This is done by asking for a KEY record by IP address in the reverse
2266 map. That is, a KEY resource record is queried for 4.1.1.192.in-
2267 addr.arpa (recall that SG-A's external address is 192.1.1.4) The
2268 resulting public key is used to authenticate the initiator. See
2269 Section 5.1 for further details.
2271 11.2.10 (5F2) DNS replies with public key of initiator
2273 Upon successfully authenticating the peer, the connection instance
2274 is transitioned to Authenticated OE peer on SG-2.
2276 The format of the TXT record that is returned is described in Section
2279 11.2.11 (5E5) Responder replies with ID and authentication
2281 SG-B sends its ID along with authentication material. This is an
2282 internal state for the keying protocol.
2284 11.2.12 (5G) IKE phase 2
2286 11.2.12.1 (5G1) Initiator proposes tunnel
2288 Having established mutually agreeable authentications (via KEY) and
2289 authorizations (via TXT), SG-A proposes to create an IPsec tunnel for
2290 datagrams transiting from Alice to Bob. This tunnel is established
2291 for only the A/B combination, not for any subnets that may be behind
2295 Richardson, et al. Expires August 22, 2002 [Page 41]
2297 Internet-Draft opportunistic February 2002
2302 11.2.12.2 (5H1) Responder determines initiator's authority
2304 While the identity of the SG-A has been established, its authority to
2305 speak for Alice has not yet been confirmed. This is done by doing a
2306 reverse lookup on A's address for a TXT record.
2308 Upon receiving this specific proposal, SG-2 transitions its instance
2309 into the Potential OE connection state. SG-2 may already have an
2310 instance, and the check is made as described above.
2312 11.2.12.3 (5H2) DNS replies with TXT record
2314 The returned key and IP address should match that of SG-A.
2316 11.2.12.4 (5G2) Responder agrees to proposal
2318 Should additional communication occur between, for instance, D and B
2319 via SG-A and SG-B, a new tunnel (phase 2 SA) would be established.
2320 The phase 1 SA may be reusable.
2322 SG-A, having successfully keyed the tunnel, now transitions from
2323 Pending OE connection to Keyed OE connection.
2325 The responder MUST setup inbound IPsec SAs before sending its reply.
2327 11.2.12.5 (5G3) Final acknowledgement from initiator
2329 The initiator agrees with the responder's choice and sets up the
2330 tunnel. The initiator sets up inbound and outbound IPsec SAs.
2332 The proper authorization returned with keys SG-2 to transition its
2333 instance to the Keyed OE connection.
2335 Upon receipt of this message, the responder may now setup the
2338 11.2.13 (6) IPsec succeeds, sets up tunnel for communication between
2341 The packet which was saved at step (5) is sent through the newly
2342 created tunnel to SG-B. Bob receives it at (7) and replies at (8).
2344 11.2.14 (9) SG-B already has tunnel up with G1, uses it
2346 At (9), SG-B has already established an SPD entry mapping Bob->Alice
2347 via a tunnel, so this tunnel is simply applied. The packet is
2351 Richardson, et al. Expires August 22, 2002 [Page 42]
2353 Internet-Draft opportunistic February 2002
2356 encrypted to SG-A, decrypted by SG-A and passed to Alice at (10).
2407 Richardson, et al. Expires August 22, 2002 [Page 43]
2409 Internet-Draft opportunistic February 2002
2412 12. Security Considerations
2414 12.1 Configured vs Opportunistic Tunnels
2416 Configured tunnels are those which are setup using bilateral
2417 mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared
2418 secrets, or by referencing keys that are in known places
2419 (distinguished name from LDAP, DNS). These keys are then used to
2420 configure a specific tunnel.
2422 A pre-configured tunnel may be on all the time, or may be keyed only
2423 when needed. The end points of the tunnel are not necessarily
2424 static: many mobile applications ("road warrior") are considered to
2425 be configured tunnels.
2427 The primary consideration is that configured tunnels are assigned
2428 specific security properties. They may be trusted in different ways.
2429 This is usually related to exceptions to firewall rules, exceptions
2430 to NAT processing, and to bandwidth or other quality of service
2433 Opportunistic tunnels are not inherently trusted in any strong way.
2434 They are created without prior arrangement. As the two parties are
2435 strangers, there MUST be no confusion of datagrams that arrive from
2436 opportunistic peers and those that arrive from configured tunnels. A
2437 security gateway MUST take care that an opportunistic peer can not
2438 impersonate a configured peer.
2440 Ingress filtering MUST be used to make sure that only packets
2441 authorized by negotiation (and the concomitant authentication and
2442 authorization) are accepted from a tunnel. This is to prevent one
2443 peer from impersonating another.
2445 An implementation suggestion is to logically treat opportunistically
2446 tunnel datagrams as if they arrive on a distinct logical interface
2447 from other configured tunnels. As the number of opportunistic
2448 tunnels that may be created automatically on a system is potentially
2449 very high, careful attention to scaling should be taken into account.
2451 As with any IKE negotiation, opportunistic encryption cannot be
2452 secure without authentication. Opportunistic encryption relies on
2453 DNS for its authentication information and therefore cannot be fully
2454 secure without a secure DNS. Without secure DNS, it can protect
2455 against passive eavesdropping, but not against active man-in-the-
2463 Richardson, et al. Expires August 22, 2002 [Page 44]
2465 Internet-Draft opportunistic February 2002
2468 12.2 Firewalls vs Opportunistic Tunnels
2470 Typical usage of per-packet access control lists is to implement
2471 various kinds of security gateways. These are typically called
2474 Typical usage of virtual private network (VPN) within a firewall is
2475 to bypass all or part of the access controls between two networks.
2476 Additional trust (as outlined in the previous section) is given to
2477 datagrams that arrive in the VPN.
2479 Datagrams that arrive via opportunistically configured tunnels MUST
2480 not be trusted. Any security policy that would apply to a packet
2481 arriving in the clear SHOULD also be applied to datagrams arriving
2484 12.3 Denial of Service
2486 There are several different forms of denial of service which an
2487 implementor should concern themselves with. Most of these problems
2488 are shared with security gateways that have large numbers of mobile
2489 peers (road warriors).
2491 The design of ISAKMP/IKE, and its use of cookies, defend against many
2492 kinds of denial of service. There is an assumption that if the phase
2493 1 (ISAKMP) SA is authenticated, that it was worthwhile creating.
2494 Opportunism changes this assumption. As the gateway will communicate
2495 with anyone, it is possible to form phase 1 SAs with any machine on
2519 Richardson, et al. Expires August 22, 2002 [Page 45]
2521 Internet-Draft opportunistic February 2002
2524 13. IANA Considerations
2526 There are no known numbers which IANA will need to manage.
2575 Richardson, et al. Expires August 22, 2002 [Page 46]
2577 Internet-Draft opportunistic February 2002
2580 14. Acknowledgements
2582 Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert
2583 Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore and John
2584 Denker for their comments and constructive criticism.
2631 Richardson, et al. Expires August 22, 2002 [Page 47]
2633 Internet-Draft opportunistic February 2002
2638 [1] Redelmeier, D. and H. Spencer, "Opportunistic Encryption",
2639 paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/
2640 opportunism.spec, May 2001.
2642 [2] Defense Advanced Research Projects Agency (DARPA), Information
2643 Processing Techniques Office and , "Internet Protocol", STD 5,
2644 RFC 791, September 1981.
2646 [3] Braden, R. and J. Postel, "Requirements for Internet gateways",
2647 RFC 1009, June 1987.
2649 [4] IAB, IESG, Carpenter, B. and F. Baker, "IAB and IESG Statement
2650 on Cryptographic Technology and the Internet", RFC 1984, August
2653 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
2654 Levels", BCP 14, RFC 2119, March 1997.
2656 [6] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API,
2657 Version 2", RFC 2367, July 1998.
2659 [7] Kent, S. and R. Atkinson, "Security Architecture for the
2660 Internet Protocol", RFC 2401, November 1998.
2662 [8] Piper, D., "The Internet IP Security Domain of Interpretation
2663 for ISAKMP", RFC 2407, November 1998.
2665 [9] Maughan, D., Schneider, M. and M. Schertler, "Internet Security
2666 Association and Key Management Protocol (ISAKMP)", RFC 2408,
2669 [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
2670 RFC 2409, November 1998.
2672 [11] Huttunen, A. and W. Dixon, "UDP Encapsulation of IPsec
2673 Packets", ID internet-draft (draft-ietf-ipsec-udp-encaps-00),
2676 [12] Kivinen, T. and M. Kojo, "More MODP Diffie-Hellman groups for
2677 IKE", ID internet-draft (draft-ietf-ipsec-ike-modp-groups-03),
2680 [13] Mockapetris, P., "Domain names - concepts and facilities", STD
2681 13, RFC 1034, November 1987.
2683 [14] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
2687 Richardson, et al. Expires August 22, 2002 [Page 48]
2689 Internet-Draft opportunistic February 2002
2694 [15] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary
2695 String Attributes", RFC 1464, May 1993.
2697 [16] Eastlake, D., "Domain Name System Security Extensions", RFC
2700 [17] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System
2701 (DNS)", RFC 2537, March 1999.
2703 [18] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
2704 Domain Name System (DNS)", RFC 2538, March 1999.
2706 [19] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
2707 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2710 [20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
2711 (NAT) Terminology and Considerations", RFC 2663, August 1999.
2716 Michael C. Richardson
2717 Sandelman Software Works
2722 EMail: mcr@sandelman.ottawa.on.ca
2723 URI: http://www.sandelman.ottawa.on.ca/
2731 EMail: hugh@mimosa.com
2743 Richardson, et al. Expires August 22, 2002 [Page 49]
2745 Internet-Draft opportunistic February 2002
2754 EMail: henry@spsystems.net
2799 Richardson, et al. Expires August 22, 2002 [Page 50]
2801 Internet-Draft opportunistic February 2002
2804 Full Copyright Statement
2806 Copyright (C) The Internet Society (2002). All Rights Reserved.
2808 This document and translations of it may be copied and furnished to
2809 others, and derivative works that comment on or otherwise explain it
2810 or assist in its implementation may be prepared, copied, published
2811 and distributed, in whole or in part, without restriction of any
2812 kind, provided that the above copyright notice and this paragraph are
2813 included on all such copies and derivative works. However, this
2814 document itself may not be modified in any way, such as by removing
2815 the copyright notice or references to the Internet Society or other
2816 Internet organizations, except as needed for the purpose of
2817 developing Internet standards in which case the procedures for
2818 copyrights defined in the Internet Standards process must be
2819 followed, or as required to translate it into languages other than
2822 The limited permissions granted above are perpetual and will not be
2823 revoked by the Internet Society or its successors or assigns.
2825 This document and the information contained herein is provided on an
2826 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2827 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2828 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2829 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2830 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2834 Funding for the RFC Editor function is currently provided by the
2855 Richardson, et al. Expires August 22, 2002 [Page 51]
OSDN Git Service
