+++ /dev/null
-.DA "3 May 2001"
-.ds LH "
-.ds CH "Opportunistic Encryption
-.ds RH "
-.ds LF "Draft 4+
-.ds CF "\\*(DY
-.ds RF %
-.de P
-.LP
-..
-.de R
-.LP
-\fBRationale:\fR
-..
-.de A
-.LP
-\fBAhem:\fR
-..
-.TL
-Opportunistic Encryption
-.AU
-Henry Spencer
-D. Hugh Redelmeier
-.AI
-henry@spsystems.net
-hugh@mimosa.com
-Linux FreeS/WAN Project
-.AB no
-xxx cases where reverses not controlled, all possibilities.
-xxx DHR suggests okay if gateway doesn't control reverse but destination does.
-xxx level of patience where Responder just doesn't answer the phone.
-xxx IKE finger to get basic keying info, to be confirmed via DNSSEC?
-xxx packets from some OE connections might get special status,
-if the other end is definitely someone we trust.
-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.
-.sp
-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 ``Implementing Opportunistic
-Encryption'' document.
-.AE
-.NH 1
-Introduction
-.P
-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 negotiate an IPsec tunnel to that
-host's security gateway.
-If the attempt succeeds, traffic can then be secure,
-transparently (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.
-.P
-This generalizes trivially to the end-to-end case:
-host and security gateway simply are one and the same.
-Some optimizations are possible in that case,
-but the basic scheme need not change.
-.P
-The objectives for security systems need to be explicitly stated.
-Opportunistic encryption is meant to achieve secure communication,
-without prearrangement of the individual connection
-(although some prearrangement on a per-host basis is required),
-between any two hosts which implement the protocol
-(and, if they act as security gateways,
-between hosts behind them).
-Here ``secure'' means strong encryption and authentication of packets,
-with authentication of participants\(emto prevent man-in-the-middle
-and impersonation attacks\(emdependent on several factors.
-The biggest factor is the authentication of DNS records,
-via DNSSEC or equivalent 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 Qualified 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.
-.P
-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 implementations are
-guaranteed to reach agreement,
-without any explicit prearrangement or preliminary negotiation.
-The first two problems are solved using DNS,
-with DNSSEC ensuring that the data obtained is reliable;
-the third is solved by specifying a minimum standard which must be supported.
-.P
-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.
-.P
-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.
-.P
-A note on document structure:
-Discussions of \fIwhy\fR 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 the ends of sections).
-Paragraphs headed ``Ahem:'' are discussions of where the problem is being
-made significantly harder by problems elsewhere,
-and how that might be corrected.
-Some meta-comments are enclosed in [].
-.R
-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 outdated.
-.R
-Speed is of the essence in tunnel setup:
-a connection-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 fetching.
-.A
-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 destination address to obtain a
-public key for that address,
-and simply encrypt all packets going to it with that key,
-signing them with your own private key.
-Alas, this is impractical with current CPU speeds and current algorithms
-(although as noted later, it might be of some use for limited purposes).
-Nevertheless, it is a useful model.
-.NH 1
-Connection Setup
-.P
-For purposes of discussion, the network is taken to look like this:
-.DS
-Source----Initiator----...----Responder----Destination
-.DE
-The intercepted packet comes from the Source,
-bound for the Destination,
-and is intercepted at the Initiator.
-The Initiator 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 Initiator a
-security gateway (SG).
-Likewise for the Responder and the Destination.
-.P
-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).
-.P
-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 \fIno\fR tunnel can be established must also be made rapidly.
-.NH 2
-Packet Interception
-.P
-Interception of outgoing packets is relatively straightforward
-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 \fImost recent\fR
-packet for an as-yet-unresolved address,
-and throwing away older ones.
-(Incrementing of request numbers etc. means that replies to older ones may no
-longer be accepted.)
-.P
-Is it worth intercepting \fIincoming\fR packets, from the outside world, and
-attempting tunnel setup based on them?
-No, unless and until a way can be devised to initiate opportunistic 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.
-.R
-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.
-.R
-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 consuming resources and delaying
-traffic in an attempt at opportunistic 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.
-.NH 2
-Algorithm
-.P
-For clarity,
-the following defers most discussion of error handling to the end.
-.nr x \w'Step 3A.'u+1n
-.de S
-.IP "Step \\$1." \nxu
-..
-.S 1
-Initiator does a DNS reverse lookup on the Destination 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.)
-.S 2A
-If at least one suitable TXT record (see section 2.3) comes back,
-each contains a potential 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.
-.S 2B
-If no suitable TXT record is available,
-and policy permits,
-Initiator designates the Destination itself as the Responder
-(see section 2.4).
-If policy does not permit,
-or the Destination is unresponsive to the negotiation,
-then opportunistic encryption is not possible,
-and Initiator gives up (see section 2.5).
-.S 3
-If there already is a keying channel to the Responder'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 dictates whether
-the keying channel and the outside of the tunnel should be IPv4 or IPv6.
-.S 4
-Responder gets the first IKE message,
-and responds.
-It also starts a DNS reverse lookup on the Initiator's IP address,
-for KEY records, on speculation.
-.S 5
-Initiator gets Responder's reply,
-and sends first message of IKE's D-H exchange (see 2.4).
-.S 6
-Responder gets Initiator's D-H message,
-and responds with a matching one.
-.S 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\(eme.g., the DNS data for it need not
-include an A record.)
-.S 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 forward lookup on the FQDN, for a KEY record;
-waits for that lookup to return;
-it should yield a suitable KEY record.
-Either way, Responder uses the KEY data to verify the message's hash.
-Responder replies with an authentication message,
-with an FQDN identity if a reverse lookup on its address will not yield a
-suitable KEY record.
-.S 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.
-.S 9B
-(If step 2B was used.)
-The Initiator gets the Responder's authentication message,
-which must contain 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 suitable KEY record, verify hash.
-Encrypted keying channel established,
-man-in-middle attack precluded,
-but authentication weak (see 2.4).
-.S 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 determines whether the inside
-of the tunnel should be IPv4 or IPv6.
-.S 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 contain either the Initiator's IP address
-or an FQDN identity identical to that supplied by the Initiator 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 tunnel.
-.S 12
-Initiator gets second Phase 2 message,
-establishes tunnel (if he didn't already),
-and releases the intercepted packet into it, finally.
-.S 13
-Communication proceeds.
-See section 3 for what happens later.
-.P
-As additional information becomes available,
-notably in steps 1, 2, 4, 8, 9, 11, and 12,
-there is always a possibility that local policy
-(e.g., access limitations) might prevent further progress.
-Whenever possible,
-at least attempt to inform the other end of this.
-.P
-At any time, there is a possibility of the negotiation failing 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 Initiator 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.
-.P
-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.
-(Passing 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!)
-.P
-The flip side of waiting for a timeout is that all other forms of
-feedback, e.g. ``host not reachable'',
-arguably should be \fIignored\fR,
-because in the absence of authenticated ICMP,
-you cannot trust them!
-.R
-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 destination 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 multiple 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 network model badly,
-making problems difficult to diagnose and impossible to work around
-(and there is already bad experience with this, in areas like web caching).
-.R
-(Step 1.)
-Dynamic setup actions might include establishment of demand-dialed links.
-These might be present anywhere along the path,
-so one cannot rely on out-of-band communication at the Initiator to
-trigger them.
-Hence the ping.
-.R
-(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 distant 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.
-.A
-Support for a small subset of this admittedly-obscure feature
-would be useful.
-Unfortunately, it seems unlikely.
-.R
-(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.
-.R
-(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.
-.R
-(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 identity (as an FQDN) and
-proof of its right to use that identity.
-This is somewhat better than nothing,
-and may be quite useful if the SG is representing a client host
-which \fIcan\fR prove its right to \fIits\fR IP address.
-(For example, a fixed-address subnet might live behind an SG with
-a dynamically-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 \fIboth\fR ends.
-.R
-(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 encryption is intended as a general-purpose
-connection mechanism between strangers,
-it may well be convenient for prearranged connections to use
-the same mechanism.
-.R
-(Steps 7 and 8.)
-FQDNs as identities are avoided where possible,
-since they can involve synchronous DNS lookups.
-.R
-(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 represent 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.
-.R
-While it might seem unlikely that a refusal to cooperate from one SG
-could be remedied by trying another\(empresumably they all use the
-same policies\(emit'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.
-.NH 2
-DNS Records
-.P
-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.
-.NH 3
-TXT
-.P
-Opportunistic-encryption SG discovery uses TXT records with the content:
-.DS
-X-IPsec-Gateway(\fInnn\fR)=\fIiii\fR\ \fIkkk\fR
-.DE
-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.)
-.P
-The \fInnn\fR 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.
-xxx rollover.
-The preference field is not optional;
-use ``0'' if there is no meaningful preference ordering.
-.P
-The \fIiii\fR 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 \fIiii\fR is of the form ``@fqdn'',
-where \fIfqdn\fR is the FQDN that the SG will use to
-identify itself (in step 7 of section 2.2);
-such a record cannot be used for SG discovery by an Initiator,
-but can be used for
-SG verification (step 11 of 2.2) by a Responder.
-.P
-The \fIkkk\fR 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 specifies that the public key can be found in a KEY
-record located based on the SG's identification:
-if \fIiii\fR is an IP address,
-do a reverse lookup on that address,
-else do a forward lookup on the FQDN.
-.R
-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 reason why it can't.
-The TXT record is a temporary stand-in
-for (we hope, someday) a new DNS record for SG identification 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.
-.R
-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 experimental;
-this design will probably need modification after initial experiments.
-The format is chosen with an eye on eventual binary encoding.
-Note, in particular,
-that the TXT record normally contains the \fIaddress\fR 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\(emthis is conceptually
-a \fIbinary\fR record, temporarily using a text encoding.
-The ``@fqdn'' form of the SG identity is
-for specialized uses and is never mapped to an address.
-.A
-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 \fIand\fR not the final string of the
-record should have a blank appended to it,
-and the strings of the record
-should then be concatenated.
-(This observation is based on how BIND 8 transforms a TXT record
-from text to DNS binary.)
-.NH 3
-KEY
-.P
-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 \fIflags\fR, \fIprotocol\fR, or \fIalgorithm\fR
-values are ignored.
-.R
-Unfortunately, the public key has to be
-associated 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.
-.A
-Per-client keys would reduce vulnerability to key compromise,
-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.
-.NH 3
-Summary
-.P
-For reference, the minimum set of DNS records needed to make this
-all work is either:
-.IP 1. \w'1.'u+2n
-TXT in Destination reverse map, identifying Responder and providing public key.
-.IP 2.
-KEY in Initiator reverse map, providing public key.
-.IP 3.
-TXT in Source reverse map, verifying relationship to Initiator.
-.P
-or:
-.IP 1. \w'1.'u+2n
-TXT in Destination reverse map, identifying Responder.
-.IP 2.
-KEY in Responder reverse map, providing public key.
-.IP 3.
-KEY in Initiator reverse map, providing public key.
-.IP 4.
-TXT in Source reverse map, verifying relationship to Initiator.
-.P
-Slight complications ensue for dynamic addresses,
-lack of control over reverse maps, etc.
-.NH 3
-Implementation
-.P
-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.
-.P
-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.
-(Obviously there needs to be a way to manually flush the remembered results
-for a specific host, to permit deliberate changes.)
-.NH 2
-Responders Without Credentials
-.P
-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.
-.P
-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 opportunistic
-encryption is entirely impossible,
-but the case seems common enough to justify the overhead.
-.P
-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.
-.NH 2
-Failure of Opportunism
-.P
-When there is no way to do opportunistic encryption, a policy 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 \fIboth\fR a block and a bypass would be set up if
-opportunistic encryption failed.
-.P
-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.
-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 unauthenticated error
-reports like ``port unreachable'' are borderline,
-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 participate in opportunistic encryption.)
-.P
-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 available 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.
-.P
-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.
-.NH 2
-Subnet Opportunism
-.P
-In principle, when the Source or Destination host belongs to a subnet
-and the corresponding SG is willing to provide tunnels 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,
-opportunistic tunnels can only have degenerate subnets (single hosts)
-at their ends.
-(This does, at least, set up the keying channel,
-so that negotiations for tunnels to other hosts in the same subnets
-will be considerably faster.)
-.P
-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.
-.A
-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 delegation.
-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.
-.P
-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 Destination
-(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 subnet(s) are present on its end.
-.NH 2
-Option Settings
-.P
-IPsec and IKE have far too many useless options, and a few useful ones.
-IKE negotiation is quite simplistic, and cannot 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 interoperability without prearrangement or
-other negotiation protocols.
-.R
-The prohibition of other negotiations is simply because there is no time.
-The setup algorithm (section 2.2) is lengthy already.
-.P
-[Open question:
-should opportunistic IKE use a different port than normal IKE?]
-.P
-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.
-.R
-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.
-.P
-Keying channels must remain in existence at least as long as any
-tunnel created with them remains (they are not costly, 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 rekeying time between 1hr and 24hr inclusive
-and a rekeying volume between 100KB and 10MB inclusive.
-.P
-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 otherwise,
-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.
-.P
-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.
-.R
-The numbers used here for rekeying intervals are chosen quite arbitrarily
-and should be re-assessed after some implementation experience is gathered.
-.NH 1
-Renewal and Teardown
-.NH 2
-Aging
-.P
-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 \fIsomehow sometime\fR.
-.P
-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 (definition:
-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 tunnel's future
-is next considered.
-This should happen reasonably 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.
-.P
-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 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.
-.P
-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.
-.P
-See section 2.7 for discussion of rekeying intervals.
-.P
-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 connection 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.
-.R
-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 connections in particular are
-notoriously bursty and repetitive.
-.R
-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.
-.NH 2
-Teardown and Cleanup
-.P
-Teardown should always be coordinated with the other end.
-This means interpreting and sending Delete notifications.
-.P
-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 considered as bidirectional entities,
-even though the low-level protocols don't think of them that way.
-.P
-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 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.)
-.P
-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.
-.P
-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.
-.R
-The pairing of Delete notifications effectively constitutes an
-acknowledged Delete, which is highly desirable.
-.NH 2
-Outages and Reboots
-.P
-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 outages 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 \fIat all\fR (except via IKE)
-until the situation is noticed.
-So a bias toward quick response is appropriate,
-even at the cost of occasional false alarms.
-.P
-Heartbeat mechanisms are somewhat unsatisfactory for this.
-Unless they are very frequent, which causes other problems,
-they do not detect the problem promptly.
-.A
-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.
-.P
-In the absence of that, a two-part approach seems warranted.
-.P
-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 keying channel).
-This must be severely rate-limited on \fIboth\fR ends;
-one notification per SG pair per minute seems ample.
-.P
-Second, there is an obvious difficulty with this:
-the Initial-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.
-.P
-What is needed here is something that's desirable for
-debugging and testing anyway:
-an IKE-level ping mechanism.
-Pinging direct at the IP level instead will not tell us about a
-crash/reboot event.
-Sending pings through tunnels has
-various 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 continuity check on a keying channel.
-(This could also be used as a heartbeat,
-should that seem useful.)
-.P
-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.
-.A
-Some existing implementations are already using
-(private) notify value 30000 (``LIKE_HELLO'') as ping
-and (private) notify value 30002 (``SHUT_UP'') as ping reply.
-.P
-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.
-.P
-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.
-xxx that's not what Invalid-SPI is for.
-The other host can then tear down the half-torn-down tunnel,
-and negotiate a new tunnel for the traffic
-it presumably still wants to send.
-.P
-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 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.
-.NH 1
-Conclusions
-.P
-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 reliably authenticated
-as having originated from the legitimate administrators of that
-subnet/FQDN.
-The authentication situation is less satisfactory when DNS is less helpful,
-but it is difficult to see what else could be done about it.
-.NH 1
-References
-.P
-[TBW]
-.NH 1
-Appendix: Separate Design Proposals TBW
-.IP \(bu \w'\(bu'u+2n
-How can we build a web of trust with DNSSEC?
-(See section 2.3.4.)
-.IP \(bu
-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.)
-.IP \(bu
-How can rekeying be done as robustly as possible?
-(At least partly, this is just documenting current FreeS/WAN practice.)
-(See section 2.7.)
-.IP \(bu
-How should IKE Pings be implemented?
-(See section 3.3.)
projects / thirdparty / strongswan.git / blobdiff