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

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 20:44:50 +0100

Hi,

I dont think the document is ready for adoption.
First, the document conflates SeND modifications and a new crypto 
address modification, which i believe is not the right approach, in 
particular because it is hard to understand the benefits of the new 
address generation method.
In particular, crypto address cope is much larger than just SeND. By 
keeping the two things in the same document it is harder to understand 
what can be achieved with the addresses themselves and the protocols 
that use them. this is clear in the draft when it claims that CGAs are 
vulnerable to reply attacks. CGAs are not vulnerable. The protocols that 
use CGAs should take measures to deal with replay attacks.

Second, the document does not contain enough information to understnad 
the new address generation method. The draft claims that SSAS v2 provide 
similar or better security than CGAs with high SEC values, but it is not 
clear to me the SSASv2 generation process and verification.

Regards, marcelo

	

Begin forwarded message:

> From: Ole Troan <[email-masked]>
> Subject: 6MAN Adoption call on draft-rafiee-6man-ssas-07
> Date: 19 Nov 2013 11:01:07 GMT+1
> Resent-To: [email-masked], [email-masked],
> To: 6man WG <[email-masked]>
> Cc: 6man Chairs <[email-masked]>
> Message-Id: <[email-masked]>
>
> All,
>
> We reconsidered the action from Vancouver, and decided to have the discussion on this draft as part of the adoption call instead.
> Please provide a view with reasons as to whether the WG should adopt this or not.
>
> This message starts a one week 6MAN Working Group call on adopting:
>
> 	Title           : A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)
> 	Author(s)    : H. Rafiee, C. Meinel
> 	Filename    : draft-rafiee-6man-ssas-07
> 	Pages        : 15
> 	Date          : 2013-11-4
>
>    http://tools.ietf.org/html/draft-rafiee-6man-ssas-07
>
> The call ends on November 26th, 2013.
>
> Regards,
>
> Bob Hinden & Ole Trøan

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 21:13:21 +0100

Hi Marcelo,

Can I ask you which version of document you read? 
> First, the document conflates SeND modifications and a new crypto address
> modification, which i believe is not the right approach, in particular
because it
> is hard to understand the benefits of the new address generation method.
keeping
> the two things in the same document it is harder to understand what can be
> achieved with the addresses themselves and the protocols that use them.
this
> is clear in the draft when it claims that CGAs are vulnerable to reply
attacks.
> CGAs are not vulnerable. The protocols that use CGAs should take measures
> to deal with replay attacks.
> 
clear to
> me the SSASv2 generation process and verification.

CGA has a big security issue. Refer to my message. Its current security is
not more than 61 bits disregard of adding complexity.
Second, I guess you read the other version of draft since in this version we
don't have SSAS v1 and SSAS v2.

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 21:16:45 +0100

El 21/11/13 21:13, Hosnieh Rafiee escribió:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 21:21:00 +0100

> don't have SSAS v1 and SSAS v2.

from the security considerations of 
http://tools.ietf.org/html/draft-rafiee-6man-ssas-07

    Mathematically it has been shown that the probability of matching 48
    bits in the public key against 62 bits in the IID is about
    pow(1/2,62) where pow is the power function, 2 is a base and 64 is an
    exponent. in [2  <http://tools.ietf.org/html/draft-rafiee-6man-ssas-07#ref-2>] the analysis of SSAS is explained and compared to
    CGA. For CGA sec value 0, the attacker needs to do brute force
    attacks against 59 bits. So SSAS v1 is more secure than CGA sec value
    0. For SSAS v2, the attacker needs to do brute force attacks against
    the whole public key. So the security of that is depends on the
    security of public key algorithm and the key size.

So, how strong are SSAS?

If SSAS v2 no longer exists, the strength is 2^62?

Regards, marcelo

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 21:46:01 +0100

> >> particular
> >> the two things in the same document it is harder to understand what
> >> can be achieved with the addresses themselves and the protocols that
use
> them.
> >> CGAs are not vulnerable. The protocols that use CGAs should take
> >> measures to deal with replay attacks.
> >>
> >> Second, the document does not contain enough information to
> >> understnad the new address generation method. The draft claims that
> >> SSAS v2 provide similar or better security than CGAs with high SEC
> >> values, but it is not
> > clear to
> > CGA has a big security issue. Refer to my message. Its current
> > security is not more than 61 bits disregard of adding complexity.
> > Second, I guess you read the other version of draft since in this
> > version we don't have SSAS v1 and SSAS v2.
> 
>     exponent. in [2
<http://tools.ietf.org/html/draft-rafiee-6man-ssas-07#ref-
> 2>] the analysis of SSAS is explained and compared to

No,
For a few seconds (during the first DAD process 2*64 and then the whole
public key;.

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 21:56:55 +0100

>> If SSAS v2 no longer exists, the strength is 2^62?
you should probably update the security consideration of the draft, i guess

> For a few seconds (during the first DAD process 2*64 and then the whole

This is the fundamental problem with this draft, the SSAS and the update 
to SeND are tied together.
The strenght of the address is not related to how it is used with SeND 
(or NS)
what happens if you use SSAS to secure something else, like a mobility 
protocol?

Regards, marcelo

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Nov 2013 21:00:15 +0000

On 21 Nov 2013, at 20:56, marcelo bagnulo braun <[email-masked]> wrote:

> This is the fundamental problem with this draft, the SSAS and the update to SeND are tied together.
> The strenght of the address is not related to how it is used with SeND (or NS)
> what happens if you use SSAS to secure something else, like a mobility protocol?

Looks like another vote to split the draft in two…

Tim

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 22:04:44 +0100

> Looks like another vote to split the draft in two…

i think a document with both a new address generation and SeND 
modfications is not the way to go,
however, i certainly do not mean to say that if the document is split it 
is a good idea to adopt them anyway....

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 22:09:31 +0100

> > For a few seconds (during the first DAD process 2*64 and then the
> > whole public key;.
> 
to
> SeND are tied together.

Not necessarily. As I explained before, for routers you might need to use
RPKI model with SSAS or other approach if you know any but it does not
necessarily require to be an option of SeND as my first purpose was not. If
you read the draft, it has all its required options itself but if it wants
to come with SeND I need to add to the draft that what sections we do not
need in this combination. I agree with many people in this mailing list like
Tim, etc. that the text need revision and the sections needs to be better
organized so that it is better readable . 

> what happens if you use SSAS to secure something else, like a mobility

You can use it since it provide the prove of IP address ownership. Either
mobile IPv6, SIP, etc. There is no limitation on that  as some people also
did CGA and patented it for securing something else. If you googling on the
internet you can find many patented work based on CGA.

Smile, 
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 22:14:24 +0100

to
> > (or NS) what happens if you use SSAS to secure something else, like a
> mobility protocol?
> 

You still think that I have to split up the draft? The question is how? You
mean I have different use case scenario or... I probably need more
guidelines for splitting if it really needed.

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 22:16:12 +0100

> organized so that it is better readable .

so, if you use to secure mobile IPv6, and you stated the the protection 
depends on the DAD, but the CN does not receve the DAD as it is in a 
different network, right?

I mean, again, you are conflating the SeND and the address ownership proof.

Regards, marcelo

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 22:22:06 +0100

> > Not necessarily. As I explained before, for routers you might need to
> > use RPKI model with SSAS or other approach if you know any but it does
> > not necessarily require to be an option of SeND as my first purpose
> > was not. If you read the draft, it has all its required options itself
> > but if it wants to come with SeND I need to add to the draft that what
> > sections we do not need in this combination. I agree with many people
> > in this mailing list like Tim, etc. that the text need revision and
> > the sections needs to be better organized so that it is better readable
.
> I mean, again, you are conflating the SeND and the address ownership
proof.

NO no, DAD is not protection mechanism (if I get your question right). DAD
process is only used to check whether or not this address is unique in the
network if you are sure about the uniqueness of IP addresses or nobody else
use it (I don't know anybody recommend this) , then just start using it.
What is really important is that, if you are looking for using SSAS as an IP
address ownership, then you need to include the SSAS parameters in your
mobile IPv6 packets which is only the public key of the sender. That's it.
It will do the job and process the SSAS verification on other side.

Smile,
Hosnieh

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Nov 2013 16:37:41 -0500

Rather than decide whether or not to adopt this document now,
I think that the WG needs to decide:

1) Do we still care about SeND?  Is it something we want to figure
   out how to get deployed.

   Or does it deal with attacks which, at present, we simply do not
   see in IPv4?

   (can we agree that we don't have enough IPv6 deployment to judge if they
   occur in IPv6)

2) Are the IPR claims against CGA something that has been keeping
   CGA from being deployed as a SeND mechanism?

3) ten years later, are the legal/IPR and computational compromises
   that we made with CGA still valid?
   Are there privacy issues with using CGA?
   Do we want a better mechanism?

4) do we have consensus that the SeND/CGA is essentially completely undeployed?
   (I understand we might have as many as two interoperable implementations,
   but I'm pretty sure we have no deployed host implementations)
   If so, then we could agree that we are still in a greenfield situation.

====

My take on this, is that this is work that we SHOULD do as we are changing
and fixing the MUSTs and SHOULDs about eui-64 and privacy based addressing.
If we are asking host implementations to change some things there, let's get
them to level-up now.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Nov 2013 21:44:09 +0000

On 21 Nov 2013, at 21:04, marcelo bagnulo braun <[email-masked]> wrote:

> i think a document with both a new address generation and SeND modfications is not the way to go,
> however, i certainly do not mean to say that if the document is split it is a good idea to adopt them anyway....

Indeed, but it would be rather better to separate the two - currently - entangled purposes of the draft as it stands.

tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2013 11:57:56 +1300

On 22/11/2013 10:37, Michael Richardson wrote:
...
>    If so, then we could agree that we are still in a greenfield situation.

I am completely unable to form an opinion about the ssas draft, but
I think Michael raises an important point here. If SEND is *undeployable*
as well as undeployed, we need to get rid of it as a security figleaf,
and then perhaps we can have a useful discussion about how to prevent
address spoofing.

   Brian

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Fri, 22 Nov 2013 11:04:37 +0000

It is "undeployed", this is a fact.
The immediate cause, there is no host implementations, is another fact.
Why is debatable: ipr, weak security, lack of critical/real use cases to
solve, deployability, etc.
I am pretty sure we would deploy it, should we have hosts implementations.

It would be useful to hear why it's not on any of the most wide spread
IPv6 stacks. 
>From the interested parties. So that we can fix what need fixing, if it is
w problem we can fix.
Eric

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Nov 2013 09:20:29 -0500

Brian E Carpenter <[email-masked]> wrote:
    > On 22/11/2013 10:37, Michael Richardson wrote: ...
    >> 4) do we have consensus that the SeND/CGA is essentially completely
    >> undeployed?  (I understand we might have as many as two interoperable
    >> implementations, but I'm pretty sure we have no deployed host
    >> implementations) If so, then we could agree that we are still in a
    >> greenfield situation.

    > I am completely unable to form an opinion about the ssas draft, but I
    > think Michael raises an important point here. If SEND is *undeployable*

I do not make the claim that it is undeployable.

My point is that if it is undeployed, then we have no concern with being
backwards compatible with anything.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 23 Nov 2013 13:03:50 +0100

>     > I am completely unable to form an opinion about the ssas draft, but
I
> backwards compatible with anything.

I also do not think that we have problem with backward compatibility because
there is no (no-experimental) implementation for hosts. The second point is,
SSAS do not change SeND protocol but it can be behaved like a new option. 

Thanks,
Smile,
Hosnieh