2013.10.24

[uclinux-h8/uClinux-dist.git] / freeswan / doc / opportunism.spec

                  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