Re: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07)

Fernando Gont <> Fri, 17 January 2014 13:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E08BC1AE0C4 for <>; Fri, 17 Jan 2014 05:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ni0QsnRs-kGD for <>; Fri, 17 Jan 2014 05:48:15 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id D1EC51AE0BD for <>; Fri, 17 Jan 2014 05:48:14 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1W49m8-0003WE-23; Fri, 17 Jan 2014 14:47:56 +0100
Message-ID: <>
Date: Fri, 17 Jan 2014 07:14:10 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Hosnieh Rafiee <>, 'Fernando Gont' <>, 'Ole Troan' <>, '6man WG' <>
Subject: Re: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07)
References: <> <> <001201cf1348$50032470$f0096d50$>
In-Reply-To: <001201cf1348$50032470$f0096d50$>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: '6man Chairs' <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jan 2014 13:48:17 -0000


On 01/17/2014 02:52 AM, Hosnieh Rafiee wrote:
>> My two cents:
>> * Use of trust anchors makes deployment painful for the general case.
> This is why I proposed a local centralized RPKI in the second draft.

What do you mean by "local centralized"? Whether the PKI is local or
global doesn't seem to affect how hard this is to deploy.

>> * Most popular OSes do not have a real SEND implementation (not long ago
>> the only way to play on BSDs was a Java implementation?). When it comes to
>> open source ones, the fact that SEND is IPR'ed doesn't help the situation.
> The reason is because of CGA

IIRC, there were *two* patents on SEND.

>> * While other parts of the "system" are largely unsecured, SeND probably
>> does not much. (e.g, if a local attacker can spoof a DNS response,
> securing the
>> layer-2/3 mapping will not buy much in most cases -- i.e., just spoof the
>> response, and you're done).
> I considered DNS spoofing to address that problem by proposing CGA-TSIG (it
> use both SSAS/CGA as its solution) and it is implemented.

I didn't go through your I-D in detail, hence I cannot comment one way
or another.

Based on the discussions it seems folks are not convinced why this would
be easier to deploy than send. So if you're willing to continue pursuing
this effort, you could try to spell out the reasons for which SEND has
not been widely deployed, and provide a clear explanation on why your
proposal would make a difference. -- Feel free to start from the reasons
I provided, or tweak as deemed necessary.

>> * SEND wasn't there for v4. And there's a tendency to try to employ
>> IPv6 as IPv4, focusing on the benefit of the larger address space (i.e.,
> for
>> some, "I lived with this in v4 for 20+ years, so..."). Not that I
> necessarily
>> endorse this view, but just meant to spell it out.
> Current available mechanism also have problem and cannot mitigate IP
> spoofing. This is the main reason I wrote that local security draft to
> address these problems.

Agreed. But we're analyzing why SEND has not been widely deployed. If
folks out there do not consider this is to be a problem that is worth
addressing, no matter what solution we propose, it will still be a
"problem not worth addressing" from their point of view.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492