Regardless of which method is used to remove tunnels, the
implementation MUST use a method to determine if the tunnel is still
in use. The specifics are a local matter, but the FreeS/WAN project
uses the following criteria. These criteria are currently
implemented in the key management daemon, but could also be
implemented at the SPD layer using an idle timer.
Set a short initial (soft) lifespan of 1 minute since many net flows
last only a few seconds.
At the end of the lifespan, check to see if the tunnel was used by
traffic in either direction during the last 30 seconds. If so,
assign a longer tentative lifespan of 20 minutes, after which, look
again. If the tunnel is not in use, then close the tunnel.
The expiring state in the key management system (see Section 3.2.7)
implements these timeouts. The timer above may be in the forwarding
plane, but then it must be resettable.
The tentative lifespan is independent of re-keying; it is just the
time when the tunnel’s future is next considered. (The term lifespan
is used here rather than lifetime for this reason.) Unlike re-
keying, this tunnel use check is not costly and should happen
reasonably frequently.
A multi-step back-off algorithm is not considered worth the effort
here.
If the security gateway and the client host are the same, and not a
Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown
decisions MAY pay attention to TCP connection status as reported by
the local TCP layer. A still-open TCP connection is almost a
guarantee that more traffic is expected. Closing of the only TCP
connection through a tunnel is a strong hint that no more traffic is
expected.
3.4.2. Teardown and Cleanup
Teardown should always be coordinated between the two ends of the
tunnel by interpreting and sending delete notifications. There is a
detailed sub-state in the expired connection state of the key manager
that relates to retransmits of the delete notifications, but this is
considered to be a keying system detail.
On receiving a delete for the outbound SAs of a tunnel (or some
subset of them), tear down the inbound ones also and notify the
remote end with a delete. If the local system receives a delete for
a tunnel that is no longer in existence, then two delete messages
have crossed paths. Ignore the delete. The operation has already
been completed. Do not generate any messages in this situation.
Tunnels are to be considered as bidirectional entities, even though
the low-level protocols don’t treat them this way.
When the deletion is initiated locally, rather than as a response to
a received delete, send a delete for (all) the inbound SAs of a
tunnel. If the local system does not receive a responding delete for
the outbound SAs, try re-sending the original delete. Three tries
spaced 10 seconds apart seems a reasonable level of effort. A
failure of the other end to respond after 3 attempts indicates that
the possibility of further communication is unlikely. Remove the
outgoing SAs. (The remote system may be a mobile node that is no
longer present or powered on.)
After re-keying, transmission should switch to using the new outgoing
SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs
should be cleared out promptly (delete should be sent for the
outgoing SAs) rather than waiting for them to expire. This reduces
clutter and minimizes confusion for the operator doing diagnostics.
4. Impacts on IKE
4.1. ISAKMP/IKE Protocol
The IKE wire protocol needs no modifications. The major changes are
implementation issues relating to how the proposals are interpreted,
and from whom they may come.
As opportunistic encryption is designed to be useful between peers
without prior operator configuration, an IKE daemon must be prepared
to negotiate phase 1 SAs with any node. This may require a large
amount of resources to maintain cookie state, as well as large
amounts of entropy for nonces, cookies, and so on.
The major changes to support opportunistic encryption are at the IKE
daemon level. These changes relate to handling of key acquisition
requests, lookup of public keys and TXT records, and interactions
with firewalls and other security facilities that may be co-resident
on the same gateway.
4.2. Gateway Discovery Process
In a typical configured tunnel, the address of SG-B is provided via
configuration. Furthermore, the mapping of an SPD entry to a gateway
is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique
is used, then the mapping to a gateway is determined by the reverse
DNS records.
The need to do a DNS lookup and wait for a reply will typically
introduce a new state and a new event source (DNS replies) to IKE.
Although a synchronous DNS request can be implemented for proof of
concept, experience is that it can cause very high latencies when a
queue of queries must all timeout in series.
Use of an asynchronous DNS lookup will also permit overlap of DNS
lookups with some of the protocol steps.
4.3. Self Identification
SG-A will have to establish its identity. Use an IPv4 (IPv6) ID in
phase 1.
There are many situations where the administrator of SG-A may not be
able to control the reverse DNS records for SG-A’s public IP address.
Typical situations include dialup connections and most residential-
type broadband Internet access (ADSL, cable-modem) connections. In
these situations, a fully qualified domain name that is under the
control of SG-A’s administrator may be used when acting as an
initiator only. The FQDN ID should be used in phase 1. See Section
5.3 for more details and restrictions.
4.4. Public Key Retrieval Process
Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID
or an FQDN ID, an IKE daemon needs to examine local caches and
configuration files to determine if this is part of a configured
tunnel. If no configured tunnels are found, then the implementation
should attempt to retrieve a KEY record from the reverse DNS in the
case of an IPv4/IPv6 ID, or from the forward DNS in the case of FQDN
ID.
It is reasonable that if other non-local sources of policy are used
(COPS, LDAP), they be consulted concurrently, but that some clear
ordering of policy be provided. Note that due to variances in
latency, implementations must wait for positive or negative replies
from all sources of policy before making any decisions.
4.5. Interactions with DNSSEC
The implementation described (FreeS/WAN 1.98) neither uses DNSSEC
directly to explicitly verify the authenticity of zone information,
nor uses the NSEC records to provide authentication of the absence of
a TXT or KEY record. Rather, this implementation uses a trusted path
to a DNSSEC-capable caching resolver.
To distinguish between an authenticated and an unauthenticated DNS
resource record, a stub resolver capable of returning DNSSEC
information MUST be used.
4.6. Required Proposal Types
4.6.1. Phase 1 Parameters
Main mode MUST be used.
The initiator MUST offer at least one proposal using some combination
of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be
proposed first. (See [RFC3526])
The initiator MAY offer additional proposals, but the cipher MUST not
be weaker than 3DES. The initiator SHOULD limit the number of
proposals such that the IKE datagrams do not need to be fragmented.
The responder MUST accept one of the proposals. If any configuration
of the responder is required, then the responder is not acting in an
opportunistic way.
The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of
the external interface of the initiator for phase 1. (There is an
exception, see Section 5.3.) The authentication method MUST be RSA
public key signatures. The RSA key for the initiator SHOULD be
placed into a DNS KEY record in the reverse space of the initiator
(i.e., using in-addr.arpa or ip6.arpa).
4.6.2. Phase 2 Parameters
The initiator MUST propose a tunnel between the ultimate sender
("Alice" or "A") and ultimate recipient ("Bob" or "B") using 3DES-CBC
mode, MD5, or SHA1 authentication. Perfect Forward Secrecy MUST be
specified.
Tunnel mode MUST be used.
Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
Authorization for the initiator to act on Alice’s behalf is
determined by looking for a TXT record in the reverse-map at Alice’s
IP address.
Compression SHOULD NOT be mandatory. It MAY be offered as an option.
5. DNS Issues
5.1. Use of KEY Record
In order to establish their own identities, security gateways SHOULD
publish their public keys in their reverse DNS via DNSSEC’s KEY
record. See section 3 of RFC 2535 [RFC2535].
For example:
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
0x4200: The flag bits, indicating that this key is prohibited for
confidentiality use (it authenticates the peer only, a separate
Diffie-Hellman exchange is used for confidentiality), and that
this key is associated with the non-zone entity whose name is the
RR owner name. No other flags are set.
4: This indicates that this key is for use by IPsec.
1: An RSA key is present.
AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in
[RFC3110].
Use of several KEY records allows for key roll-over. The SIG Payload
in IKE phase 1 SHOULD be accepted if the public key, given by any KEY
RR, validates it.
5.2. Use of TXT Delegation Record
If, for example, machine Alice wishes SG-A to act on her behalf, then
she publishes a TXT record to provide authorization for SG-A to act
on Alice’s behalf. This is done similarly for Bob and SG-B.
These records are located in the reverse DNS (in-addr.arpa or
ip6.arpa) for their respective IP addresses. The reverse DNS SHOULD
be secured by DNSSEC. DNSSEC is required to defend against active
attacks.
If Alice’s address is P.Q.R.S, then she can authorize another node to
act on her behalf by publishing records at:
S.R.Q.P.in-addr.arpa
The contents of the resource record are expected to be a string that
uses the following syntax, as suggested in RFC1464 [RFC1464]. (Note
that the reply to query may include other TXT resource records used
by other applications.)
X-IPsec-Server(P)=A.B.C.D public-key
Figure 2: Format of reverse delegation record
P: Specifies a precedence for this record. This is similar to MX
record preferences. Lower numbers have stronger preference.
A.B.C.D: Specifies the IP address of the Security Gateway for this
client machine.
public-key: Is the encoded RSA Public key of the Security Gateway.
The public-key is provided here to avoid a second DNS lookup. If
this field is absent, then a KEY resource record should be looked
up in the reverse-map of A.B.C.D. The key is transmitted in
base64 format.
The fields of the record MUST be separated by whitespace. This MAY
be: space, tab, newline, or carriage return. A space is preferred.
In the case where Alice is located at a public address behind a
security gateway that has no fixed address (or no control over its
reverse-map), then Alice may delegate to a public key by domain name.
X-IPsec-Server(P)=@FQDN public-key
Figure 3: Format of reverse delegation record (FQDN version)
P: Is as above.
FQDN: Specifies the FQDN that the Security Gateway will identify
itself with.
public-key: Is the encoded RSA Public key of the Security Gateway.
If there is more than one such TXT record with strongest (lowest
numbered) precedence, one Security Gateway is picked arbitrarily from
those specified in the strongest-preference records.
5.2.1. Long TXT Records
When packed into wire-format, TXT records that are longer than 255
characters are divided into smaller <character-strings>. (See
[RFC1035] section 3.3 and 3.3.14.) These MUST be reassembled into a
single string for processing. Whitespace characters in the base64
encoding are to be ignored.
5.2.2. Choice of TXT Record
It has been suggested to use the KEY, OPT, CERT, or KX records
instead of a TXT record. None is satisfactory.
The KEY RR has a protocol field that could be used to indicate a new
protocol, and an algorithm field that could be used to indicate
different contents in the key data. However, the KEY record is
clearly not intended for storing what are really authorizations, it
is just for identities. Other uses have been discouraged.
OPT resource records, as defined in [RFC2671], are not intended to be
used for storage of information. They are not to be loaded, cached
or forwarded. They are, therefore, inappropriate for use here.
CERT records [RFC2538] can encode almost any set of information. A
custom type code could be used permitting any suitable encoding to be
stored, not just X.509. According to the RFC, the certificate RRs
are to be signed internally, which may add undesirable and
unnecessary bulk. Larger DNS records may require TCP instead of UDP
transfers.
At the time of protocol design, the CERT RR was not widely deployed
and could not be counted upon. Use of CERT records will be
investigated, and may be proposed in a future revision of this
document.
KX records are ideally suited for use instead of TXT records, but had
not been deployed at the time of implementation.
5.3. Use of FQDN IDs
Unfortunately, not every administrator has control over the contents
of the reverse-map. Where the initiator (SG-A) has no suitable
reverse-map, the authorization record present in the reverse-map of
Alice may refer to a FQDN instead of an IP address.
In this case, the client’s TXT record gives the fully qualified
domain name (FQDN) in place of its security gateway’s IP address.
The initiator should use the ID_FQDN ID-payload in phase 1. A
forward lookup for a KEY record on the FQDN must yield the
initiator’s public key.
This method can also be used when the external address of SG-A is
dynamic.
If SG-A is acting on behalf of Alice, then Alice must still delegate
authority for SG-A to do so in her reverse-map. When Alice and SG-A
are one and the same (i.e., Alice is acting as an end-node) then
there is no need for this when initiating only.
However, Alice must still delegate to herself if she wishes others to
initiate OE to her. See Figure 3.
5.4. Key Roll-Over
Good cryptographic hygiene says that one should replace
public/private key pairs periodically. Some administrators may wish
to do this as often as daily. Typical DNS propagation delays are
determined by the SOA Resource Record MINIMUM parameter, which
controls how long DNS replies may be cached. For reasonable
operation of DNS servers, administrators usually want this value to
be at least several hours, sometimes as a long as a day. This
presents a problem: a new key MUST not be used prior to its
propagation through DNS.
This problem is dealt with by having the Security Gateway generate a
new public/private key pair, at least MINIMUM seconds in advance of
using it. It then adds this key to the DNS (both as a second KEY
record and in additional TXT delegation records) at key generation
time. Note: only one key is allowed in each TXT record.
When authenticating, all gateways MUST have available all public keys
that are found in DNS for this entity. This permits the
authenticating end to check both the key for "today" and the key for
"tomorrow". Note that it is the end which is creating the signature
(possesses the private key) that determines which key is to be used.
6. Network Address Translation Interaction
There are no fundamentally new issues for implementing opportunistic
encryption in the presence of network address translation. Rather,
there are only the regular IPsec issues with NAT traversal.
There are several situations to consider for NAT.
6.1. Co-Located NAT/NAPT
If a security gateway is also performing network address translation
on behalf of an end-system, then the packet should be translated
prior to being subjected to opportunistic encryption. This is in
contrast to typically configured tunnels, which often exist to bridge
islands of private network address space. The security gateway will
use the translated source address for phase 2, and so the responding
security gateway will look up that address to confirm SG-A’s
authorization.
In the case of NAT (1:1), the address space into which the
translation is done MUST be globally unique, and control over the
reverse-map is assumed. Placing of TXT records is possible.
In the case of NAPT (m:1), the address will be the security gateway
itself. The ability to get KEY and TXT records in place will again
depend upon whether or not there is administrative control over the
reverse-map. This is identical to situations involving a single host
acting on behalf of itself. For initiators (but not responders), an
FQDN-style ID can be used to get around a lack of a reverse-map.
6.2. Security Gateway behind a NAT/NAPT
If there is a NAT or NAPT between the security gateways, then normal
IPsec NAT traversal problems occur. In addition to the transport
problem, which may be solved by other mechanisms, there is the issue
of what phase 1 and phase 2 IDs to use. While FQDN could be used
during phase 1 for the security gateway, there is no appropriate ID
for phase 2. Due to the NAT, the end systems live in different IP
address spaces.
6.3. End System behind a NAT/NAPT
If the end system is behind a NAT (perhaps SG-B), then there is, in
fact, no way for another end system to address a packet to this end
system. Not only is opportunistic encryption impossible, but it is
also impossible for any communication to be initiated to the end
system. It may be possible for this end system to initiate such
communication. This creates an asymmetry, but this is common for
NAPT.
7. Host Implementations
When Alice and SG-A are components of the same system, they are
considered to be a host implementation. The packet sequence scenario
remains unchanged.
Components marked Alice are the upper layers (TCP, UDP, the
application), and SG-A is the IP layer.
Note that tunnel mode is still required.
As Alice and SG-A are acting on behalf of themselves, no TXT based
delegation record is necessary for Alice to initiate. She can rely
on FQDN in a forward map. This is particularly attractive to mobile
nodes such as notebook computers at conferences. To respond,
Alice/SG-A will still need an entry in Alice’s reverse-map.
8. Multi-Homing
If there are multiple paths between Alice and Bob (as illustrated in
the diagram with SG-D), then additional DNS records are required to
establish authorization.
In Figure 1, Alice has two ways to exit her network: SG-A and SG-D.
Previously, SG-D has been ignored. Postulate that there are routers
between Alice and her set of security gateways (denoted by the +
signs and the marking of an autonomous system number for Alice’s
network). Datagrams may, therefore, travel to either SG-A or SG-D en
route to Bob.
As long as all network connections are in good order, it does not
matter how datagrams exit Alice’s network. When they reach either
security gateway, the security gateway will find the TXT delegation
record in Bob’s reverse-map, and establish an SA with SG-B.
SG-B has no problem establishing that either of SG-A or SG-D may
speak for Alice, because Alice has published two equally weighted TXT
delegation records:
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
Figure 4: Multiple gateway delegation example for Alice
Alice’s routers can now do any kind of load sharing needed. Both
SG-A and SG-D send datagrams addressed to Bob through their tunnel to
SG-B.
Alice’s use of non-equal weight delegation records to show preference
of one gateway over another, has relevance only when SG-B is
initiating to Alice.
If the precedences are the same, then SG-B has a more difficult time.
It must decide which of the two tunnels to use. SG-B has no
information about which link is less loaded, nor which security
gateway has more cryptographic resources available. SG-B, in fact,
has no knowledge of whether both gateways are even reachable.
The Public Internet’s default-free zone may well know a good route to
Alice, but the datagrams that SG-B creates must be addressed to
either SG-A or SG-D; they can not be addressed to Alice directly.
SG-B may make a number of choices:
1. It can ignore the problem and round robin among the tunnels.
This causes losses during times when one or the other security
gateway is unreachable. If this worries Alice, she can change
the weights in her TXT delegation records.
2. It can send to the gateway from which it most recently received
datagrams. This assumes that routing and reachability are
symmetrical.
3. It can listen to BGP information from the Internet to decide
which system is currently up. This is clearly much more
complicated, but if SG-B is already participating in the BGP
peering system to announce Bob, the results data may already be
available to it.
4. It can refuse to negotiate the second tunnel. (It is unclear
whether or not this is even an option.)
5. It can silently replace the outgoing portion of the first tunnel
with the second one while still retaining the incoming portions
of both. Thus, SG-B can accept datagrams from either SG-A or
SG-D, but send only to the gateway that most recently re-keyed
with it.
Local policy determines which choice SG-B makes. Note that even if
SG-B has perfect knowledge about the reachability of SG-A and SG-D,
Alice may not be reachable from either of these security gateways
because of internal reachability issues.
FreeS/WAN implements option 5. Implementing a different option is
being considered. The multi-homing aspects of OE are not well
developed and may be the subject of a future document.
9. Failure Modes
9.1. DNS Failures
If a DNS server fails to respond, local policy decides whether or not
to permit communication in the clear as embodied in the connection
classes in Section 3.2. It is easy to mount a denial of service
attack on the DNS server responsible for a particular network’s
reverse-map. Such an attack may cause all communication with that
network to go in the clear if the policy is permissive, or fail
completely if the policy is paranoid. Please note that this is an
active attack.
There are still many networks that do not have properly configured
reverse-maps. Further, if the policy is not to communicate, the
above denial of service attack isolates the target network.
Therefore, the decision of whether or not to permit communication in
the clear MUST be a matter of local policy.
9.2. DNS Configured, IKE Failures
DNS records claim that opportunistic encryption should occur, but the
target gateway either does not respond on port 500, or refuses the
proposal. This may be because of a crash or reboot, a faulty
configuration, or a firewall filtering port 500.
The receipt of ICMP port, host or network unreachable messages
indicates a potential problem, but MUST NOT cause communication to
fail immediately. ICMP messages are easily forged by attackers. If
such a forgery caused immediate failure, then an active attacker
could easily prevent any encryption from ever occurring, possibly
preventing all communication.
In these situations a log should be produced and local policy should
dictate if communication is then permitted in the clear.
9.3. System Reboots
Tunnels sometimes go down because the remote end crashes,
disconnects, or has a network link break. In general there is no