Subject: I-D action : draft-rafiee-6man-ssas-01

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 2 Feb 2013 09:44:20 +0100

Hello,

Anyone had an opportunity to view the new version of our SSAS draft RFC. I
received no comments after I applied the last comments given by Ray, Jeremy,
Fernando and others.  Your thoughts and comments would be greatly
appreciated. 

 <http://tools.ietf.org/html/draft-rafiee-6man-ssas-01>
http://tools.ietf.org/html/draft-rafiee-6man-ssas-01

Thank you,

Hosnieh

---

From: Karl Auer <[email-masked]>
Date: Sat, 02 Feb 2013 23:02:54 +1100

> http://tools.ietf.org/html/draft-rafiee-6man-ssas-01

Comments below. Disclaimer: I am not a crypto guy :-)

Regards, K.

In the Abstract: I don't think the word "organitionally" exists. If it
does it is so unusual that it should be replaced with a more common word
or with a description of what the word means.

CGA were not designed to address privacy related attacks, they are a
means of securing NDP exchanges. The fact that they appear random is
coincidental to their function.

Introduction: Either always use leading zeros in your example values, or
never, but don't mix them. I suggest that always using leading zeros
would be better.

MAC should always be capitalised: "MAC", not "Mac", throughout.

In your description of how an EUI-64 IID is formed, you have omitted the
need to complement bit7 of the IID.

The introduction repeats the error in the abstract, that CGA addresses
are "used to randomize the IID".

There are places where necessary spaces have been omitted:
"[RFC3315]can", "approachfor".

The sentence beginning "This convention..." is unnecessary.

In the problem statement, the second sentence should read "...easy for
an attacker to track that node as it moves between networks." Or
similar, but it is unclear as it stands.

"If one wants to use a secure method, with the privacy extension, then
one needs to use CGA." Can one use CGA with privacy addressing? That is,
can you have CGA addresses that change regularly, as privacy addresses
do? I'm not sure.

Spell check everything ("Deniel of Service", "deminished", etc)

"In order to overcome the problem with the other mechanisms,[...]" What
other mechanisms? Isn't this just a problem with CGA?

"the time is needed to generate and verify IP address needs to be
decreased" -> "the time required to generate and verify IP addresses
needs to be reduced"

In 2.1.1.3 there is an odd character in "victim?s", should be
"victim's". The same odd character appears in other places.

In 2.1.1.3 suggest that the first SHOULD should be MAY.
 
In 2.1.1.3, it is unclear whether the formula is provided as a helpful
hint, or whether this is the formula that should be used. Why a 2-minute
window? I suggest using language similar to other RFCs in similar
situations, e.g. "To mitigate such an attack, a node SHOULD rate limit
message verification. Implementations MUST provide a conservative
default and SHOULD provide a way for the rate limiting parameters to be
set by the node administrator."

2.1.2 should provide an explanation of why SSAS is helpful in nodes with
limited resources. It appears that it is not helpful per se, but is
helpful *in comparison to CGA*, because of the lower computational load.
An explanation is also needed for why SSAS is useful in mobile networks.

In the first para of section 3: Compute load is only a problem with CGA.
Privacy is only a problem with SLAAC (and maybe with CGA if a node uses
the same 64-bit CGA IID on multiple networks). This introductory
paragraph seems to just restate what has already been said elsewhere and
could probably be dropped anyway.

3.1 step 2: There is no need to specify XML or any other particular
storage method, format or location. These can be left to the
implementation. All that is necessary is that these items be stored
where they will survive for the length of time a particular key pair
will be in use. You need to address the situation where a node has no
such storage.

3.1 step 2 second para: The use of should and SHOULD is confusing.
Should a node generate new keys? If it does, should it use them? If it
isn't going to use them, why generate them? What happens when a new
address is generated - is it used alongside the old one or are current
connections using the old address dropped immediately? The loss of
active connections when an address changes might be worth mentioning
somewhere.

3.1 step 2: Either the encryption algorithms used must be stipulated, or
there must be some mechanism for the verifier to know what method was
used by the sender.

3.1 step 3: What is "a fixed point format"? Needs explanation. If there
is more than one possible "fixed point format" then the specific one
used by SSAS must be specified.

3.1 step 5: Why is a whole byte needed to store a value from 0 to 20?
Have you done the maths to check that this value will actually
meaningfully "[help] randomize the IID and [...] minimize the chance of
a collision in the network"? If the benefit is not significant, then
this step should be omitted.

3.1 step 10 "this IP will be permanent after..." This contradicts
earlier recommendations that the IP be changed after a certain period.

3.2 This needs to be clearer. It seems that you are describing the
components of the NDP message that will be signed, not items that will
actually be included in the signature. Either way, it seems to me that a
list of components should be provided for each NDP message type that
requires signing, with a default to cover all others and any that have
not yet been invented.

3.3 How does a recipient know whether a message is SEND+SSAS or just
SEND?

3.3.1: Length is described as including certain fields; the description
does NOT include certain other fields, such as subnet prefix, other
options. It seems to me that length can simply be described as "the
length of the signature data field". Might be an idea to specify the
units, eg "length in octets".

3.3.1 Padding would be more simply described by saying that "if the
above values do not form an SSAS signature field that is an exact
multiple of eight octets long, random octets are added to the end of the
signature field to bring its length up to an exact multiple of eight
octets." Or octets with the binary value zero, or whatever.

3.3.1: "If, for a second time, the node receives the same claim, then it
considers it an attack and will use that IP address." Why? And why two?
Is this because no two nodes should ever be able to generate the same
address? If so, then either one try is sufficient, or arbitrarily many
will be insufficient.

4: This seems to need a bit of bulking out. Also, the discussion of
trust anchors is unclear - what, if any, place do trust anchors have in
SSAS? Might be worth discussing how shorter key validity periods affect
the likelihood of a successful attack.

5. Is that an IAN consideration?

6. This section repeats the error that CGA is about randomising IIDs. It
is not, that's a side effect at best.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 2 Feb 2013 22:41:42 +0100

Thanks for your comments. Please find my responses inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karl
Auer
Sent: Saturday, February 02, 2013 1:03 PM
To: [email-masked]
Subject: Re: I-D action : draft-rafiee-6man-ssas-01

>In the Abstract: I don't think the word "organitionally" exists. If it does
it is so unusual that it should be replaced with a more common word or with
a description of what the word means.

Ok, I will correct it in next version. Maybe I created a new English word...
who knows ;-)  How about "organizationally"?

> CGA were not designed to address privacy related attacks, they are a means
of securing NDP exchanges. The fact that they appear random is coincidental
to their function.

It is true that the main purpose was security, but it is not true that
privacy was not a consideration. You can find in many parts of the CGA RFC
(RFC 3972) where privacy is also mentioned. Some such sections are section
3, where it explains that the reason for the addition of a modifier is to
enhance privacy by adding randomness to the address and at the end of
section 4 and in section 7.3 where privacy considerations are clearly
explained.

>Introduction: Either always use leading zeros in your example values, or
never, but don't mix them. I suggest that always using leading zeros would
be better.

Good point. I will do this.

>MAC should always be capitalised: "MAC", not "Mac", throughout.

Will correct this  in the next version.

You mean bits u and g (both 7 and 8). I'll add it.  Of course these two bits
are a matter for discussion in Brian's draft :-)

>The introduction repeats the error in the abstract, that CGA addresses are
"used to randomize the IID".

In RFC Privacy Extension (section 3.2.3) and also CGA RFC (in stated
sections), it also mentioned CGA as an approach to randomize IID

>"[RFC3315]can", "approachfor".

The problem of my "spacebar" in keyboard, sometimes doesn't work and....
thx. I'll fix it in next version

>The sentence beginning "This convention..." is unnecessary.

I'll remove it

>In the problem statement, the second sentence should read "...easy for an
attacker to track that node as it moves between networks." Or similar, but
it is unclear as it stands.

Yes true. I'll update it.

>"If one wants to use a secure method, with the privacy extension, then one
needs to use CGA." Can one use CGA with privacy addressing? That is, can you
have CGA addresses that change regularly, as privacy addresses do? I'm not
sure.

Yes you can. Please see my first response.

> Spell check everything ("Deniel of Service", "deminished", etc)

Ops... Ok, I'll correct it in next version.

True, maybe I will have to rephrase the sentence. I wanted to address both
privacy related attacks (privacy extension RFC) and also the problem with
CGA.

>"the time is needed to generate and verify IP address needs to be
decreased" -> "the time required to generate and verify IP addresses needs
to be reduced"

>In 2.1.1.3 there is an odd character in "victim?s", should be "victim's".
The same odd character appears in other places.

? will be replaced with ' .

> In 2.1.1.3 suggest that the first SHOULD should be MAY.

I'll correct it.
 
hint, or whether this is the formula that should be used. Why a 2-minute
window? I suggest using language similar to other RFCs in >similar
situations, e.g. "To mitigate such an attack, a node SHOULD rate limit
message verification. Implementations MUST provide a conservative default
and SHOULD provide a way for the rate >limiting parameters to be set by the
node administrator."

Good suggestion! I will apply it.

>2.1.2 should provide an explanation of why SSAS is helpful in nodes with
limited resources. It appears that it is not helpful per se, but is helpful
*in comparison to CGA*, because of the lower >computational load.
>An explanation is also needed for why SSAS is useful in mobile networks.

I will clarify this section. 

>Privacy is only a problem with SLAAC (and maybe with CGA if a node uses the
same 64-bit CGA IID on multiple networks). This introductory paragraph seems
to just restate what has already been said >elsewhere and could probably be
dropped anyway.

Ok I will correct it.

>3.1 step 2: There is no need to specify XML or any other particular storage
method, format or location. These can be left to the implementation. All
that is necessary is that these items be stored where >they will survive for
the length of time a particular key pair will be in use. You need to address
the situation where a node has no such storage.

I think I really saw it from the implementers' point of view. You are right.
I will change it.

>Should a node generate new keys? If it does, should it use them? If it
isn't going to use them, why generate them? What happens when a new address
is generated - is it used alongside the old one or >are current connections
using the old address dropped immediately? The loss of active connections
when an address changes might be worth mentioning somewhere.

The old IP address status is changed to deprecated. This means the node will
not use it for the new connection but it can continue using it for the old
connections. 
When the node generates a new IP address, it should also re-generate
public/private keys because of the privacy concerns.

> 3.1 step 2: Either the encryption algorithms used must be stipulated, or
there must be some mechanism for the verifier to know what method was used
by the sender.

I will add a bit to the SSAS data structure in order to distinguish between
RSA and ECC or other faster algorithms of the future.

> 3.1 step 3: What is "a fixed point format"? Needs explanation. If there is
more than one possible "fixed point format" then the specific one used by
SSAS must be specified.

I explained in the draft that we are using the same format as RFC SEND.

>Have you done the maths to check that this value will actually meaningfully
"[help] randomize the IID and [...] minimize the chance of a collision in
the network"? If the benefit is not significant, then >this step should be
omitted.

Yes , it does.

>3.1 step 10 "this IP will be permanent after..." This contradicts earlier
recommendations that the IP be changed after a certain period.

I meant the status of the IP address. The first status will be temporary and
if no collisions are found the status will change to permanent. The 3
statuses for an IP address are deprecated, temporary and permanent. This
defines how the IP address can be used at the start of new connections or
its use in existing connections. Each IP address has a lifetime. When the
lifetime of the IP address has expired, the node changes the status of the
IP address to deprecated. 
I will add the status and add this explanation to the new version.

components of the NDP message that will be signed, not items that will
actually be included in the signature. Either way, it seems to me >that a
list of components should be provided for each NDP message type that
requires signing, with a default to cover all others and any that have not
yet been invented.

True. Maybe instead of NDP, I have to change it to SEND. Then it might be
clearer.

SEND?

In SSAS, just the RSA signature is different than the RSA signature section
of SEND. I will think about using another type, like type=16, for SSAS Data
field (signature and...).

>3.3.1: Length is described as including certain fields; the description
does NOT include certain other fields, such as subnet prefix, other options.
It seems to me that length can simply be described as >"the length of the
signature data field". Might be an idea to specify the units, eg "length in
octets".

Good suggestion.

>3.3.1 Padding would be more simply described by saying that "if the above
values do not form an SSAS signature field that is an exact multiple of
eight octets long, random octets are added to the end >of the signature
field to bring its length up to an exact multiple of eight octets." Or
octets with the binary value zero, or whatever.

Good suggestion.

>Is this because no two nodes should ever be able to generate the same
address? If so, then either one try is sufficient, or arbitrarily many will
be insufficient.

There have been no proven collisions using SHA256. Also, it will be a very
rare case when two nodes choose the same modifier and even rarer If, after a
node increments the modifier after the first collision, another node will
have the IP address. 

> 4: This seems to need a bit of bulking out. Also, the discussion of trust
anchors is unclear - what, if any, place do trust anchors have in SSAS?
Might be worth discussing how shorter key validity periods > affect the
likelihood of a successful attack.

I will clarify the section describing trust anchors. About successful
attacks, in practice, it is not like theoretical proofs; the probability is
very low. I obtained that mathematical proof by finding the expected value
for 2 days, 10 days, and also 20 days... . 

>5. Is that an IAN consideration?
 
It might be.

>6. This section repeats the error that CGA is about randomising IIDs. It is
not, that's a side effect at best.

Please refer to my first response

Thank you. I really cannot understand how I made so many spelling mistakes,
especially when I had a text correctors in front of me... :-/ or perhaps
sleepy!?
Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 08:20:02 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Karl

...
> are a matter for discussion in Brian's draft :-)

Only the u bit is complemented, the g bit is untouched.

In any case, draft-carpenter-6man-ug doesn't change or abolish this.

    Brian

---

From: George Mitchell <[email-masked]>
Date: Sun, 03 Feb 2013 16:35:36 -0500

On 02/02/13 16:41, Hosnieh Rafiee wrote:
> [...]

Administratively?                                     -- George Mitchell

Subject: RE: I-D action : draft-rafiee-6man-ssas-01
From: "Hosnieh Rafiee" <[email-masked]>
To: "'Karl Auer'" <[email-masked]>
Cc: [email-masked]
Date: Sat, 2 Feb 2013 22:41:42 +0100
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>

-----Original Message-----

I'll remove it

I'll correct it.

Ok I will correct it.

Yes , it does.

SEND?

Good suggestion.

Good suggestion.

 
It might be.

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

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Feb 2013 09:58:37 +1100

On Sun, 2013-02-03 at 16:35 -0500, George Mitchell wrote:
> >> In the Abstract: I don't think the word "organitionally" exists.
> Administratively?

The word is unnecessary anyway. Just leave it out.

Regards, K.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 03:52:47 -0300

Hosnieh,

On 02/02/2013 06:41 PM, Hosnieh Rafiee wrote:
> privacy was not a consideration.

It can't be a consideration, because in order for CGAs to serve their
purpose, nodes must be able to compute the IID. An IID that aims at
protecting user privacy works the other way around: a third-party should
not be able to compute the IID.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 4 Feb 2013 15:46:05 +0100

purpose, nodes must be able to compute the IID. An IID that aims at
protecting user privacy works the other way around: a third->party should
not be able to compute the IID.

Please refer you to CGA RFC.

About SSAS: the purpose of this draft is to discuss the means of combining
or integrating privacy (layer 3) and security.

Thank you,
Hosnieh

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Montag, 4. Februar 2013 07:53
To: Hosnieh Rafiee
Cc: 'Karl Auer'; [email-masked]
Subject: Re: I-D action : draft-rafiee-6man-ssas-01

Hosnieh,

On 02/02/2013 06:41 PM, Hosnieh Rafiee wrote:
>> means
> of securing NDP exchanges. The fact that they appear random is 

It can't be a consideration, because in order for CGAs to serve their
purpose, nodes must be able to compute the IID. An IID that aims at
protecting user privacy works the other way around: a third-party should not
be able to compute the IID.

Cheers,