Thanks for your comments. Please find my responses inline. -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Karl Auer Sent: Saturday, February 02, 2013 1:03 PM To: ipv6@ietf.org Subject: Re: I-D action : draft-rafiee-6man-ssas-01
> http://tools.ietf.org/html/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. >In your description of how an EUI-64 IID is formed, you have omitted the need to complement bit7 of the IID. 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 >There are places where necessary spaces have been omitted: >"[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. >"In order to overcome the problem with the other mechanisms,[...]" What other mechanisms? Isn't this just a problem with CGA? 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. >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." 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. >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. 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. >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. 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. > 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. 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. >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. True. Maybe instead of NDP, I have to change it to SEND. Then it might be clearer. > 3.3 How does a recipient know whether a message is SEND+SSAS or just 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. >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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
