[secdir] Security review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00

"Hilarie Orman" <ho@alum.mit.edu> Mon, 20 June 2011 19:14 UTC

Date: Mon, 20 Jun 2011 13:13:51 -0600
Message-Id: <201106201913.p5KJDpAW018018@sylvester.rhmr.com>
From: Hilarie Orman <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org
Cc: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@ietf.org
Subject: [secdir] Security review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>

Security review of
IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

>From the abstract:
   In this document, we analyze the use cases of multihoming.  We also
   describe functional requirements for multihoming without the use of
   NAT in IPv6 for hosts and small IPv6 networks that would otherwise
   be unable to meet minimum IPv6 allocation criteria.

The underlying problem is that if a host has more than one one network
provider and has been assigned different IPv6 addresses for each
provider, then it becomes important to construct packets using the
right combination of {source address, destination address based on a
lookup to an appropriate DNS server, next-hop address}.  What is the
right combination, though?  The answer depends on the properties of
the different networks, and in general, hosts or gateway routers in
small networks may not have enough information to make a good choice.

The authors propose a solution based on policy information, to be
distributed by network administrators to network elements that are
multihomed.  The policy would list destination network prefixes
and the appropriate triples to use for each.

The security considerations are brief, simply noting that a policy
might be "evil" or the participants might ignore the policy.  I think
it is more complicated (of course).

There is a fundamental question of who should be trusted to distribute
policy.  How is the trust established, and how can the network element
be assured that it can established that trust before the network is
fully configured?  This might be quite difficult, because there could
be more than one policy distributor, each with a slightly different
view of the network (imagine P1 that can see external networks A
and B, and P2 that can see networks B and C).  It seems inevitable
that a host will have to be able to merge policies and deal with
updates.

Further, a host might have its own policies to merge into the mix.
For example, it might require a DNSSEC capable server for queries
about network A, but the policy might specify a non-DNSSEC server for
that network.  Thus, I can see a need for hosts to communicate their
security requirements to the policy server.

There are issues about the privacy of the policy itself.  Perhaps
particular network prefixes reveal business relationships that are
confidential.  Thus, some policy information might be sent on
encrypted channels.

What kind of policy enforcement is necessary?  If a host violates the
multihoming policy and sends a packet with a source address that is
appropriate to network A over the path to network B, should the packet
be blocked, redirected, or allowed?  What about DNS queries that are
sent to a server that is not recommended for the target?  Quash,
redirect, or allow?  What information should go back to the host?

I think that most of these comments apply to any policy server, and I
believe that various IETF documents in the past have attempted to
define generic security considerations for them.

Trivial editorial comments: 
"uRPF" is used three times without a definition.
"RA" is used before it is defined.

Typo:
7.2. Co-exisitence consideration

[secdir] Security review of draft-ietf-v6ops-ipv6… Hilarie Orman