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

["Hosnieh Rafiee" <[e-mail]>]

Fernando,

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.
http://tools.ietf.org/html/draft-rafiee-6man-local-security-00#section-4.1 

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

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

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

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

Hosnieh