ims-volte-vowifi
/
strongswan
9
0
Fork 0
Code Pull Requests Releases Activity
strongswan/doc/opportunism-spec.txt

1255 lines
48 KiB
Plaintext
Raw Blame History

Opportunistic Encryption
Henry Spencer
D. Hugh Redelmeier
henry@spsystems.net
hugh@mimosa.com
Linux FreeS/WAN Project
Opportunistic encryption permits secure
(encrypted, authenticated) communication via IPsec
without connection-by-connection prearrangement,
either explicitly between hosts (when the hosts
are capable of it) or transparently via packet-
intercepting security gateways. It uses DNS
records (authenticated with DNSSEC) to provide the
necessary information for gateway discovery and
gateway authentication, and constrains negotiation
enough to guarantee success.
Substantive changes since draft 3: write off
inverse queries as a lost cause; use Invalid-SPI
rather than Delete as notification of unknown SA;
minor wording improvements and clarifications.
This document takes over from the older ``Imple-
menting Opportunistic Encryption'' document.
1. Introduction
A major goal of the FreeS/WAN project is opportunistic
encryption: a (security) gateway intercepts an outgoing
packet aimed at a remote host, and quickly attempts to nego-
tiate an IPsec tunnel to that host's security gateway. If
the attempt succeeds, traffic can then be secure, transpar-
ently (without changes to the host software). If the
attempt fails, the packet (or a retry thereof) passes
through in clear or is dropped, depending on local policy.
Prearranged tunnels bypass the packet interception etc., so
static VPNs can coexist with opportunistic encryption.
This generalizes trivially to the end-to-end case: host and
security gateway simply are one and the same. Some opti-
mizations are possible in that case, but the basic scheme
need not change.
The objectives for security systems need to be explicitly
stated. Opportunistic encryption is meant to achieve secure
communication, without prearrangement of the individual con-
nection (although some prearrangement on a per-host basis is
Draft 4 3 May 2001 1
Opportunistic Encryption
required), between any two hosts which implement the proto-
col (and, if they act as security gateways, between hosts
behind them). Here ``secure'' means strong encryption and
authentication of packets, with authentication of partici-
pants--to prevent man-in-the-middle and impersonation
attacks--dependent on several factors. The biggest factor
is the authentication of DNS records, via DNSSEC or equiva-
lent means. A lesser factor is which exact variant of the
setup procedure (see section 2.2) is used, because there is
a tradeoff between strong authentication of the other end
and ability to negotiate opportunistic encryption with hosts
which have limited or no control of their reverse-map DNS
records: without reverse-map information, we can verify that
the host has the right to use a particular FQDN (Fully Qual-
ified Domain Name), but not whether that FQDN is authorized
to use that IP address. Local policy must decide whether
authentication or connectivity has higher priority.
Apart from careful attention to detail in various areas,
there are three crucial design problems for opportunistic
encryption. It needs a way to quickly identify the remote
host's security gateway. It needs a way to quickly obtain
an authentication key for the security gateway. And the
numerous options which can be specified with IKE must be
constrained sufficiently that two independent implementa-
tions are guaranteed to reach agreement, without any
explicit prearrangement or preliminary negotiation. The
first two problems are solved using DNS, with DNSSEC ensur-
ing that the data obtained is reliable; the third is solved
by specifying a minimum standard which must be supported.
A note on philosophy: we have deliberately avoided providing
six different ways to do each job, in favor of specifying
one good one. Choices are provided only when they appear to
be necessary, or at least important.
A note on terminology: to avoid constant circumlocutions, an
ISAKMP/IKE SA, possibly recreated occasionally by rekeying,
will be referred to as a ``keying channel'', and a set of
IPsec SAs providing bidirectional communication between two
IPsec hosts, possibly recreated occasionally by rekeying,
will be referred to as a ``tunnel'' (it could conceivably
use transport mode in the host-to-host case, but we advocate
using tunnel mode even there). The word ``connection'' is
here used in a more generic sense. The word ``lifetime''
will be avoided in favor of ``rekeying interval'', since
many of the connections will have useful lives far shorter
than any reasonable rekeying interval, and hence the two
concepts must be separated.
A note on document structure: Discussions of why things were
done a particular way, or not done a particular way, are
broken out in paragraphs headed ``Rationale:'' (to preserve
the flow of the text, many such paragraphs are deferred to
Draft 4 3 May 2001 2
Opportunistic Encryption
the ends of sections). Paragraphs headed ``Ahem:'' are dis-
cussions of where the problem is being made significantly
harder by problems elsewhere, and how that might be cor-
rected. Some meta-comments are enclosed in [].
Rationale: The motive is to get the Internet encrypted.
That requires encryption without connection-by-connection
prearrangement: a system must be able to reliably negotiate
an encrypted, authenticated connection with a total
stranger. While end-to-end encryption is preferable, doing
opportunistic encryption in security gateways gives enormous
leverage for quick deployment of this technology, in a world
where end-host software is often primitive, rigid, and out-
dated.
Rationale: Speed is of the essence in tunnel setup: a con-
nection-establishment delay longer than about 10 seconds
begins to cause problems for users and applications. Thus
the emphasis on rapidity in gateway discovery and key fetch-
ing.
Ahem: Host-to-host opportunistic encryption would be utterly
trivial if a fast public-key encryption/signature algorithm
was available. You would do a reverse lookup on the desti-
nation address to obtain a public key for that address, and
simply encrypt all packets going to it with that key, sign-
ing them with your own private key. Alas, this is impracti-
cal with current CPU speeds and current algorithms (although
as noted later, it might be of some use for limited pur-
poses). Nevertheless, it is a useful model.
2. Connection Setup
For purposes of discussion, the network is taken to look
like this:
Source----Initiator----...----Responder----Destination
The intercepted packet comes from the Source, bound for the
Destination, and is intercepted at the Initiator. The Ini-
tiator communicates over the insecure Internet to the
Responder. The Source and the Initiator might be the same
host, or the Source might be an end-user host and the Ini-
tiator a security gateway (SG). Likewise for the Responder
and the Destination.
Given an intercepted packet, whose useful information (for
our purposes) is essentially only the Destination's IP
address, the Initiator must quickly determine the Responder
(the Destination's SG) and fetch everything needed to
authenticate it. The Responder must do likewise for the
Initiator. Both must eventually also confirm that the other
is authorized to act on behalf of the client host behind it
(if any).
Draft 4 3 May 2001 3
Opportunistic Encryption
An important subtlety here is that if the alternative to an
IPsec tunnel is plaintext transmission, negative results
must be obtained quickly. That is, the decision that no
tunnel can be established must also be made rapidly.
2.1. Packet Interception
Interception of outgoing packets is relatively straightfor-
ward in principle. It is preferable to put the intercepted
packet on hold rather than dropping it, since higher-level
retries are not necessarily well-timed. There is a problem
of hosts and applications retrying during negotiations. ARP
implementations, which face the same problem, use the
approach of keeping the most recent packet for an as-yet-
unresolved address, and throwing away older ones. (Incre-
menting of request numbers etc. means that replies to older
ones may no longer be accepted.)
Is it worth intercepting incoming packets, from the outside
world, and attempting tunnel setup based on them? No,
unless and until a way can be devised to initiate oppor-
tunistic encryption to a non-opportunistic responder,
because if the other end has not initiated tunnel setup
itself, it will not be prepared to do so at our request.
Rationale: Note, however, that most incoming packets will
promptly be followed by an outgoing packet in response!
Conceivably it might be useful to start early stages of
negotiation, at least as far as looking up information, in
response to an incoming packet.
Rationale: If a plaintext incoming packet indicates that the
other end is not prepared to do opportunistic encryption, it
might seem that this fact should be noted, to avoid consum-
ing resources and delaying traffic in an attempt at oppor-
tunistic setup which is doomed to fail. However, this would
be a major security hole, since the plaintext packet is not
authenticated; see section 2.5.
2.2. Algorithm
For clarity, the following defers most discussion of error
handling to the end.
Step 1. Initiator does a DNS reverse lookup on the Destina-
tion address, asking not for the usual PTR records,
but for TXT records. Meanwhile, Initiator also
sends a ping to the Destination, to cause any other
dynamic setup actions to start happening. (Ping
replies are disregarded; the host might not be
reachable with plaintext pings.)
Step 2A. If at least one suitable TXT record (see section
2.3) comes back, each contains a potential
Draft 4 3 May 2001 4
Opportunistic Encryption
Responder's IP address and that Responder's public
key (or where to find it). Initiator picks one TXT
record, based on priority (see 2.3), thus picking a
Responder. If there was no public key in the TXT
record, the Initiator also starts a DNS lookup (as
specified by the TXT record) to get KEY records.
Step 2B. If no suitable TXT record is available, and policy
permits, Initiator designates the Destination
itself as the Responder (see section 2.4). If pol-
icy does not permit, or the Destination is unre-
sponsive to the negotiation, then opportunistic
encryption is not possible, and Initiator gives up
(see section 2.5).
Step 3. If there already is a keying channel to the Respon-
der's IP address, the Initiator uses the existing
keying channel; skip to step 10. Otherwise, the
Initiator starts an IKE Phase 1 negotiation (see
section 2.7 for details) with the Responder. The
address family of the Responder's IP address dic-
tates whether the keying channel and the outside of
the tunnel should be IPv4 or IPv6.
Step 4. Responder gets the first IKE message, and responds.
It also starts a DNS reverse lookup on the Initia-
tor's IP address, for KEY records, on speculation.
Step 5. Initiator gets Responder's reply, and sends first
message of IKE's D-H exchange (see 2.4).
Step 6. Responder gets Initiator's D-H message, and
responds with a matching one.
Step 7. Initiator gets Responder's D-H message; encryption
is now established, authentication remains to be
done. Initiator sends IKE authentication message,
with an FQDN identity if a reverse lookup on its
address will not yield a suitable KEY record.
(Note, an FQDN need not actually correspond to a
host--e.g., the DNS data for it need not include an
A record.)
Step 8. Responder gets Initiator's authentication message.
If there is no identity included, Responder waits
for step 4's speculative DNS lookup to finish; it
should yield a suitable KEY record (see 2.3). If
there is an FQDN identity, responder discards any
data obtained from step 4's DNS lookup; does a for-
ward lookup on the FQDN, for a KEY record; waits
for that lookup to return; it should yield a suit-
able KEY record. Either way, Responder uses the
KEY data to verify the message's hash. Responder
replies with an authentication message, with an
Draft 4 3 May 2001 5
Opportunistic Encryption
FQDN identity if a reverse lookup on its address
will not yield a suitable KEY record.
Step 9A. (If step 2A was used.) The Initiator gets the
Responder's authentication message. Step 2A has
provided a key (from the TXT record or via DNS
lookup). Verify message's hash. Encrypted and
authenticated keying channel established, man-in-
middle attack precluded.
Step 9B. (If step 2B was used.) The Initiator gets the
Responder's authentication message, which must con-
tain an FQDN identity (if the Responder can't put a
TXT in his reverse map he presumably can't do a KEY
either). Do forward lookup on the FQDN, get suit-
able KEY record, verify hash. Encrypted keying
channel established, man-in-middle attack pre-
cluded, but authentication weak (see 2.4).
Step 10. Initiator initiates IKE Phase 2 negotiation (see
2.7) to establish tunnel, specifying Source and
Destination identities as IP addresses (see 2.6).
The address family of those addresses also deter-
mines whether the inside of the tunnel should be
IPv4 or IPv6.
Step 11. Responder gets first Phase 2 message. Now the
Responder finally knows what's going on! Unless
the specified Source is identical to the Initiator,
Responder initiates DNS reverse lookup on Source IP
address, for TXT records; waits for result; gets
suitable TXT record(s) (see 2.3), which should con-
tain either the Initiator's IP address or an FQDN
identity identical to that supplied by the Initia-
tor in step 7. This verifies that the Initiator is
authorized to act as SG for the Source. Responder
replies with second Phase 2 message, selecting
acceptable details (see 2.7), and establishes tun-
nel.
Step 12. Initiator gets second Phase 2 message, establishes
tunnel (if he didn't already), and releases the
intercepted packet into it, finally.
Step 13. Communication proceeds. See section 3 for what
happens later.
As additional information becomes available, notably in
steps 1, 2, 4, 8, 9, 11, and 12, there is always a possibil-
ity that local policy (e.g., access limitations) might pre-
vent further progress. Whenever possible, at least attempt
to inform the other end of this.
Draft 4 3 May 2001 6
Opportunistic Encryption
At any time, there is a possibility of the negotiation fail-
ing due to unexpected responses, e.g. the Responder not
responding at all or rejecting all Initiator's proposals.
If multiple SGs were found as possible Responders, the Ini-
tiator should try at least one more before giving up. The
number tried should be influenced by what the alternative
is: if the traffic will otherwise be discarded, trying the
full list is probably appropriate, while if the alternative
is plaintext transmission, it might be based on how long the
tries are taking. The Initiator should try as many as it
reasonably can, ideally all of them.
There is a sticky problem with timeouts. If the Responder
is down or otherwise inaccessible, in the worst case we
won't hear about this except by not getting responses. Some
other, more pathological or even evil, failure cases can
have the same result. The problem is that in the case where
plaintext is permitted, we want to decide whether a tunnel
is possible quickly. There is no good solution to this,
alas; we just have to take the time and do it right. (Pass-
ing plaintext meanwhile looks attractive at first glance...
but exposing the first few seconds of a connection is often
almost as bad as exposing the whole thing. Worse, if the
user checks the status of the connection, after that brief
window it looks secure!)
The flip side of waiting for a timeout is that all other
forms of feedback, e.g. ``host not reachable'', arguably
should be ignored, because in the absence of authenticated
ICMP, you cannot trust them!
Rationale: An alternative, sometimes suggested, to the use
of explicit DNS records for SG discovery is to directly
attempt IKE negotiation with the destination host, and
assume that any relevant SG will be on the packet path, will
intercept the IKE packets, and will impersonate the destina-
tion host for the IKE negotiation. This is superficially
attractive but is a very bad idea. It assumes that routing
is stable throughout negotiation, that the SG is on the
plaintext-packets path, and that the destination host is
routable (yes, it is possible to have (private) DNS data for
an unroutable host). Playing extra games in the plaintext-
packet path hurts performance and can be expected to be
unpopular. Various difficulties ensue when there are multi-
ple SGs along the path (there is already bad experience with
this, in RSVP), and the presence of even one can make it
impossible to do IKE direct to the host when that is what's
wanted. Worst of all, such impersonation breaks the IP net-
work model badly, making problems difficult to diagnose and
impossible to work around (and there is already bad experi-
ence with this, in areas like web caching).
Rationale: (Step 1.) Dynamic setup actions might include
establishment of demand-dialed links. These might be
Draft 4 3 May 2001 7
Opportunistic Encryption
present anywhere along the path, so one cannot rely on out-
of-band communication at the Initiator to trigger them.
Hence the ping.
Rationale: (Step 2.) In many cases, the IP address on the
intercepted packet will be the result of a name lookup just
done. Inverse queries, an obscure DNS feature from the dis-
tant past, in theory can be used to ask a DNS server to
reverse that lookup, giving the name that produced the
address. This is not the same as a reverse lookup, and the
difference can matter a great deal in cases where a host
does not control its reverse map (e.g., when the host's IP
address is dynamically assigned). Unfortunately, inverse
queries were never widely implemented and are now considered
obsolete. Phooey.
Ahem: Support for a small subset of this admittedly-obscure
feature would be useful. Unfortunately, it seems unlikely.
Rationale: (Step 3.) Using only IP addresses to decide
whether there is already a relevant keying channel avoids
some difficult problems. In particular, it might seem that
this should be based on identities, but those are not known
until very late in IKE Phase 1 negotiations.
Rationale: (Step 4.) The DNS lookup is done on speculation
because the data will probably be useful and the lookup can
be done in parallel with IKE activity, potentially speeding
things up.
Rationale: (Steps 7 and 8.) If an SG does not control its
reverse map, there is no way it can prove its right to use
an IP address, but it can nevertheless supply both an iden-
tity (as an FQDN) and proof of its right to use that iden-
tity. This is somewhat better than nothing, and may be
quite useful if the SG is representing a client host which
can prove its right to its IP address. (For example, a
fixed-address subnet might live behind an SG with a dynami-
cally-assigned address; such an SG has to be the Initiator,
not the Responder, so the subnet's TXT records can contain
FQDN identities, but with that restriction, this works.) It
might sound like this would permit some man-in-the-middle
attacks in important cases like Road Warrior, but the RW can
still do full authentication of the home base, so a man in
the middle cannot successfully impersonate home base, and
the D-H exchange doesn't work unless the man in the middle
impersonates both ends.
Rationale: (Steps 7 and 8.) Another situation where proof
of the right to use an identity can be very useful is when
access is deliberately limited. While opportunistic encryp-
tion is intended as a general-purpose connection mechanism
between strangers, it may well be convenient for prearranged
connections to use the same mechanism.
Draft 4 3 May 2001 8
Opportunistic Encryption
Rationale: (Steps 7 and 8.) FQDNs as identities are avoided
where possible, since they can involve synchronous DNS
lookups.
Rationale: (Step 11.) Note that only here, in Phase 2, does
the Responder actually learn who the Source and Destination
hosts are. This unfortunately demands a synchronous DNS
lookup to verify that the Initiator is authorized to repre-
sent the Source, unless they are one and the same. This and
the initial TXT lookup are the only synchronous DNS lookups
absolutely required by the algorithm, and they appear to be
unavoidable.
Rationale: While it might seem unlikely that a refusal to
cooperate from one SG could be remedied by trying another--
presumably they all use the same policies--it's conceivable
that one might be misconfigured. Preferably they should all
be tried, but it may be necessary to set some limits on this
if alternatives exist.
2.3. DNS Records
Gateway discovery and key lookup are based on TXT and KEY
DNS records. The TXT record specifies IP address or other
identity of a host's SG, and possibly supplies its public
key as well, while the KEY record supplies public keys not
found in TXT records.
2.3.1. TXT
Opportunistic-encryption SG discovery uses TXT records with
the content:
X-IPsec-Gateway(nnn)=iii kkk
following RFC 1464 attribute/value notation. Records which
do not contain an ``='', or which do not have exactly the
specified form to the left of it, are ignored. (Near misses
perhaps should be reported.)
The nnn is an unsigned integer which will fit in 16 bits,
specifying an MX-style preference (lower number = stronger
preference) to control the order in which multiple SGs are
tried. If there are ties, pick one, randomly enough that
the choice will probably be different each time. The pref-
erence field is not optional; use ``0'' if there is no mean-
ingful preference ordering.
The iii part identifies the SG. Normally this is a dotted-
decimal IPv4 address or a colon-hex IPv6 address. The sole
exception is if the SG has no fixed address (see 2.4) but
the host(s) behind it do, in which case iii is of the form
``@fqdn'', where fqdn is the FQDN that the SG will use to
identify itself (in step 7 of section 2.2); such a record
Draft 4 3 May 2001 9
Opportunistic Encryption
cannot be used for SG discovery by an Initiator, but can be
used for SG verification (step 11 of 2.2) by a Responder.
The kkk part is optional. If it is present, it is an RSA-
MD5 public key in base-64 notation, as in the text form of
an RFC 2535 KEY record. If it is not present, this speci-
fies that the public key can be found in a KEY record
located based on the SG's identification: if iii is an IP
address, do a reverse lookup on that address, else do a for-
ward lookup on the FQDN.
Rationale: While it is unusual for a reverse lookup to go
for records other than PTR records (or possibly CNAME
records, for RFC 2317 classless delegation), there's no rea-
son why it can't. The TXT record is a temporary stand-in
for (we hope, someday) a new DNS record for SG identifica-
tion and keying. Keeping the setup process fast requires
minimizing the number of DNS lookups, hence the desire to
put all the information in one place.
Rationale: The use of RFC 1464 notation avoids collisions
with other uses of TXT records. The ``X-'' in the attribute
name indicates that this format is tentative and experimen-
tal; this design will probably need modification after ini-
tial experiments. The format is chosen with an eye on even-
tual binary encoding. Note, in particular, that the TXT
record normally contains the address of the SG, not (repeat,
not) its name. Name-to-address conversion is the job of
whatever generates the TXT record, which is expected to be a
program, not a human--this is conceptually a binary record,
temporarily using a text encoding. The ``@fqdn'' form of
the SG identity is for specialized uses and is never mapped
to an address.
Ahem: A DNS TXT record contains one or more character
strings, but RFC 1035 does not describe exactly how a multi-
string TXT record is interpreted. This is relevant because
a string can be at most 255 characters, and public keys can
exceed this. Empirically, the standard pattern is that each
string which is both less than 255 characters and not the
final string of the record should have a blank appended to
it, and the strings of the record should then be concate-
nated. (This observation is based on how BIND 8 transforms
a TXT record from text to DNS binary.)
2.3.2. KEY
An opportunistic-encryption KEY record is an Authentication-
permitted, Entity (host), non-Signatory, IPsec, RSA/MD5
record (that is, its first four bytes are 0x42000401), as
per RFCs 2535 and 2537. KEY records with other flags, pro-
tocol, or algorithm values are ignored.
Draft 4 3 May 2001 10
Opportunistic Encryption
Rationale: Unfortunately, the public key has to be associ-
ated with the SG, not the client host behind it. The
Responder does not know which client it is supposed to be
representing, or which client the Initiator is representing,
until far too late.
Ahem: Per-client keys would reduce vulnerability to key com-
promise, and simplify key changes, but they would require
changes to IKE Phase 1, to separately identify the SG and
its initial client(s). (At present, the client identities
are not known to the Responder until IKE Phase 2.) While
the current IKE standard does not actually specify (!) who
is being identified by identity payloads, the overwhelming
consensus is that they identify the SG, and as seen earlier,
this has important uses.
2.3.3. Summary
For reference, the minimum set of DNS records needed to make
this all work is either:
1. TXT in Destination reverse map, identifying Responder
and providing public key.
2. KEY in Initiator reverse map, providing public key.
3. TXT in Source reverse map, verifying relationship to
Initiator.
or:
1. TXT in Destination reverse map, identifying Responder.
2. KEY in Responder reverse map, providing public key.
3. KEY in Initiator reverse map, providing public key.
4. TXT in Source reverse map, verifying relationship to
Initiator.
Slight complications ensue for dynamic addresses, lack of
control over reverse maps, etc.
2.3.4. Implementation
In the long run, we need either a tree of trust or a web of
trust, so we can trust our DNS data. The obvious approach
for DNS is a tree of trust, but there are various practical
problems with running all of this through the root servers,
and a web of trust is arguably more robust anyway. This is
logically independent of opportunistic encryption, and a
separate design proposal will be prepared.
Draft 4 3 May 2001 11
Opportunistic Encryption
Interim stages of implementation of this will require a bit
of thought. Notably, we need some way of dealing with the
lack of fully signed DNSSEC records right away. Without
user interaction, probably the best we can do is to remember
the results of old fetches, compare them to the results of
new fetches, and complain and disbelieve all of it if
there's a mismatch. This does mean that somebody who gets
fake data into our very first fetch will fool us, at least
for a while, but that seems an acceptable tradeoff. (Obvi-
ously there needs to be a way to manually flush the remem-
bered results for a specific host, to permit deliberate
changes.)
2.4. Responders Without Credentials
In cases where the Destination simply does not control its
DNS reverse-map entries, there is no verifiable way to
determine a suitable SG. This does not make communication
utterly impossible, though.
Simply attempting negotiation directly with the host is a
last resort. (An aggressive implementation might wish to
attempt it in parallel, rather than waiting until other
options are known to be unavailable.) In particular, in
many cases involving dynamic addresses, it will work. It
has the disadvantage of delaying the discovery that oppor-
tunistic encryption is entirely impossible, but the case
seems common enough to justify the overhead.
However, there are policy issues here either way, because it
is possible to impersonate such a host. The host can supply
an FQDN identity and verify its right to use that identity,
but except by prearrangement, there is no way to verify that
the FQDN is the right one for that IP address. (The data
from forward lookups may be controlled by people who do not
own the address, so it cannot be trusted.) The encryption
is still solid, though, so in many cases this may be useful.
2.5. Failure of Opportunism
When there is no way to do opportunistic encryption, a pol-
icy issue arises: whether to put in a bypass (which allows
plaintext traffic through) or a block (which discards it,
perhaps with notification back to the sender). The choice
is very much a matter of local policy, and may depend on
details such as the higher-level protocol being used. For
example, an SG might well permit plaintext HTTP but forbid
plaintext Telnet, in which case both a block and a bypass
would be set up if opportunistic encryption failed.
A bypass/block must, in practice, be treated much like an
IPsec tunnel. It should persist for a while, so that high-
overhead processing doesn't have to be done for every
packet, but should go away eventually to return resources.
Draft 4 3 May 2001 12
Opportunistic Encryption
It may be simplest to treat it as a degenerate tunnel. It
should have a relatively long lifetime (say 6h) to keep the
frequency of negotiation attempts down, except in the case
where the other SG simply did not respond to IKE packets,
where the lifetime should be short (say 10min) because the
other SG is presumably down and might come back up again.
(Cases where the other SG responded to IKE with unauthenti-
cated error reports like ``port unreachable'' are border-
line, and might deserve to be treated as an intermediate
case: while such reports cannot be trusted unreservedly, in
the absence of any other response, they do give some reason
to suspect that the other SG is unable or unwilling to par-
ticipate in opportunistic encryption.)
As noted in section 2.1, one might think that arrival of a
plaintext incoming packet should cause a bypass/block to be
set up for its source host: such a packet is almost always
followed by an outgoing reply packet; the incoming packet is
clear evidence that opportunistic encryption is not avail-
able at the other end; attempting it will waste resources
and delay traffic to no good purpose. Unfortunately, this
means that anyone out on the Internet who can forge a source
address can prevent encrypted communication! Since their
source addresses are not authenticated, plaintext packets
cannot be taken as evidence of anything, except perhaps that
communication from that host is likely to occur soon.
There needs to be a way for local administrators to remove a
bypass/block ahead of its normal expiry time, to force a
retry after a problem at the other end is known to have been
fixed.
2.6. Subnet Opportunism
In principle, when the Source or Destination host belongs to
a subnet and the corresponding SG is willing to provide tun-
nels to the whole subnet, this should be done. There is no
extra overhead, and considerable potential for avoiding
later overhead if similar communication occurs with other
members of the subnet. Unfortunately, at the moment, oppor-
tunistic tunnels can only have degenerate subnets (single
hosts) at their ends. (This does, at least, set up the key-
ing channel, so that negotiations for tunnels to other hosts
in the same subnets will be considerably faster.)
The crucial problem is step 11 of section 2.2: the Responder
must verify that the Initiator is authorized to represent
the Source, and this is impossible for a subnet because
there is no way to do a reverse lookup on it. Information
in DNS records for a name or a single address cannot be
trusted, because they may be controlled by people who do not
control the whole subnet.
Draft 4 3 May 2001 13
Opportunistic Encryption
Ahem: Except in the special case of a subnet masked on a
byte boundary (in which case RFC 1035's convention of an
incomplete in-addr.arpa name could be used), subnet lookup
would need extensions to the reverse-map name space, perhaps
along the lines of that commonly done for RFC 2317 delega-
tion. IPv6 already has suitable name syntax, as in RFC
2874, but has no specific provisions for subnet entries in
its reverse maps. Fixing all this is is not conceptually
difficult, but is logically independent of opportunistic
encryption, and will be proposed separately.
A less-troublesome problem is that the Initiator, in step 10
of 2.2, must know exactly what subnet is present on the
Responder's end so he can propose a tunnel to it. This
information could be included in the TXT record of the Des-
tination (it would have to be verified with a subnet lookup,
but that could be done in parallel with other operations).
The Initiator presumably can be configured to know what sub-
net(s) are present on its end.
2.7. Option Settings
IPsec and IKE have far too many useless options, and a few
useful ones. IKE negotiation is quite simplistic, and can-
not handle even simple discrepancies between the two SGs.
So it is necessary to be quite specific about what should be
done and what should be proposed, to guarantee interoper-
ability without prearrangement or other negotiation proto-
cols.
Rationale: The prohibition of other negotiations is simply
because there is no time. The setup algorithm (section 2.2)
is lengthy already.
[Open question: should opportunistic IKE use a different
port than normal IKE?]
Somewhat arbitrarily and tentatively, opportunistic SGs must
support Main Mode, Oakley group 5 for D-H, 3DES encryption
and MD5 authentication for both ISAKMP and IPsec SAs,
RSA/MD5 digital-signature authentication with keys between
2048 and 8192 bits, and ESP doing both encryption and
authentication. They must do key PFS in Quick Mode, but not
identity PFS. They may support IPComp, preferably using
Deflate, but must not insist on it. They may support AES as
an alternative to 3DES, but must not insist on it.
Rationale: Identity PFS essentially requires establishing a
complete new keying channel for each new tunnel, but key PFS
just does a new Diffie-Hellman exchange for each rekeying,
which is relatively cheap.
Keying channels must remain in existence at least as long as
any tunnel created with them remains (they are not costly,
Draft 4 3 May 2001 14
Opportunistic Encryption
and keeping the management path up and available simplifies
various issues). See section 3.1 for related issues. Given
the use of key PFS, frequent rekeying does not seem critical
here. In the absence of strong reason to do otherwise, the
Initiator should propose rekeying at 8hr-or-1MB. The
Responder must accept any proposal which specifies a rekey-
ing time between 1hr and 24hr inclusive and a rekeying vol-
ume between 100KB and 10MB inclusive.
Given the short expected useful life of most tunnels (see
section 3.1), very few of them will survive long enough to
be rekeyed. In the absence of strong reason to do other-
wise, the Initiator should propose rekeying at 1hr-or-100MB.
The Responder must accept any proposal which specifies a
rekeying time between 10min and 8hr inclusive and a rekeying
volume between 1MB and 1000MB inclusive.
It is highly desirable to add some random jitter to the
times of actual rekeying attempts, to break up ``convoys''
of rekeying events; this and certain other aspects of robust
rekeying practice will be the subject of a separate design
proposal.
Rationale: The numbers used here for rekeying intervals are
chosen quite arbitrarily and should be re-assessed after
some implementation experience is gathered.
3. Renewal and Teardown
3.1. Aging
When to tear tunnels down is a bit problematic, but if we're
setting up a potentially unbounded number of them, we have
to tear them down somehow sometime.
Set a short initial tentative lifespan, say 1min, since most
net flows in fact last only a few seconds. When that
expires, look to see if the tunnel is still in use (defini-
tion: has had traffic, in either direction, in the last half
of the tentative lifespan). If so, assign it a somewhat
longer tentative lifespan, say 20min, after which, look
again. If not, close it down. (This tentative lifespan is
independent of rekeying; it is just the time when the tun-
nel's future is next considered. This should happen reason-
ably frequently, unlike rekeying, which is costly and
shouldn't be too frequent.) Multi-step backoff algorithms
are not worth the trouble; looking every 20min doesn't seem
onerous.
If the security gateway and the client host are one and the
same, tunnel teardown decisions might wish to pay attention
to TCP connection status, as reported by the local TCP
layer. A still-open TCP connection is almost a guarantee
that more traffic is coming, while the demise of the only
Draft 4 3 May 2001 15
Opportunistic Encryption
TCP connection through a tunnel is a strong hint that none
is. If the SG and the client host are separate machines,
though, tracking TCP connection status requires packet
snooping, which is complicated and probably not worthwhile.
IKE keying channels likewise are torn down when it appears
the need has passed. They always linger longer than the
last tunnel they administer, in case they are needed again;
the cost of retaining them is low. Other than that, unless
the number of keying channels on the SG gets large, the SG
should simply retain all of them until rekeying time, since
rekeying is the only costly event. When about to rekey a
keying channel which has no current tunnels, note when the
last actual keying-channel traffic occurred, and close the
keying channel down if it wasn't in the last, say, 30min.
When rekeying a keying channel (or perhaps shortly before
rekeying is expected), Initiator and Responder should re-
fetch the public keys used for SG authentication, against
the possibility that they have changed or disappeared.
See section 2.7 for discussion of rekeying intervals.
Given the low user impact of tearing down and rebuilding a
connection (a tunnel or a keying channel), rekeying attempts
should not be too persistent: one can always just rebuild
when needed, so heroic efforts to preserve an existing con-
nection are unnecessary. Say, try every 10s for a minute
and every minute for 5min, and then give up and declare the
connection (and all other connections to that IKE peer)
dead.
Rationale: In future, more sophisticated, versions of this
protocol, examining the initial packet might permit a more
intelligent guess at the tunnel's useful life. HTTP connec-
tions in particular are notoriously bursty and repetitive.
Rationale: Note that rekeying a keying connection basically
consists of building a new keying connection from scratch,
using IKE Phase 1, and abandoning the old one.
3.2. Teardown and Cleanup
Teardown should always be coordinated with the other end.
This means interpreting and sending Delete notifications.
On receiving a Delete for the outbound SAs of a tunnel (or
some subset of them), tear down the inbound ones too, and
notify the other end with a Delete. Tunnels need to be con-
sidered as bidirectional entities, even though the low-level
protocols don't think of them that 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 no responding Delete is
Draft 4 3 May 2001 16
Opportunistic Encryption
received for the outbound SAs, try re-sending the original
Delete. Three tries spaced 10s apart seems a reasonable
level of effort. (Indefinite persistence is not necessary;
whether the other end isn't cooperating because it doesn't
feel like it, or because it is down/disconnected/etc., the
problem will eventually be cleared up by other means.)
After rekeying, transmission should switch to using the new
SAs (ISAKMP or IPsec) immediately, and the old leftover SAs
should be cleared out promptly (and Deletes sent) rather
than waiting for them to expire. This reduces clutter and
minimizes confusion.
Since there is only one keying channel per remote IP
address, the question of whether a Delete notification has
appeared on a ``suitable'' keying channel does not arise.
Rationale: The pairing of Delete notifications effectively
constitutes an acknowledged Delete, which is highly desir-
able.
3.3. Outages and Reboots
Tunnels sometimes go down because the other end crashes, or
disconnects, or has a network link break, and there is no
notice of this in the general case. (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 out-
ages is undesirable... but note that a tunnel can be torn
down and then re-established without any user-visible effect
except a pause in traffic, whereas if one end does reboot,
the other end can't get packets 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.
Heartbeat mechanisms are somewhat unsatisfactory for this.
Unless they are very frequent, which causes other problems,
they do not detect the problem promptly.
Ahem: What is really wanted is authenticated ICMP. This
might be a case where public-key encryption/authentication
of network packets is the right thing to do, despite the
expense.
In the absence of that, a two-part approach seems warranted.
First, when an SG receives an IPsec packet that is addressed
to it, and otherwise appears healthy, but specifies an
unknown SA and is from a host that the receiver currently
has no keying channel to, the receiver must attempt to
inform the sender via an IKE Initial-Contact notification
(necessarily sent in plaintext, since there is no suitable
Draft 4 3 May 2001 17
Opportunistic Encryption
keying channel). This must be severely rate-limited on both
ends; one notification per SG pair per minute seems ample.
Second, there is an obvious difficulty with this: the Ini-
tial-Contact notification is unauthenticated and cannot be
trusted. So it must be taken as a hint only: there must be
a way to confirm it.
What is needed here is something that's desirable for debug-
ging and testing anyway: an IKE-level ping mechanism. Ping-
ing direct at the IP level instead will not tell us about a
crash/reboot event. Sending pings through tunnels has vari-
ous complications (they should stop at the far mouth of the
tunnel instead of going on to a subnet; they should not
count against idle timers; etc.). What is needed is a con-
tinuity check on a keying channel. (This could also be used
as a heartbeat, should that seem useful.)
IKE Ping delivery need not be reliable, since the whole
point of a ping is simply to provoke an acknowledgement.
They should preferably be authenticated, but it is not clear
that this is absolutely necessary, although if they are not
they need encryption plus a timestamp or a nonce, to foil
replay mischief. How they are implemented is a secondary
issue, and a separate design proposal will be prepared.
Ahem: Some existing implementations are already using (pri-
vate) notify value 30000 (``LIKE_HELLO'') as ping and (pri-
vate) notify value 30002 (``SHUT_UP'') as ping reply.
If an IKE Ping gets no response, try some (say 8) IP pings,
spaced a few seconds apart, to check IP connectivity; if one
comes back, try another IKE Ping; if that gets no response,
the other end probably has rebooted, or otherwise been re-
initialized, and its tunnels and keying channel(s) should be
torn down.
In a similar vein, giving limited rekeying persistence, a
short network outage could take some tunnels down without
disrupting others. On receiving a packet for an unknown SA
from a host that a keying channel is currently open to, send
that host a Invalid-SPI notification for that SA. The other
host can then tear down the half-torn-down tunnel, and nego-
tiate a new tunnel for the traffic it presumably still wants
to send.
Finally, it would be helpful if SGs made some attempt to
deal intelligently with crashes and reboots. A deliberate
shutdown should include an attempt to notify all other SGs
currently connected by keying channels, using Deletes, that
communication is about to fail. (Again, these will be taken
as teardowns; attempts by the other SGs to negotiate new
tunnels as replacements should be ignored at this point.)
And when possible, SGs should attempt to preserve
Draft 4 3 May 2001 18
Opportunistic Encryption
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 previ-
ously-established connections.
4. Conclusions
This design appears to achieve the objective of setting up
encryption with strangers. The authentication aspects also
seem adequately addressed if the destination controls its
reverse-map DNS entries and the DNS data itself can be reli-
ably authenticated as having originated from the legitimate
administrators of that subnet/FQDN. The authentication sit-
uation is less satisfactory when DNS is less helpful, but it
is difficult to see what else could be done about it.
5. References
[TBW]
6. Appendix: Separate Design Proposals TBW
o How can we build a web of trust with DNSSEC? (See sec-
tion 2.3.4.)
o How can we extend DNS reverse lookups to permit reverse
lookup on a subnet? (Both address and mask must appear
in the name to be looked up.) (See section 2.6.)
o How can rekeying be done as robustly as possible? (At
least partly, this is just documenting current FreeS/WAN
practice.) (See section 2.7.)
o How should IKE Pings be implemented? (See section 3.3.)
Draft 4 3 May 2001 19
View Git Blame Copy Permalink