On Sat, 2013-02-02 at 09:44 +0100, Hosnieh Rafiee wrote:
> 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
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 protected])
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
