[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

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A911E81E2; Mon, 20 Jun 2011 12:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EfRfZag7sU-Q; Mon, 20 Jun 2011 12:14:15 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8F46711E80FC; Mon, 20 Jun 2011 12:14:15 -0700 (PDT)
Received: from mx03.mta.xmission.com ([]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1QYjvG-0005wx-Qk; Mon, 20 Jun 2011 13:14:11 -0600
Received: from 166-70-57-249.ip.xmission.com ([] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1QYjvE-0004yd-Uf; Mon, 20 Jun 2011 13:14:10 -0600
Received: from sylvester.rhmr.com (localhost []) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5KJDrkI018020; Mon, 20 Jun 2011 13:13:54 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id p5KJDpAW018018; Mon, 20 Jun 2011 13:13:51 -0600
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
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com)
Cc: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@ietf.org
Subject: [secdir] Security review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2011 19:14:21 -0000

Security review of
IPv6 Multihoming without Network Address Translation

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

>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

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.

7.2. Co-exisitence consideration