Subject: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07

From: Ole Troan <[email-masked]>
Date: Wed, 15 Jan 2014 09:03:21 +0100

All,

Title:       A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)
Draft:      draft-rafiee-6man-ssas-07
Type:      Working group Adoption call
Last call: 2013-11-19 - 2013-11-26 (but in practice until now)

Number of messages on thread: 75
Support for adoption: No consensus

The chairs have after much deliberation and discussion with the AD,
decided that there is no consensus to adopt the draft.
This is based on the technical concerns raised during the adoption call,
and the deployment situation of SEND. Issues have been raised regarding
the proposed CGA algorithm that we don’t see clear answers to.
While we recognize that the problem of address spoofing and authentication
on IPv6 links is an important to solve, we do not see a consensus that the
proposed solution will significantly change the current SEND deployment situation.
We do not believe the working group understands why SEND is not deployed.
If that is because the users do not perceive the problem as important,
or if other solutions (e.g. on L2) are being deployed.   

Overall, we think these the technical and deployment issues need to be addressed
before the working group could adopt this document.

We would encourage the working group to continue work on address spoofing and authentication on IPv6 links.

Best regards,
Bob and Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Jan 2014 16:25:13 +0100

Le 15/01/2014 09:03, Ole Troan a écrit :
> All,
>
> Title:       A Simple Secure Addressing Scheme for IPv6
> AutoConfiguration (SSAS) Draft:      draft-rafiee-6man-ssas-07 Type:
> Working group Adoption call Last call: 2013-11-19 - 2013-11-26 (but
> in practice until now)
>
> Number of messages on thread: 75 Support for adoption: No consensus
>
> decided that there is no consensus to adopt the draft. This is based
> on the technical concerns raised during the adoption call, and the
> deployment situation of SEND. Issues have been raised regarding the
> proposed CGA algorithm that we don’t see clear answers to. While we
> recognize that the problem of address spoofing and authentication on
> IPv6 links is an important to solve, we do not see a consensus that
> the proposed solution will significantly change the current SEND
> deployment situation. We do not believe the working group
> understands why SEND is not deployed. If that is because the users do
> not perceive the problem as important, or if other solutions (e.g. on
> L2) are being deployed.

The lack of SeND deployment could be an issue.

There are some areas where IP security is needed with link scope, on
links which have little or no link-layer security.

One could also argue about the incompatibility of link1-layer security
with link2-layer security; or maybe the optimizations which could exist
if a wifi/bluetooth sensor node could carry a single set of keys instead
of 2.

To further dissect the question of SeND deployment one would need to
quantify it.  One would do so first by some simple means such as
checking the  availability of open-source implementations, and feature
presence in linux and other kernels.

Alex

>
> Overall, we think these the technical and deployment issues need to
> be addressed before the working group could adopt this document.
>
> We would encourage the working group to continue work on address
> spoofing and authentication on IPv6 links.
>
> Best regards, Bob and Ole
>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 16 Jan 2014 19:00:10 +0100

I do not accept the chair arguments since this draft have its own supporters
in the mailing list and I do not see this decision a fair decision . We all
know that we need local security and I also discussed about how this draft
can help to faster deploy SeND . I addressed all the comments I received
during the call and seriously cannot accept the result.

http://tools.ietf.org/html/draft-rafiee-6man-local-security 

-----------smile----------
Hosnieh
… success is a journey, not a destination….
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Wednesday, January 15, 2014 4:25 PM
> To: [email-masked]
> Subject: Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07
> 
> > Working group Adoption call Last call: 2013-11-19 - 2013-11-26 (but in
> > practice until now)
> >
> > deployment situation. We do not believe the working group understands
> > why SEND is not deployed. If that is because the users do not perceive
> > the problem as important, or if other solutions (e.g. on
> > L2) are being deployed.
> 
> There are some areas where IP security is needed with link scope, on links
> which have little or no link-layer security.
> 
with
> link2-layer security; or maybe the optimizations which could exist if a
> wifi/bluetooth sensor node could carry a single set of keys instead of 2.
> 
> quantify it.  One would do so first by some simple means such as checking
the
> availability of open-source implementations, and feature presence in linux
> and other kernels.
> 
> Alex
> 
> >
> > Overall, we think these the technical and deployment issues need to be
> > addressed before the working group could adopt this document.
> >
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Jan 2014 22:02:13 -0300

Hi, Ole,

[This is orthogonal to the consensus call from my pov, but felt like
dropping a note]

> We do not believe the working group understands why SEND is not

My two cents:

* Use of trust anchors makes deployment painful for the general case.

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

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

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

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 17 Jan 2014 06:52:31 +0100

Fernando,

> * Use of trust anchors makes deployment painful for the general case.

This is why I proposed a local centralized RPKI in the second draft.

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

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

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

Hosnieh

----------

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Jan 2014 07:14:10 -0300

Hosnieh,

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

> The reason is because of CGA

IIRC, there were *two* patents on SEND.

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

> spoofing. This is the main reason I wrote that local security draft to

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.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492