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

From: Hosnieh <[email-masked]>
Date: Mon, 2 Dec 2013 07:46:33 -0500 (EST)

Hello,

I have uploaded a new version of SSAS on my own server since I want to avoid
uploading a new version for a short time on server and also revise two other
documents at the same time that is associated with this document. So, please
take a look and if you have any comments please let me know so that I can apply
them before I upload this version on IETF server.
The changes on this version
- I tried to apply Dan's, Tim's comments
- I clarified the text and removed the typos I found in the text
- I removed many unrelated sections that was there due to the fact that I wrote
the last version so quickly!!
- I clarified the purpose and scenarioes on which SSAS can be used.

Here you go:
http://rozanak.com/ssas.txt

Thanks,
smile,
Hosnieh
Sorry for tpyos from my chubby fingers typing on my phone

---

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Dec 2013 19:47:31 +0000

Dear all,
I support the adoption of this document as a 6man wg item, since this is
an interesting technology to have in our toolbox. However, I should note
that it will need substantive work before it can be published as an RFC.
Below you will find some comments that will help improve this document.

Meta:

Throughout this document you talk about "IP spoofing". This document
does not really prevent IP spoofing, but rather mitigates ND-message
falsification. For example, this document does not mitigate DNS
reflectin attacks or the like.

Section 1:
The IEEE
  Standards Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered
  a standard for the generation of IPv6 Interface IDs (IID) called the
  Extended Unique Identifier (EUI-64).

IEEE does not standardize IPv6 things.

Section 3:
  The drawback to using IIDs that do not change over time is one of
  privacy. The node will generate the same IID whenever it joins a new
  network thus making it easy for an attacker to track that node when
  it moves to different networks.

Actually, tracking is a product of constant addresses across networks.
Time variance is not required to prevent network tracking. Please see:
<http://tools.ietf.org/id/draft-ietf-6man-ipv6-address-generation-privacy-00.txt>

Section 3:
  of attack in the IP layer. Our experimental results [2] show that
  SSAS is more secure and faster than CGA when using a sec value of 0
  (Brute force attacks against 64 bits (when using first SSAS
  algorithm) while in CGA this value is 59 bits) and much faster than
  CGA when using a sec value of 1.

Why do you meantion Sec of 0 and then Sec of 1?

  Also the attacker has a few seconds
  to attack 64 bits in SSAS. This is because the neighboring nodes keep
  the public key of this node in their cache after the first successful
  verification.

Doesn't this happen for CGA, too?

3.1.1.3. Denial of Service (DoS) attacks

  An attacker might send many NDP messages, using invalid signatures,
  to a victim?s node which then forces the node to busy itself with the
  verification process. To mitigate this attack, a node SHOULD set a
  limit on the number of messages (x) that should be verified within a
  certain period of time. Implementations MUST provide a conservative
  default and SHOULD provide a means for detecting when this limit is
  reached.

Section 3.1.2:

The current problem with the addressing mechanism
  in a mobile node is that no privacy is observed when a node moves to
  another network while usually keeping its Home Address.

You should clarify what you mean by "mobile networks" -- here you imply
mobile-IP, but people usually refer to "mobile networks" for other
(non-mobile-ip) things.

Section 4:
The second
  algorithm addresses the problem with the security level and tries to
  use the security of the whole public key during the first time
  verification.

It is unclear what you mean with this paragraph.

Thank you,
Tina

On Dec 2, 2013, at 4:47 AM, "Hosnieh" <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

I have uploaded a new version of SSAS on my own server since I want to avoid uploading a new version for a short time on server and also revise two other documents at the same time that is associated with this document. So, please take a look and if you have any comments please let me know so that I can apply them before I upload this version on IETF server.
The changes on this version
- I tried to apply Dan's, Tim's comments
- I clarified the text and removed the typos I found in the text
- I removed many unrelated sections that was there due to the fact that I wrote the last version so quickly!!
- I clarified the purpose and scenarioes on which SSAS can be used.

Here you go:

Thanks,
smile,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 3 Dec 2013 22:21:31 +0100

Hi Tina,

Thank you very much for your support. You’re right that version 7 was
confusing and had a lot of unrelated sections. I actually removed them in
the new version in the following link http://rozanak.com/ssas.txt. I am
going to upload this version on IETF server on Thursday. My waiting is due
to the fact that I am improving attack draft and also almost finished
writing a draft for local security deployment that can complement SSAS. Then
I want also to add this as one of useful references to SSAS while avoid
versioning. During this time, I also would like to apply any comments I
would receive. As I explained before, I am open to improve this document
based on any reasonable comments I receive in the mailinglist and willing to
apply them.

By the way, about IP spoofing if one wants to use it for DNS attack
prevention then one needs to include the SSAS parameters in the packet which
is the public key. In this case, it can prevent/complicate the IP spoofing
but only using this mechanism as an IP generation would not help since the
parameters are only valid in local link and they are not sent to other nodes
over the internet or in other networks.

Thanks,
smile,
Hosnieh
-------------------------------------

Dear all,

Meta:

Section 1:

The IEEE

Section 3:

Actually, tracking is a product of constant addresses across networks.
Time variance is not required to prevent network tracking. Please see:
<http://tools.ietf.org/id/draft-ietf-6man-ipv6-address-generation-privacy-00
.txt>

Section 3:

  verification.

  reached.

Section 3.1.2:

Section 4:

The second

  verification.

Thank you,
Tina