Subject: Re: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 6 Jan 2013 21:40:12 +0100

Dear Ahmad,

Thank you so much for your comments. 

>SEND already offers what you are looking for. It has the Timestamp and the
Signature options which are attached to the DNP messages.

As I explained in my last email to Jeremy, It just updates SEND and does not
replace it. It updates SEND because of the signature contents. I also
explained in the draft that we used the same timestamp as is used in SEND.

>I agree with the claim that CGA is compute intensive, but one can use Sec=0
or 1. In this case the computation of the CGA (SEND) would be equivalent to
the complexity of your approach.  
I compared it with both sec value 0 and sec value 1. I did not consider sec
value higher because it is not really feasible in practice that someone wait
for 2 or 3 hours to days to generate an address. CGA for 1 it is 600 times
more. For zero it is about 10 to 20 times more. 

The computation of this algorithm is faster than that for CGA and also the
verification process is much faster. In the verification process you do not
need to do all the CGA generation processing in reverse in order to verify
it. With CGA you also have to include the verification time for the
signature even though we say we use a sec value of 0 this is not considered
in the verification process. For CGA you also need to include an extra 17
bytes of options (modifier and collision count) in the packet, but with SSAS
the packet size would be less. 

Thank you,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Sunday, January 06, 2013 9:10 PM
To: [email-masked]
Subject: CGA-EXT Digest, Vol 47, Issue 2

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/cga-ext

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.

Send CGA-EXT mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/cga-ext
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of CGA-EXT digest..."

Today's Topics:

   1. Re:  Call for comments on draft-rafiee-6man-ssas-00.txt
      (Al-Sadeh, Ahmad)

----------------------------------------------------------------------

Message: 1
Date: Sun, 6 Jan 2013 21:09:53 +0100
From: "Al-Sadeh, Ahmad" <[email-masked]>
To: Hosnieh Rafiee <[email-masked]>, "[email-masked]"
	<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CGA-EXT] Call for comments on
	draft-rafiee-6man-ssas-00.txt
Message-ID: <BB4E1F8A-2971-4648-82E4-3A34DBE777A5@mimectl>
Content-Type: text/plain; charset="Windows-1252"

Hosnieh,
I have read your draft. And I have the following comments.
SEND already offers what you are looking for. It has the Timestamp and the
Signature options which are attached to the DNP messages. So, the new
benefits of your approach are not clear to me.
I agree with the claim that CGA is compute intensive, but one can use Sec=0
or 1. In this case the computation of the CGA (SEND) would be equivalent to
the complexity of your approach.  Therefore the enhancements that are
proposed to protect the user privacy by setting a lifetime for the generated
address (e.g. 2 days) or generating the key pairs by CGA code can be
directly applied to the CGA and SEND implementation without significant
change to proposed standard.
In Section 5, ?? it provides proof of address ownership at a speed that is
about 600 times faster than that of the CGA algorithm.?
For which Sec value this comparison was done?
Regards,
Ahmad AlSadeh

________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Hosnieh Rafiee [[email-masked]]
Sent: 04 January 2013 21:13
To: [email-masked]
Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt

Dear All,

This draft addresses the following problem:
Unfortunately the existing drafts do not consider the integration of
security and privacy  for the generation of the Interface ID (IID). This
draft tries to offer a solution to this problem while at the same time
considering the generation and verification times and complexity of the
existing algorithms. Please take a look. Comments are greatly appreciated.
Thank you,
Hosnieh

Filename:        draft-rafiee-6man-ssas
Revision:        00
Title:           A Simple Secure Addressing Generation Scheme for IPv6
AutoConfiguration (SSAS)
Creation date:   2013-01-02
WG ID:           Individual Submission
Number of pages: 13
URL:
http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas
Htmlized:        http://tools.ietf.org/html/draft-rafiee-6man-ssas-00

Abstract:
   The default method for IPv6 address generation uses two unique
   manufacturer IDs that are assigned by the IEEE Standards Association
   [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will
   always have the same Interface ID (IID) whenever it connects to a new
   network. Because the node's IP address does not change, the node is
   vulnerable to privacy related attacks. To address this issue, there
   are currently two mechanisms in use to randomize the IID,
   Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy
   Extension [RFC4941]. The problem with the former approach is the
   computational cost involved for the IID generation. The problem with
   the latter approach is that it lacks security. This document offers a
   new algorithm for use in the generation of the IID while, at the same
   time, securing the node against some types of attack, such as IP
   spoofing. These attacks are prevented with the addition of a
   signature to the Neighbor Discovery messages (NDP).

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

------------------------------

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

End of CGA-EXT Digest, Vol 47, Issue 2
**************************************

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 7 Jan 2013 09:40:53 +0000

Hosnieh,

I have some comments:
- Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment 
- You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing.
- You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every 2 days. This seams like a non-starter IMHO.
- Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ".

BTW, there other proposals for privacy extensions today that you should mention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02

Roque.

---

From: Hosnieh <[email-masked]>
Date: Mon, 7 Jan 2013 11:05:30 -0500 (EST)

Dear Rogue,

Thank you for your comments and questions.

> Why this is an important problem to be addressed is not clear in the text
> other than saying "CGA are computing intensive", which is arguable depending
> on network sizes and equipment

The problem is one of privacy. Addresses need to change in order to protect
privacy. In this vain it then becomes beneficial and important to be able to
generate the IID more quickly. For nodes in the network it is enough to use SSAS
without thinking about the use of certificates because that is all that is
needed to prove address ownership. At the same time, it is recommended to use
vehicles outlined in other RFCs to prevent all nodes from claiming to be a
router.

> You need to add text to the document on where the improvement resides. You
> mentioned something on the answer to Ahmad but that is still not convincing.

So being able to generate the address faster along with reducing the
verification time does not convince you? It is already a given that the use of
CGA for a sec value over 1 is not feasible. Even when using a sec value of 0 the
verification time using CGA is much higher than that for SSAS. The conclusion
drawn from this is that, in the event of DoS attacks, SSAS enable nodes have the
ability to process more packets per minute than do those using CGA.

> You mention that the strength of your algorithm requires that the key pair
> needs to be changed every 2 days. In the case you are using SEND, this means
> generating new certificates for every node every >2 days. This seems like a
> non-starter IMHO

As I explained in my answer to Ray in 6man WG, 2 days is just recommendation. If
one uses 20 days the probability is still low. Now let's explain the problem
from different aspects, i.e., internal network and external network.

Internal network:

We can provide privacy in layer 3. For privacy in layer 2, there is also a need
to have a dynamic MAC address (this is explained in another paper that is under
publication) from which we generate the address by using a kind of hashing
algorithm, like SHA256. This is especially feasible in cloud networks where
virtual machines are used. Using temporary keys and IP addresses would provide
privacy in layer 3.

 We also provide security for this network by preventing DAD and IP stealing
attacks.

One thing that is missing in my draft, which I will correct, is how to avoid
spoofed MAC address attacks. In this case, we also need to include the MAC
address in the signature so that, if the verification process fails, the message
is discarded by the node that should redirect this message.

External network:

Changing router prefixes (now done in some countries) and the IID would provide
the privacy needed for this node in layer 3. But for upper layers, there are a
lot of different approaches available: far too numerous to explain them here.

Another thing is that router nodes do not necessarily require the use of
 certification because, for a node in local network, it is important that they
be able to generate their IP address so that nobody can steal their address and
this is also true routers as well. Finally, the reason for recommending that key
pairs be generated with the generation of a new IP address is that this
eliminates the chance of a node being tracked based on its public key in layer 3
of internal networks and in external networks (eliminates the chance of privacy
attacks).

> Please include the reference to your studies instead of saying "Our
> experimental results show a definite improvement ".

Our research in this area is about to be published. I can upload the results of
our research to our website and refer you to that. (I will add the reference to
the draft after the it published and appears online)

Thank you,

Hosnieh

On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" <[email-masked]>
wrote:
> Hosnieh,
>
> I have some comments:
> - Why this is an important problem to be addressed is not clear in the text
> other than saying "CGA are computing intensive", which is arguable depending
> on network sizes and equipment
> - You need to add text to the document on where the improvement resides. You
> mentioned something on the answer to Ahmad but that is still not convincing.
> - You mention that the strength of your algorithm requires that the key pair
> needs to be changed every 2 days. In the case you are using SEND, this means
> generating new certificates for every node every 2 days. This seams like a
> non-starter IMHO.
> - Please include the reference to your studies instead of saying "Our
> experimental results show a definite improvement ".
>
> BTW, there other proposals for privacy extensions today that you should
> mention:
> https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02
>
> Roque.
>

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 7 Jan 2013 17:00:31 +0000

Hosnieh,

On Jan 7, 2013, at 5:05 PM, Hosnieh <[email-masked]<mailto:[email-masked]>> wrote:

Dear Rogue,

> Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment

The problem is one of privacy. Addresses need to change in order to protect privacy. In this vain it then becomes beneficial and important to be able to generate the IID more quickly. For nodes in the network it is enough to use SSAS without thinking about the use of certificates because that is all that is needed to prove address ownership. At the same time, it is recommended to use vehicles outlined in other RFCs to prevent all nodes from claiming to be a router.

So if the problem you want to solve is privacy, what is the big difference between your proposal and changing a CGA by using a different modifier from time to time? In your case you have a timestamp but the modifier can be arbitrary.

> You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing.

So being able to generate the address faster along with reducing the verification time does not convince you? It is already a given that the use of CGA for a sec value over 1 is not feasible. Even when using a sec value of 0 the verification time using CGA is much higher than that for SSAS. The conclusion drawn from this is that, in the event of DoS attacks, SSAS enable nodes have the ability to process more packets per minute than do those using CGA.

What do you mean by packet per minutes? ND packets? new neighbours? old neighbours that I already have in the cache? which L2 domain size? I think I would expect these sort of data to backup your comments.

> You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every >2 days. This seems like a non-starter IMHO

As I explained in my answer to Ray in 6man WG, 2 days is just recommendation. If one uses 20 days the probability is still low. Now let's explain the problem from different aspects, i.e., internal network and external network.

I am not following 6man. I will read your documents once you have publish all the data.

Roque

Internal network:

We can provide privacy in layer 3. For privacy in layer 2, there is also a need to have a dynamic MAC address (this is explained in another paper that is under publication) from which we generate the address by using a kind of hashing algorithm, like SHA256. This is especially feasible in cloud networks where virtual machines are used. Using temporary keys and IP addresses would provide privacy in layer 3.

 We also provide security for this network by preventing DAD and IP stealing attacks.

One thing that is missing in my draft, which I will correct, is how to avoid spoofed MAC address attacks. In this case, we also need to include the MAC address in the signature so that, if the verification process fails, the message is discarded by the node that should redirect this message.

External network:

Changing router prefixes (now done in some countries) and the IID would provide the privacy needed for this node in layer 3. But for upper layers, there are a lot of different approaches available: far too numerous to explain them here.

Another thing is that router nodes do not necessarily require the use of  certification because, for a node in local network, it is important that they be able to generate their IP address so that nobody can steal their address and this is also true routers as well. Finally, the reason for recommending that key pairs be generated with the generation of a new IP address is that this eliminates the chance of a node being tracked based on its public key in layer 3 of internal networks and in external networks (eliminates the chance of privacy attacks).

> Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ".

Our research in this area is about to be published. I can upload the results of our research to our website and refer you to that. (I will add the reference to the draft after the it published and appears online)

Thank you,

Hosnieh

On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" <[email-masked]<mailto:[email-masked]>> wrote:
> On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee <[email-masked]<mailto:[email-masked]>> wrote:
>
> > Dear Ahmad,
> >
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of [email-masked]<mailto:[email-masked]>
> > To: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> >
> > [email-masked]<mailto:[email-masked]>
> >
> > [email-masked]<mailto:[email-masked]>
> >
> > From: "Al-Sadeh, Ahmad" <[email-masked]<mailto:[email-masked]>>
> > To: Hosnieh Rafiee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
> > <[email-masked]<mailto:[email-masked]>>
> > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> > From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
> > Hosnieh Rafiee [[email-masked]<mailto:[email-masked]>]
> > To: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 14 Jan 2013 01:37:15 +0100

Dear Roque,

>So if the problem you want to solve is privacy, what is the big difference
between your proposal and changing a CGA by using a different modifier from
time to time? In >your case you have a timestamp but the modifier can be
arbitrary.

I also use a modifier. The difference between SSAS and CGA is the direct
usage of a public key as a part of the IP address. So, SSAS also generates a
random address and the chances of address collision is also minimized
because SSAS uses SHA2. If we want to use SHA2 for CGA, we would need to
forget about a sec value  higher than 0 because of the generation time is
dependent on the condition of 16 by sec value that must be equal to zero.

For the generation of CGA, the subnet prefix is required. This generation
must be in real time and cannot be in offline. For privacy, you usually need
to change your IP address regularly. Unfortunately, to generate a CGA, it
takes all the CPU power to accomplish this generation. This might have an
adverse effect on the other services trying to use that CPU. This is why an
algorithm needing less computing time is an advantage. 

>What do you mean by packet per minutes? ND packets? new neighbours? old
neighbours that I already have in the cache? which L2 domain size? I think I
would expect ?>these sort of data to backup your comments.

The number of NDP messages a node can verify per a certain period of time.
This verification is due to the addition of the addition of  that node's IP
address to the node's neighbor cache or just for to accomplish the DAD
process. As you know, one type of attack against CGA is related to DoS. This
means that the node is kept busy with false parameters. There is nothing in
the CGA RFC about how to protect a node against this type of attack. The new
RFCs, that extend CGA, also did not explain this. But in SSAS, we did we
explain how to protect nodes against this type of attack and in new version
of SSAS I enhanced the process to making the verification time even faster.
This should also be of help. 

Thank you,

Best Regards,

Hosnieh

 

From: Roque Gagliano (rogaglia) [mailto:[email-masked]] 
Sent: Monday, January 07, 2013 6:01 PM
To: Hosnieh
Cc: Roque Gagliano (rogaglia); <[email-masked]>
Subject: Re: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2

Hosnieh, 

On Jan 7, 2013, at 5:05 PM, Hosnieh <[email-masked]> wrote:

Dear Rogue,

The problem is one of privacy. Addresses need to change in order to protect
privacy. In this vain it then becomes beneficial and important to be able to
generate the IID more quickly. For nodes in the network it is enough to use
SSAS without thinking about the use of certificates because that is all that
is needed to prove address ownership. At the same time, it is recommended to
use vehicles outlined in other RFCs to prevent all nodes from claiming to be
a router.

So if the problem you want to solve is privacy, what is the big difference
between your proposal and changing a CGA by using a different modifier from
time to time? In your case you have a timestamp but the modifier can be
arbitrary.

So being able to generate the address faster along with reducing the
verification time does not convince you? It is already a given that the use
of CGA for a sec value over 1 is not feasible. Even when using a sec value
of 0 the verification time using CGA is much higher than that for SSAS. The
conclusion drawn from this is that, in the event of DoS attacks, SSAS enable
nodes have the ability to process more packets per minute than do those
using CGA.

What do you mean by packet per minutes? ND packets? new neighbours? old
neighbours that I already have in the cache? which L2 domain size? I think I
would expect these sort of data to backup your comments.

As I explained in my answer to Ray in 6man WG, 2 days is just
recommendation. If one uses 20 days the probability is still low. Now let's
explain the problem from different aspects, i.e., internal network and
external network.

I am not following 6man. I will read your documents once you have publish
all the data.

Roque

Internal network:

We can provide privacy in layer 3. For privacy in layer 2, there is also a
need to have a dynamic MAC address (this is explained in another paper that
is under publication) from which we generate the address by using a kind of
hashing algorithm, like SHA256. This is especially feasible in cloud
networks where virtual machines are used. Using temporary keys and IP
addresses would provide privacy in layer 3.

One thing that is missing in my draft, which I will correct, is how to avoid
spoofed MAC address attacks. In this case, we also need to include the MAC
address in the signature so that, if the verification process fails, the
message is discarded by the node that should redirect this message.

External network: 

Changing router prefixes (now done in some countries) and the IID would
provide the privacy needed for this node in layer 3. But for upper layers,
there are a lot of different approaches available: far too numerous to
explain them here.

Another thing is that router nodes do not necessarily require the use of
certification because, for a node in local network, it is important that
they be able to generate their IP address so that nobody can steal their
address and this is also true routers as well. Finally, the reason for
recommending that key pairs be generated with the generation of a new IP
address is that this eliminates the chance of a node being tracked based on
its public key in layer 3 of internal networks and in external networks
(eliminates the chance of privacy attacks).

Our research in this area is about to be published. I can upload the results
of our research to our website and refer you to that. (I will add the
reference to the draft after the it published and appears online)

Thank you,

Hosnieh

On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)"
<[email-masked]> wrote: 
> Hosnieh, 
> 
> I have some comments: 
> - Why this is an important problem to be addressed is not clear in the
text other than saying "CGA are computing intensive", which is arguable
depending on network sizes and equipment 
> - You need to add text to the document on where the improvement resides.
You mentioned something on the answer to Ahmad but that is still not
convincing. 
> - You mention that the strength of your algorithm requires that the key
pair needs to be changed every 2 days. In the case you are using SEND, this
means generating new certificates for every node every 2 days. This seams
like a non-starter IMHO. 
mention: