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

"Hosnieh Rafiee" <> Mon, 20 January 2014 18:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 915D31A0222 for <>; Mon, 20 Jan 2014 10:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.265
X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8OsdwNZxkFl2 for <>; Mon, 20 Jan 2014 10:21:20 -0800 (PST)
Received: from ( [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by (Postfix) with ESMTP id 00C851A01E5 for <>; Mon, 20 Jan 2014 10:21:19 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id C112E23E2D48; Mon, 20 Jan 2014 18:21:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 37dFsgdTnwQO; Mon, 20 Jan 2014 19:21:13 +0100 (CET)
Received: from kopoli ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 65D2923E2B25; Mon, 20 Jan 2014 19:21:12 +0100 (CET)
From: Hosnieh Rafiee <>
To: 'Fernando Gont' <>, 'Fernando Gont' <>, 'Ole Troan' <>, '6man WG' <>
Subject: RE: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07)
Date: Mon, 20 Jan 2014 19:21:11 +0100
Message-ID: <001501cf160c$66105a00$32310e00$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8WDGN4/fj2matnTPmt+IaYi/jFTw==
Content-Language: en-us
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: Mon, 20 Jan 2014 18:21:22 -0000


Just a quick review about SSAS to give you and those who didn't get the idea
of SSAS a short review.
If you review the SSAS draft, you will find out that you can either use it
as an option of SeND or use it alone. So, it doesn't necessarily need to
deploy with SeND but if one wants to use it as a SeND option, it is also
possible but in this case it doesn't need to carry the signature in SSAS
data structure. I explained this all in version 8 of this draft and
addressed all the issues. 

About why SeND is not deployed again, I refer you to the local security
draft that I wrote which is informational draft. You can find some of the
reasons that I gathered during the discussions with people. 

Some notes,

None of the existing approaches can prevent IP spoofing, with some of the
approaches you can mitigate fake RA spoofing but not host IP address

> Hosnieh,
> 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
> 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
> 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
> > DNS
> >> 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
> easier to deploy than send. So if you're willing to continue pursuing this
> 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
> deemed necessary.

You can actually find the reasons inside the drafts and all supportive
drafts. At least in version 8 I tried to clarify the reasons.

> >> * 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
> 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.

Why do you think that I established a non-WG group. I want really to solve
the problem of local security and  deploy it and also use it as a means of
authentication for other layers. I again refer you to that local security
draft. I really tried to discuss the problem and inform the possible