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

[Tina TSOU <[e-mail]>]

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" <[e-mail]<mailto:[e-mail]>> 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:
http://rozanak.com/ssas.txt

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