Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?

Stephen Kent <> Wed, 21 July 2010 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E008F3A6A85; Tue, 20 Jul 2010 18:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qVtm0zbVpO4c; Tue, 20 Jul 2010 18:04:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E259C3A6A84; Tue, 20 Jul 2010 18:04:01 -0700 (PDT)
Received: from ([]:38710 helo=[]) by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1ObNjN-000IOT-Bz; Tue, 20 Jul 2010 21:04:17 -0400
Mime-Version: 1.0
Message-Id: <p06240805c86a38f57df9@[]>
In-Reply-To: <>
References: <>
Date: Tue, 20 Jul 2010 21:03:08 -0400
To: Sam Hartman <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: Margaret Wasserman <>, PaddyNallur <>,, Dong Zhang <>,
Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Jul 2010 01:04:03 -0000


Based on a quick reading, I am troubled by many aspects of this proposal.

CGAs were intended to afford privacy for IPv6 users, while allowing a 
first-hop router to verify the binding between the host asserting the 
address and the address in question.

The proposal to use CGAs in ACLs seems to negate the privacy feature, 
because it would (I assume) call for the CGAs to be static (for ease 
of ACL management).

The proposal says that "any host along the path" can engage in an 
exchange to cause the subject host to verify itself as the "owner" of 
the address. this is a very big deviation from the much more limited, 
local SeND context.

The proposal also calls for the sender to generate the signature on 
the payload of the packet, ala IPsec in Transport mode.  The document 
cites RFC 3971 (the SeND) spec, which calls for sig generation is a 
very different context, i.e., NDP packets in the SeND exchange.

This proposal includes an example (from the wireless context) 
suggesting that the sig is to be generated for every packet sent by a 
host, a requirement that would place a substantial burden on a host. 
IPsec rejected solutions of this sort for performance reasons.

Conversely, if only an initial packet exchange, involves the signed 
packet from the host, the secruity offered is much lower, making it 
vulnerable to MITM attacks.

Also note that SeND requires a trust anchor to be shared between the 
host and its local router. This is a reasonable assumption for that 
local context, but it less viable in a more general 
source/destination context that may extend outside a local space, as 
many of the offered examples do.