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

["Hosnieh Rafiee" <[e-mail]>]

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