notification of this. Even in the event of a crash and successful
reboot, other SGs don’t hear about it unless the rebooted SG has
specific reason to talk to them immediately. Over-quick response to
temporary network outages is undesirable. Note that a tunnel can be
torn down and then re-established without any 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
attempt to preserve 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 obtaining information by reverse DNS lookup causes
problems for people who cannot 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 example, GW-A (Gateway A)
and GW-B (Gateway B) have always-clear-text policies, and in the
second example they have an OE policy. The clear-text policy serves
as a reference for what occurs in TCP/IP in the absence of
Opportunistic Encryption.
Alice wants to communicate with Bob. Perhaps she wants to retrieve a
web page from Bob’s web server. In the absence of opportunistic
encryptors, the following events occur:
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 transaction
11.2. Opportunistic Encryption
In the presence of properly configured opportunistic encryptors, the
event list is extended. Only changes are annotated.
The following symbols are used in the time-sequence diagram:
- A single dash represents clear-text datagrams.
= An equals sign represents phase 2 (IPsec) cipher-text datagrams.
~ A single tilde represents clear-text phase 1 datagrams.
# A hash sign represents 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 transaction
For the purposes of this section, we will describe only the changes
that occur between Figure 5 and Figure 6. This corresponds to time
points 5, 6, 7, 9, and 10 on the list above.
At point (5), SG-A intercepts the datagram because this
source/destination pair lacks a policy (the nonexistent policy
state). SG-A creates a hold policy, and buffers the datagram. SG-A
requests keys from the keying daemon.
(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. A new connection instance is 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 is, a KEY resource record is queried
for 4.1.1.192.in-addr.arpa (recall that SG-A’s external address
is 192.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.
Upon successfully authenticating the peer, the connection
instance makes a transition to authenticated OE peer on SG-B.
The format of the TXT record returned is described in
Section 5.2.
Responder replies with ID and authentication.
SG-B sends its ID along with authentication material, completing
the phase 1 negotiation.
(5L) IKE phase 2 negotiation.
Having established mutually agreeable authentications (via KEY)
and authorizations (via TXT), SG-A proposes to create an IPsec
tunnel for datagrams transiting 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.
While the identity of SG-A has been established, its authority
to speak for Alice has not yet been confirmed. 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. It confirms that SG-A is authorized
to speak for Alice.
Upon receiving this specific proposal, SG-B’s connection
instance makes a transition 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, proceeds 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.
Upon receipt of this message, 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
established an SPD entry mapping Bob->Alice via a tunnel, so this
tunnel is simply applied. The datagram is encrypted to SG-A,
decrypted by SG-A, and passed to Alice at (10).
12. Security Considerations
12.1. Configured versus Opportunistic Tunnels
Configured tunnels are setup using bilateral mechanisms: exchanging
public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by
referencing keys that are in known places (distinguished name from
LDAP, DNS). These keys are then used to configure a specific tunnel.
A pre-configured tunnel may be on all the time, or may be keyed only
when needed. The endpoints of the tunnel are not necessarily static;
many mobile applications (road warrior) are considered to be
configured tunnels.
The primary characteristic is that configured tunnels are assigned
specific security properties. They may be trusted in different ways
relating to exceptions to firewall rules, exceptions to NAT
processing, and to bandwidth or other quality of service
restrictions.
Opportunistic tunnels are not inherently trusted in any strong way.
They are created without prior arrangement. As 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. As the number of opportunistic tunnels
that may be created automatically on a system is potentially very
high, 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.
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, defend against many
kinds of denial of service. Opportunism changes the assumption that
if the phase 1 (ISAKMP) SA is authenticated, that 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.
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
[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
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.com
Full Copyright Statement
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 takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.