create additional connection classes to further refine these
policies.
The simplest system may need only the "OE-permissive" connection, and
would list its own (single) IP address as the source address of this
policy and the wild-card address 0.0.0.0/0 as the destination IPv4
address. That is, the simplest policy is to try opportunistic
encryption with all destinations.
This simplest policy SHOULD be offered as a preconfigured default.
The distinction between permissive and paranoid Opportunistic
Encryption ("OE-paranoid" below) use will become clear in the state
transition differences.
In brief, an OE-permissive policy means to permit traffic to flow in
the clear when there is a failure to find and/or use the encryption
keys. OE-permissive permits the network to function, even if in an
insecure manner.
On failure, a paranoid OE ("OE-paranoid") will install a drop policy.
OE-paranoid permits traffic to flow only when appropriate security is
available.
In this description of the keying machine’s state transitions, the
states associated with the keying system itself are omitted because
they are best documented in the keying system ([RFC2407], [RFC2408],
and [RFC2409] for ISAKMP/IKE), and the details are keying system
specific. Opportunistic encryption is not dependent upon any
specific keying protocol, but this document does provide requirements
for those using ISAKMP/IKE to assure that implementations inter-
operate.
The state transitions that may be involved in communicating with the
forwarding plane are omitted. PF_KEY and similar protocols have
their own set of states required for message sends and completion
notifications.
Finally, the retransmits and recursive lookups that are normal for
DNS are not included in this description of the state machine.
|
| PF_ACQUIRE
|
V
.---------------.
| nonexistent |
| connection |
`---------------’
| | |
send , | \
expired pass / | \ send
conn. msg / | \ deny
^ / | \ msg
| V | do \
.---------------. | DNS \ .---------------.
| clear-text | | lookup `->| deny |--->expired
| connection | | for | connection | connection
`---------------’ | destination `---------------’
^ ^ | ^
| | no record | |
| | OE-permissive V | no record
| | .---------------. | OE-paranoid
| `------------| potential OE |---------’
| | connection | ^
| `---------------’ |
| | |
| | got TXT record | DNSSEC failure
| | reply |
| V | wrong
| .---------------. | failure
| | authenticate |---------’
| | & parse TXT RR| ^
| repeated `---------------’ |
| ICMP | |
| failures | initiate IKE to |
| (short timeout) | responder |
| V |
| phase-2 .---------------. | failure
| failure | pending |---------’
| (normal | OE | ^
| timeout) | |invalid | phase-2 fail (normal
| | |<--.SPI | timeout)
| | | | | ICMP failures (short
| | +=======+ |---’ | timeout)
| | | IKE | | ^ |
`----------------| states|---------------’
| +=======+ | |
`---------------’ |
| IPsec SA | invalid SPI
| established |
V | rekey time
.--------------. |
| keyed |<---|------------------------------.
| connection |----’ |
`--------------’ |
| timer |
| |
V |
.--------------. connection still active |
clear-text----->| expired |-----------------------------------’
deny----->| connection |
`--------------’
| dead connection - deleted
V
3.2.1. Nonexistent Connection
There is no connection instance for a given source/destination
address pair. Upon receipt of a request for keying material for this
source/destination pair, the initiator searches through the
connection classes to determine the most appropriate policy. Upon
determining an appropriate connection class, an instance object is
created of that type. Both of the OE types result in a potential OE
connection.
Failure to find an appropriate connection class results in an
administrator-defined default.
In each case, when the initiator finds an appropriate class for the
new flow, an instance connection is made of the class that matched.
3.2.2. Clear-Text Connection
The nonexistent connection makes a transition to this state when an
always-clear-text class is instantiated, or when an OE-permissive
connection fails. During the transition, the initiator creates a
pass-through policy object in the forwarding plane for the
appropriate flow.
Timing out is the only way to leave this state (see Section 3.2.7).
3.2.3. Deny Connection
The empty connection makes a transition to this state when a deny
class is instantiated, or when an OE-paranoid connection fails.
During the transition, the initiator creates a deny policy object in
the forwarding plane for the appropriate flow.
Timing out is the only way to leave this state (see Section 3.2.7).
3.2.4. Potential OE Connection
The empty connection makes a transition to this state when one of
either OE class is instantiated. During the transition to this
state, the initiator creates a hold policy object in the forwarding
plane for the appropriate flow.
In addition, when making a transition into this state, DNS lookup is
done in the reverse-map for a TXT delegation resource record (see
Section 5.2). The lookup key is the destination address of the flow.
There are three ways to exit this state:
1. DNS lookup finds a TXT delegation resource record.
2. DNS lookup does not find a TXT delegation resource record.
3. DNS lookup times out.
Based upon the results of the DNS lookup, the potential OE connection
makes a transition to the pending OE connection state. The
conditions for a successful DNS look are:
1. DNS finds an appropriate resource record.
2. It is properly formatted according to Section 5.2.
3. If DNSSEC is enabled, then the signature has been vouched for.
Note that if the initiator does not find the public key present in
the TXT delegation record, then the public key must be looked up as a
sub-state. Only successful completion of all the DNS lookups is
considered a success.
If DNS lookup does not find a resource record or if DNS times out,
then the initiator considers the receiver not OE capable. If this is
an OE-paranoid instance, then the potential OE connection makes a
transition to the deny connection state. If this is an OE-permissive
instance, then the potential OE connection makes a transition to the
clear-text connection state.
If the initiator finds a resource record, but it is not properly
formatted, or if DNSSEC is enabled and reports a failure to
authenticate, then the potential OE connection makes a transition to
the deny connection state. This action SHOULD be logged. If the
administrator wishes to override this transition between states, then
an always-clear class can be installed for this flow. An
implementation MAY make this situation a new class.
3.2.4.1. Restriction on Unauthenticated TXT Delegation Records
An implementation SHOULD also provide an additional administrative
control on delegation records and DNSSEC. This control would apply
to delegation records (the TXT records in the reverse-map) that are
not protected by DNSSEC. Records of this type are only permitted to
delegate to their own address as a gateway. When this option is
enabled, an active attack on DNS will be unable to redirect packets
to other than the original destination.
3.2.5. Pending OE Connection
The potential OE connection makes a transition to this state when the
initiator determines that all the information required from the DNS
lookup is present. Upon entering this state, the initiator attempts
to initiate keying to the gateway provided.
Exit from this state occurs with either a successfully created IPsec
SA or a failure of some kind. Successful SA creation results in a
transition to the key connection state.
Three failures have caused significant problems. They are clearly
not the only possible failures from keying.
Note that if there are multiple gateways available in the TXT
delegation records, then a failure can only be declared after all of
them have been tried. Further, creation of a phase 1 SA does not
constitute success. A set of phase 2 SAs (a tunnel) is considered
success.
The first failure occurs when an ICMP port unreachable is
consistently received without any other communication, or when there
is silence from the remote end. This usually means that either the
gateway is not alive, or the keying daemon is not functional. For an
OE-permissive connection, the initiator makes a transition to the
clear-text connection, but with a low lifespan. For an OE-
pessimistic connection, the initiator makes a transition to the deny
connection again with a low lifespan. The lifespan in both cases is
kept low because the remote gateway may be in the process of
rebooting or be otherwise temporarily unavailable.
The length of time to wait for the remote keying daemon to wake up is
a matter of some debate. If there is a routing failure, 5 minutes is
usually long enough for the network to re-converge. Many systems can
reboot in that amount of time as well. However, 5 minutes is far too
long for most users to wait to hear that they can not connect using
OE. Implementations SHOULD make this a tunable parameter.
The second failure occurs after a phase 1 SA has been created, but
there is either no response to the phase 2 proposal, or the initiator
receives a negative notify (the notify must be authenticated). The
remote gateway is not prepared to do OE at this time. As before, the
initiator makes a transition to the clear-text or the deny connection
based upon connection class, but this time with a normal lifespan.
The third failure occurs when there is signature failure while
authenticating the remote gateway. This can occur when there has
been a key roll-over, but DNS has not caught up. In this case again,
the initiator makes a transition to the clear-text or the deny
connection based upon the connection class. However, the lifespan
depends upon the remaining time to live in the DNS. (Note that
DNSSEC signed resource records have a different expiry time from
non-signed records.)
3.2.6. Keyed Connection
The pending OE connection makes a transition to this state when
session keying material (the phase 2 SAs) is derived. The initiator
creates an encrypt policy in the forwarding plane for this flow.
There are three ways to exit this state. The first is by receipt of
an authenticated delete message (via the keying channel) from the
peer. This is normal teardown and results in a transition to the
expired connection state.
The second exit is by expiry of the forwarding plane keying material.
This starts a re-key operation with a transition back to pending OE
connection. In general, the soft expiry occurs with sufficient time
left to continue using the keys. A re-key can fail, which may result
in the connection failing to clear-text or deny as appropriate. In
the event of a failure, the forwarding plane policy does not change
until the phase 2 SA (IPsec SA) reaches its hard expiry.
The third exit is in response to a negotiation from a remote gateway.
If the forwarding plane signals the control plane that it has
received an unknown SPI from the remote gateway, or an ICMP is
received from the remote gateway indicating an unknown SPI, the
initiator should consider that the remote gateway has rebooted or
restarted. Since these indications are easily forged, the
implementation must exercise care. The initiator should make a
cautious (rate-limited) attempt to re-key the connection.
3.2.7. Expiring Connection
The initiator will periodically place each of the deny, clear-text,
and keyed connections into this sub-state. See Section 3.4 for more
details of how often this occurs. The initiator queries the
forwarding plane for last use time of the appropriate policy. If the
last use time is relatively recent, then the connection returns to
the previous deny, clear-text or keyed connection state. If not,
then the connection enters the expired connection state.
The DNS query and answer that lead to the expiring connection state
are also examined. The DNS query may become stale. (A negative,
i.e., no such record, answer is valid for the period of time given by
the MINIMUM field in an attached SOA record. See [RFC1034] section
4.3.4.) If the DNS query is stale, then a new query is made. If the
results change, then the connection makes a transition to a new state
as described in potential OE connection state.
Note that when considering how stale a connection is, both outgoing
SPD and incoming SAD must be queried as some flows may be
unidirectional for some time.
Also note that the policy at the forwarding plane is not updated
unless there is a conclusion that there should be a change.
3.2.8. Expired Connection
Entry to this state occurs when no datagrams have been forwarded
recently via the appropriate SPD and SAD objects. The objects in the
forwarding plane are removed (logging any final byte and packet
counts, if appropriate) and the connection instance in the keying
plane is deleted.
The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs
as described in Section 3.4.
Whether or not to delete the phase 1 SAs at this time is left as a
local implementation issue. Implementations that do delete the phase
1 SAs MUST send authenticated delete messages to indicate that they
are doing so. There is an advantage to keeping the phase 1 SAs until
they expire: they may prove useful again in the near future.
3.3. Keying Daemon -- Responder
The responder has a set of objects identical to those of the
initiator.
The responder receives an invitation to create a keying channel from
an initiator.
|
| IKE main mode
| phase 1
V
.-----------------.
| unauthenticated |
| OE peer |
`-----------------’
|
| lookup KEY RR in in-addr.arpa
| (if ID_IPV4_ADDR)
| lookup KEY RR in forward
| (if ID_FQDN)
V
.-----------------. RR not found
| received DNS |---------------> log failure
| reply |
`----+--------+---’
phase 2 | \ misformatted
proposal | `------------------> log failure
V
.----------------.
| authenticated | identical initiator
| OE peer |--------------------> initiator
`----------------’ connection found state machine
|
| look for TXT record for initiator
|
V
.---------------.
| authorized |---------------------> log failure
| OE peer |
`---------------’
|
|
V
potential OE
connection in
initiator state
machine
3.3.1. Unauthenticated OE Peer
Upon entering this state, the responder starts a DNS lookup for a KEY
record for the initiator. The responder looks in the reverse-map for
a KEY record for the initiator if the initiator has offered an
ID_IPV4_ADDR, and in the forward map if the initiator has offered an
ID_FQDN type. (See [RFC2407] section 4.6.2.1.)
The responder exits this state upon successful receipt of a KEY from
DNS, and use of the key to verify the signature of the initiator.
Successful authentication of the peer results in a transition to the
authenticated OE Peer state.
Note that the unauthenticated OE peer state generally occurs in the
middle of the key negotiation protocol. It is really a form of
pseudo-state.
3.3.2. Authenticated OE Peer
The peer will eventually propose one or more phase 2 SAs. The
responder uses the source and destination address in the proposal to
finish instantiating the connection state using the connection class
table. The responder MUST search for an identical connection object
at this point.
If an identical connection is found, then the responder deletes the
old instance, and the new object makes a transition to the pending OE
connection state. This means that new ISAKMP connections with a
given peer will always use the latest instance, which is the correct
one if the peer has rebooted in the interim.
If an identical connection is not found, then the responder makes the
transition according to the rules given for the initiator: it
installs appropriate policy: clear, drop, or OE.
If OE, and the phase 2 ID (source IP) is different than the phase 1
ID, then additional authorization is required. A TXT record
associated with the proposed phase 2 source IP is requested. This is
used to confirm authorization for the phase 1 identity to encrypt on
behalf of the phase 2. Successful retrieval results in a transition
to "Authorized OE Peer".
Note that if the initiator is in OE-paranoid mode and the responder
is in either always-clear-text or deny, then no communication is
possible according to policy. An implementation is permitted to
create new types of policies such as "accept OE but do not initiate
it". This is a local matter.
3.3.3. Authorized OE Peer
This state is entered from the Authenticated OE Peer state, upon
successful retrieval of the TXT record. The contents of the record
are confirmed -- any failures lead to errors, as indicated in Section
3.2.4.
3.4. Renewal and Teardown
3.4.1. Aging
A potentially unlimited number of tunnels may exist. In practice,
only a few tunnels are used during a period of time. Unused tunnels
MUST, therefore, be torn down. Detecting when tunnels are no longer
in use is the subject of this section.
There are two methods for removing tunnels: explicit deletion or
expiry.
Explicit deletion requires an IKE delete message. The deletes MUST
be authenticated, so both ends of the tunnel must maintain the keying
channel (phase 1 ISAKMP SA). An implementation that refuses to
either maintain or recreate the keying channel SA will be unable to
use this method.
The tunnel expiry method simply allows the IKE daemon to expire
normally without attempting to re-key it.