"IPv6 transition security" problem statement from a workshop that never happened

[Rob Austein <sra+v6ops@hactrn.net>]

As promised in Vienna, here's the draft problem statement that I wrote
for the IAB workshop on "IPv6 Transition Security" that never
happened.  I'm sending this to the WG in the hopes that it will be
useful.  If you think it's a waste of time, well, feel free to ignore
it, or print it out and throw darts at it, or whatever amuses you.

Credit for any of this that's useful goes to a long list of people,
including but not limited to the folks who chaired this WG or were on
the IAB or IESG when I was writing this text late last year.  If
something in this is wrong or offends you, blame me, not them.

See the minutes from IETF57 for background on the origin of this text.
In brief: late last year we started trying to pull together a workshop
on these topics, but it never quite jelled, in part because upon
examination some of these topics didn't seem particularly well suited
to the IAB workshop format.

$Id: problem-statement.txt,v 1.8 2003/07/23 20:12:12 sra Exp $

	    Proposed Workshop on IPv6 Transition Security

Now that we have started deploying IPv6 "for real", there are a number
of pesky little (or perhaps not so little) issues that we need to
examine.  Preliminary discussion has lumped these under the general
heading of "IPv6 transition security".  This note is an attempt to
state what we mean by this phrase.

Basic premise: transition is going to take a -long- time, on the order
of a decade, maybe longer.  During this decade or more of transition
we're going to be living in a dual protocol Internet, with parts of
the network running IPv4, parts running dual stack, parts either
running IPv6 only or wishing that they could, and parts that are
running only IPv6 wishing that they could still run IPv4 as well in
order to use old software or protocols that didn't make it through the
transition.  The transition solutions that we deploy will be part of
the operational network, will be attacked (like everything else) and
will have to operate and scale well (like everything else).

Most of the issues we're talking about here are not really problems
with IPv6 per se, and many of them are not even issues with specific
transition solutions.  Rather, a number of them fall into the general
category of possible unexpected interactions between the IPv4 and IPv6
worlds, or between the transition solutions we've developed and other
seemingly unrelated parts of the network or of the protocol suite.

Some general issues:

- A number of proposed transition mechanism use some form of IP-in-IP
  tunneling.  Tunneling makes the network topology more complex, which
  can have serious implications for topologically-based security
  mechanisms (including, but not limited to, the specific kind of
  packet filtering known as "ingress filtering").   Tunneling issues
  go way beyond the IPv6 transition scope per se (we have examples of
  these same problems in the IPv4-only world), but tunneling as used
  in IPv6 transition schemes require special attention for two
  reasons:

  a) These transition solutions propose heavy operational reliance on
     tunneling for the next decade; and

  b) In the general Internet it's quite common not to know the party
     or service with which one wishes to connect.  So in the IPv6
     transition cases, tunneling is much more likely to occur between
     parties who are total strangers and thus have no pre-established
     trust relationship than is usually the case in IPv4 tunneling
     (ignoring the MBONE, which arguably is a special case).  Thus, a
     number of trust relationship issues arise that we need to examine
     very carefully.

  None of the above is intended to pass judgment on whether tunneling
  mechanisms are good or bad.  The point here is just that we don't
  understand all of the risks in detail yet (and have not had our
  noses rubbed in them to the same extent that we have with the
  alternative class of translation-based transition mechanisms).

- A number of transition mechanisms define ways of constructing IPv6
  addresses using IPv4 addresses.  There are a number of kinds of IPv4
  addresses that require careful treatment due to known security
  issues.  This implies that these transition mechanisms in effect mean
  that we have to think about all the possible issues arising from the
  cross product of

    { every known perverse form of IPv4 address }

                       X

    { every form of IPv6 address that's built using IPv4 addresses }

  For example: what bad things might an IPv6 node do with a packet
  containing an address such as 2002:0a03:002c::7f00:0002?

  Note that this is an -addressing- issue, so even a pure IPv6-only
  implementation has to worry about all these whacky addresses.

  Another sub-issue here is interactions between different mechanisms
  that use the same whacky address in different whacky ways.  For
  example, see the issues that Itojun raised regarding mapped
  addresses meaning one thing on the wire and another thing altogether
  in the sockets API.  In effect these interactions can turn into
  another kind of topological defense issue.

- There are some obvious interactions between some kinds of transition
  mechanisms (for example, translation-based mechanisms) and various
  cryptographic security mechanisms (IPsec, DNSSEC, ...).   There may
  be other interactions that are not so obvious, and some of the
  obvious interactions may include questionable assumptions (see, for
  example, the debate about whether the interaction between DNSSEC and
  NAT-PT matters for cases in which NAT-PT is being used to support
  hosts that arguably are never going to use DNSSEC anyway).

- We have stated repeatedly that IPsec is a basic mandatory to
  implement service in IPv6, and there are some transition tools that
  might benefit from suitable application of the IPsec protocols.
  There is, however, still some question about how deployable IPsec is
  due to key management issues.  Transition related applications of
  the IPsec protocols may escalate the priority of examining these
  operational issues to see what, if anything, we can do about them.

- Moving to a mixed IPv4/IPv6 world increases the number of possible
  interactions between protocols and the security mechanisms that we
  have designed to protect them.  This is not the fault of IPv6 (or of
  IPv4 for that matter), it is an unavoidable complexity problem that
  we need to examine, particularly given that, of the two major
  families of transition mechanisms that we have, one uses translation
  (which is known to be hostile to many security mechanisms) and the
  other uses tunneling (which may produce topologies that violate
  assumptions that application protocol designers or implementors have
  chosen to make).

- The intense focus on DNS issues in thinking about IPv6 transition
  issues in the last year or so is arguably grounds for concern,
  because DNS is in most respects not that different from most of the
  other protocols that build on top of the basic network and transport
  layers.  The concern here is that many of the DNS-related issues may
  just be the nose of the camel, and that we're focused on DNS just
  because it's usually the first of these protocols that any
  application has to deal with.  So in addition to solving whatever
  DNS problems may exist, we also need to ask ourselves the question
  "assuming that all the DNS issues were solved, what breaks next?"

- Some transition tools attempt to piggyback tasks that arguably ought
  to be done on the IPv6 network onto existing IPv4 mechanisms.  This
  is most obvious in the area of routing, where some transition
  solutions use IPv4 anycast (ie, the IPv4 routing infrastructure) to
  build what is in effect a single gigantic virtual link layer network
  over which IPv6 can run.  Unsurprisingly, such gigantic link layer
  networks have some of the same problems that have haunted other
  large link layer networks (for example, the difficulty of applying
  ingress control and other forms of fault isolation).  The "obvious"
  solution is to break up the gigantic link layer networks using
  routers at the IPv6 layer, but doing so may create other problems
  that defeat the purpose of the transition mechanism.  We need to
  examine such cases carefully and determine the best (or least bad)
  ways of dealing with these issues.

- Some transition tools produce overlay network topologies in which
  the control plane is not congruent with the data plane.  While
  separation of the control and data planes can be useful in certain
  environments, in general such separation is robust only when the
  separated control and data planes are congruent and coordinated to
  work towards a shared goal.  The overlay networks produced by some
  transition tools do not satisfy this prerequisite condition, and the
  lack of coordination between control and data planes can result in
  the different layers working at odds with each other.  For example,
  updating an IPv6 routing table to avoid a known link fault may not
  have the desired effect when the IPv6 network is overlaid on top of
  an IPv4 network that is making its own routing decisions, or when
  the overlay mechanism forces the IPv4 network to send all traffic
  through a particular intermediary device in the middle of the
  network.

So it would be good to understand what kinds of weaknesses
our transition solutions have:

- Individually: for example, for each of the long list of mechanisms
  that have come out of the NGTRANS WG over the years and mostly been
  ignored by the rest of the IETF, let alone the rest of the world:
  have we looked hard enough at the security considerations[*], and
  under what circumstances is this protocol safe to use?

- In groups: for example, are there generic issues that apply to all
  tunneling protocols, and generic recommendations we can make about
  how to use tunneling protocols safely?
 
- In various forms of interplay with the IPv4 network: for example,
  how serious is the threat of using one or more of the transition
  schemes that defines "relay routers" as a launching point for IPv4
  DDoS attacks, and will the threat of such attacks provoke responses
  that render these transition schemes unusable?

So the soundbite goal is that we want to avoid the attacks that are
avoidable and defend against the attacks that are unavoidable, for
however long the transition takes.

[*] Please note that folks in the IPv6 WGs are trying very hard to get
    the security considerations sections in their drafts right, for
    which they deserve our thanks.  But this stuff is complex and is
    still being ignored by way too much of the IETF, let alone the
    rest of the world, so they need our help.