Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper presents an approach to securing local IPv6 networks against neighbor spoofing attacks. 

Even though the research is interesting, several aspects need to be improved:

 

-The paper discusses existing solutions like SEND and CGA but lacks a comparison with more recent approaches in the field.

 

-The paper introduces VBA but needs more detailed explanations of its operational mechanics. For example, the process of cryptographic key derivation and how link-layer address binding specifically improves security should be better discussed.

Including pseudo-code or flow diagrams could help understand the technical implementation of VBA.

 

-The experimental setup and the parameters used for benchmarking VBA should be clearly defined. They are currently missing.

 

-An aspect missing from the paper is the discussion on global adversaries. The authors should discuss how VBA would perform under the assumption of a global adversary capable of monitoring the entire network traffic.

Please refer to the following:

https://www.mdpi.com/2076-3417/12/1/137

https://link.springer.com/chapter/10.1007/978-3-540-76929-3_5

 

-The performance evaluation section should be expanded. More extensive simulations or real-world testing, including different network sizes and configurations, would provide a better understanding of VBA’s performance.

 

-The authors state that VBA enhances privacy but they do not provide any formal or empirical evidence of this claim. A privacy analysis may improve the paper.

 

Comments on the Quality of English Language

Minor editing of English language required

Author Response

Hello. Thank you very much for your time, attention, and valuable feedback in reviewing this work. I would like to address each of your comments individually using this form (rather than a document).

 

Comment 1: "The paper discusses existing solutions like SEND and CGA but lacks a comparison with more recent approaches in the field."
Response 1: Strongly agreed. I have subsequently added a 'Related Works' section which briefly evaluates some more recent NDP security research against the core tenets of the paper (privacy, simplicity, flexibility). You can find this as Section 2.4 in the revised manuscript.

Comment 2: "The paper introduces VBA but needs more detailed explanations of its operational mechanics. For example, the process of cryptographic key derivation and how link-layer address binding specifically improves security should be better discussed. Including pseudo-code or flow diagrams could help understand the technical implementation of VBA."
Response 2: I see your point. Figures 4 and 5 provide adequate information about the process used to generate and verify VBAs, especially when coupled to the step-by-step procedure (list) in Section 3.4. A flow chart or pseudo-code is not really necessary to convey any extra or further helpful information about the process. The article includes most information about binding in its discussion of VBA's design goals in Section 3.3 (with more threat-based perspective in the Threat Model sections 3.2 and 5.4). The work factor introduced by the KDF is expounded in Section 3.4, just under Figure 4. However, I have added a blurb about KDFs specifically functioning as a work factor (and brute-force prevention mechanism) at the end of Section 3.3. Additionally, the article does include a pointer to some helpful C-language code in its Supplementary Materials.

Comment 3: "The experimental setup and the parameters used for benchmarking VBA should be clearly defined. They are currently missing."
Response 3: Agreed. While the results are meant to display a "common shape" which would appear across all different types of hardware--regardless of specifications--it is still sensible to at least list out the properties of the hardware used to drive the experiments. The revised manuscript includes this in the first paragraphs of Section 4 accordingly.

Comment 4: "An aspect missing from the paper is the discussion on global adversaries. The authors should discuss how VBA would perform under the assumption of a global adversary capable of monitoring the entire network traffic."
Response 4: Great point, agreed. While VBA doesn't provide any degree of data confidentiality that needs to be protected from omniscient adversaries, this should be clarified. VBA's focus on privacy preservation is to reduce global identifiability instead. Thus, the sections about the Threat Model (3.2 & 5.4) have been updated to reflect this. Additionally, the Discussion area (Section 5.5) has been updated to clarify the goal of privacy with VBA.

Comment 5: "The performance evaluation section should be expanded. More extensive simulations or real-world testing, including different network sizes and configurations, would provide a better understanding of VBA’s performance."
Response 5: That makes sense; however, VBA's performance is dependent only on the resources provided by the generating/verifying node. It is not affected by network congestion, network size, IP address assignment requirements (such as a minimum assignment count per interface), etc. It is a standalone address derivation and verification methodology that is decoupled from other protocol specifications and network performance issues. Therefore, having more examples or simulations of address generation would not necessarily be valuable content for this publication.

Comment 6: "The authors state that VBA enhances privacy but they do not provide any formal or empirical evidence of this claim. A privacy analysis may improve the paper."
Response 6: Agreed. While a formal analysis of statistical randomness is not quite necessary, it is important to address why. VBA produces addresses with the results of hashing algorithms, which by nature produce uniformly random outputs. Since the entirety of the hextet (16 bits) for iterations counts values can be used in the output VBA, the value in that hextet provides no identifying/leaky information either. I have updated the Discussion section (5.5) with some more details to clarify and emphasize this.

 

I hope to have adequately addressed all of your concerns with the article. Again, thank you for your contribution and your valuable and thorough review. All the best!

Reviewer 2 Report

Comments and Suggestions for Authors

The article discusses the theoretical underpinnings and provides experimental data, but it lacks a detailed discussion on the implementation feasibility of VBA in real-world networks. The authors should include more practical insights or case studies demonstrating the ease of integrating VBA into existing network infrastructures.

While the paper critiques SEND and CGA, it does not provide a direct performance comparison with these existing solutions. Including comparative benchmarks would strengthen the argument for VBA's superiority.

The security analysis is comprehensive but would benefit from a formal proof of security properties. An in-depth theoretical analysis or formal verification of the cryptographic methods used could provide stronger evidence of VBA's robustness.

The paper introduces several new terms and acronyms. Including a glossary at the beginning or in an appendix would help readers unfamiliar with the terminology. However, it really doesn't have to be such a useless table 1. It is recommended to transfer it to the text.

The literature review section could be expanded to include more recent research on IPv6 security and address resolution techniques. Reviewing and updating the literature is necessary, especially for the very old ones. The introduction of IPv6 presents a novel approach. We recommend updating the literature, as some sources (e.g., 11) are no longer relevant due to the already fixed vulnerability.

Figure 8 represents the program code. Therefore, it must be carefully formatted (as code or text) or abandoned because there is no real benefit. We can tell from the text in one sentence about the function used.

Comments for author File: Comments.pdf

Author Response

Hello. Thank you very much for your time, attention, and valuable feedback in reviewing this work. I would like to address each of your comments individually using this form (rather than a document).

 

Comment 1: "The article discusses the theoretical underpinnings and provides experimental data, but it lacks a detailed discussion on the implementation feasibility of VBA in real-world networks. The authors should include more practical insights or case studies demonstrating the ease of integrating VBA into existing network infrastructures."
Response 1: Agreed. Section 5.3 discusses the implementation feasibility of VBA in real-world networks where not all nodes have VBA capabilities. Figure 14 demonstrates the security provided by VBA in such a mixed network. However, I have swapped the title of Section 5.3 to make it more clear that it is a discussion on feasibility. I also added a sentence at the end of the first paragraph in that section, detailing that real-world platforms can choose how they want to implement VBA at the software level (which is a driving force for VBA's flexibility and interoperability).

Comment 2: "While the paper critiques SEND and CGA, it does not provide a direct performance comparison with these existing solutions. Including comparative benchmarks would strengthen the argument for VBA's superiority."
Response 2: This makes sense and it's a great point, but VBA is not declared as a superior option. Rather, it is an alternative method to secure the address resolution process in NDP. This is declared in both of the last paragraphs in the Introduction (Section 1) and the Conclusion (Section 6). SEND and CGA are introduced as the current and canonical specifications that provide a working solution; VBA is a privacy-focused, flexible, and simple alternative to them.

Comment 3: "The security analysis is comprehensive but would benefit from a formal proof of security properties. An in-depth theoretical analysis or formal verification of the cryptographic methods used could provide stronger evidence of VBA's robustness."
Response 3: I see where you are coming from. Section 3.4 provides a detailed ordering (as well as figures) of the procedures used to generate and verify VBAs. The procedure is deterministic and sufficient proof of its validity in generating results is provided throughout the article. Since the specification decouples itself from any specific cryptographic KDFs (providing instead a default set which can be expanded at-will), and the only new 'algorithm' introduced is more procedural than mathematical, a formal analysis is not really warranted.

Comment 4: "The paper introduces several new terms and acronyms. Including a glossary at the beginning or in an appendix would help readers unfamiliar with the terminology. However, it really doesn't have to be such a useless table 1. It is recommended to transfer it to the text."
Response 4: Excellent observation; agreed. I have subsequently modified the table to be much briefer and only include items which are focal and relevant to the article's newly presented content. Other terms did indeed seem to act as noise or filler. I have also trimmed many of the preserved table items and kept it as a table for the sake of organization in the paper.

Comment 5: "The literature review section could be expanded to include more recent research on IPv6 security and address resolution techniques. Reviewing and updating the literature is necessary, especially for the very old ones. The introduction of IPv6 presents a novel approach. We recommend updating the literature, as some sources (e.g., 11) are no longer relevant due to the already fixed vulnerability."
Response 5: Absolutely, agreed. I have added more information in Section 2.4 as a Related Works style section, in order to provide a comparison and brief analysis of more recent NDP security research. However, some of the older research must stay in the paper, since the goals of VBA are to solve a well-known and classic vulnerability in NDP--that is why some of the referenced articles are 'old' or stale. VBA does not build upon other solutions to NDP security issues; it instead is presenting an alternative--therefore, we cannot say that NDP security issues have been "fixed" already, as that is what VBA is aiming to solve.

Comment 6: "Figure 8 represents the program code. Therefore, it must be carefully formatted (as code or text) or abandoned because there is no real benefit. We can tell from the text in one sentence about the function used."
Response 6: This makes sense, but I have a different perspective. The figure referenced here is indeed useful and valuable in understanding the DER-encoded structure of the data in the Public Key and Signature field of the Link Voucher option. Without the figure, the explanation by text does not provide an adequate description of the very specific and exact structure of the data required in that segment of the option. As for formatting, it is left as a monospace, code-like image to preserve its appearance and alignment. It does not need to be copied because it is not actual executable program code or data (more of a structure, like Figure 7).

 

I hope to have adequately addressed all of your concerns with the article. Again, thank you for your contribution and your valuable and thorough review. All the best!

Reviewer 3 Report

Comments and Suggestions for Authors

The paper titled "Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing" proposes a new approach to mitigate IPv6 neighbor spoofing attacks. The authors introduce Voucher-Based Addressing (VBA), a method that aims to provide a simpler, more flexible, and privacy-focused alternative to existing solutions like Secure Neighbor Discovery (SEND) and Cryptographically Generated Addresses (CGA). The research presents a detailed description of the VBA mechanism, including its design goals, address generation and verification processes, and implementation considerations. The proposed method involves the use of cryptographic key derivation functions and link-layer address binding to ensure the verifiability of address resolutions without the complexities associated with SEND and CGA. There are some major comments in the following:

1-  The use of a key derivation function (KDF) in the VBA process is well-articulated. However, it would be beneficial to include a performance comparison with other KDFs, specifically highlighting the computational overhead and latency introduced in practical deployments.

2- The paper should provide a more comprehensive security analysis, including potential attack vectors that VBA could face. For example, how does VBA handle replay attacks or situations where the Link Voucher (LV) is compromised?

3- The explanation of the Link Voucher structure and its role in address generation is clear. However, the practical aspects of implementing and distributing these vouchers in a real-world network environment need further elaboration. How are these vouchers securely distributed and updated across the network?

4- While the paper mentions the compatibility of VBA with existing IPv6 implementations, it should provide more details on the transition strategy from traditional addressing methods to VBA. Are there specific steps or protocols needed to ensure seamless integration?

5- The benchmarks and performance metrics used to evaluate VBA are crucial. It would be useful to include a section that explicitly outlines the evaluation criteria, such as the impact on network latency, throughput, and resource utilization.
6- The paper references several key works, but it would benefit from including more recent studies on IPv6 security and neighbor discovery protocols. For example, incorporating findings from the latest research on mitigating neighbor discovery attacks in IPv6 networks could provide a more comprehensive background and context for VBA. Consider following papers:
a) Blockchain-enabled authentication handover with efficient privacy protection in SDN-based 5G networks
b) An efficient packet parser architecture for software-defined 5G networks
c) Increasing the performance of reactive routing protocol using the load balancing and congestion control mechanism in manet

Author Response

Hello. Thank you very much for your time, attention, and valuable feedback in reviewing this work. I would like to address each of your comments individually using this form (rather than a document).

 

Comment 1: "The use of a key derivation function (KDF) in the VBA process is well-articulated. However, it would be beneficial to include a performance comparison with other KDFs, specifically highlighting the computational overhead and latency introduced in practical deployments."
Response 1: I see your point, but the performance in the experiment is already being measured in a practical setting, since VBA is unaffected by the surrounding network's topology, configurations, latency, volume, etc. The most important aspect of the Results section is that each default KDF is presented relative to one another on the same, consistent hardware. There is no need to evaluate the performance under different scenarios or across different platforms. I have amended the writing within Section 4 to better reflect this.

Comment 2: "The paper should provide a more comprehensive security analysis, including potential attack vectors that VBA could face. For example, how does VBA handle replay attacks or situations where the Link Voucher (LV) is compromised?"
Response 2: Strongly agreed. From the backing research, these details were left out in the final draft of the article and would have resulted in too much bloat (so they were sacrificed). This is the function of the public-key cryptographic structures included with Link Vouchers. I have added these points within Section 3.6 to better emphasize how the public key information secures the Voucher Bearer's position in the network. Do note also that Section 5.2 attempts a (very excised) security analysis and perspective on the research. I have added a small paragraph about LV hijacking here as well.

Comment 3: "The explanation of the Link Voucher structure and its role in address generation is clear. However, the practical aspects of implementing and distributing these vouchers in a real-world network environment need further elaboration. How are these vouchers securely distributed and updated across the network?"
Response 3: Agreed. See Response 2 for these same details and amendments to the article.

Comment 4: "While the paper mentions the compatibility of VBA with existing IPv6 implementations, it should provide more details on the transition strategy from traditional addressing methods to VBA. Are there specific steps or protocols needed to ensure seamless integration?"
Response 4: This makes sense and I somewhat agree here. Section 5.3 already provides this information, but I have added a few updates to its content to make it clearer that it is in regards to implementation feasibility. I have also added a sentence about the viability of using the AGVL IEM in transition situations, based on how mixed networks function (a la Figure 14).

Comment 5: "The benchmarks and performance metrics used to evaluate VBA are crucial. It would be useful to include a section that explicitly outlines the evaluation criteria, such as the impact on network latency, throughput, and resource utilization."
Response 5: Great observation; agreed. I have amended Section 4 (Results) to further discuss how the performance of the network might be impacted by both minimum and difficult KDF configurations.

Comment 6: "The paper references several key works, but it would benefit from including more recent studies on IPv6 security and neighbor discovery protocols. For example, incorporating findings from the latest research on mitigating neighbor discovery attacks in IPv6 networks could provide a more comprehensive background and context for VBA."
Response 6: Strongly agreed. I have added a Related Works style section as Section 2.4 in order to discuss more recent NDP security research proposals. Even though VBA does not build on these, they are indeed worth mentioning with respect to the three core ideals of this paper (simplicity, privacy, and flexibility).

 

I hope to have adequately addressed all of your concerns with the article. Again, thank you for your contribution and your valuable and thorough review. All the best!

Reviewer 4 Report

Comments and Suggestions for Authors

The proposed work for review has a contemporary theme. The work considers a way to protect against neighbor spoofing attacks. In the paper, the authors propose a method to protect against such attacks based on Voucher-Based Addressing. Reviewed work has the following strengths:
1. In the introduction section, a very good introduction to the issues of the subject under consideration is made;
2. The possible neighbor spoofing attacks are strictly and exhaustively examined;
3. Voucher-Based Addressing is discussed in great detail.
Notes and recommendations:
1. Section 2 should be renamed "State of the problem" or another more appropriate title, according to the authors, in which attention should be paid to the current state of the problem;
2. To add a new section "Related work", in which authors can review other authors who have worked on a similar topic, in order to highlight why and how their work differs from others;
3. In the "Prototypes & Results" section, the authors should describe in more detail how they performed the experimental studies (simulations, modeling, what software they used, etc.) to prove the applicability of their proposed method. Additionally, in this section, they should organize the structure of the presented graphics. 4.3, 4.4, 4.5 have only graphs, without analysis of the obtained results. There is some analysis after figure 10, but it is not clear what it is for. This needs to be corrected because that is the point of the whole study.
4. Section "Summary, Future Research, & Conclusion" to remain only "Conclusion". The rest should be transferred to the previous "Discussion" section. They may also be separated into a separate chapter "Future Research". Summary is assumed to have been made in the Discussion section and does not need to be redone. In the "Conclusions" section, authors should in telegraph-style list/note the most important things they did in their research without repeating the abstract;
5. The used references are very old. It should be replaced with a newer one from the last 4-5 years.

Author Response

Hello. Thank you very much for your time, attention, and valuable feedback in reviewing this work. I would like to address each of your comments individually using this form (rather than a document).

 

Comment 1: "Section 2 should be renamed 'State of the problem' or another more appropriate title, according to the authors, in which attention should be paid to the current state of the problem."
Response 1: I understand your perspective here, but "Background & Motivation" is a fairly typical title for a section which outlines the specific motivations behind the research and what other work has been done to correct the issue. This is the purpose of the section; it is more expository than just 'where the problem is now', because it fully explains and demonstrates the underlying threats. Section 2 has become more than a coverage of the problem in this revision, due to the introduction of a Related Works subsection (per Comment 2).

Comment 2: "To add a new section 'Related work', in which authors can review other authors who have worked on a similar topic, in order to highlight why and how their work differs from others."
Response 2: Strongly agreed. This section (Section 2.4) has been added to include a perspective on more recent NDP security research, as well as an analysis of each according to the three core ideals of the paper (simplicity, privacy, and flexibility).

Comment 3: "In the 'Prototypes & Results' section, the authors should describe in more detail how they performed the experimental studies (simulations, modeling, what software they used, etc.) to prove the applicability of their proposed method. Additionally, in this section, they should organize the structure of the presented graphics. 4.3, 4.4, 4.5 have only graphs, without analysis of the obtained results. There is some analysis after figure 10, but it is not clear what it is for. This needs to be corrected because that is the point of the whole study."
Response 3: Great observation; agreed. This has been added to the text beginning in Section 4 and the misfit text has been moved to be alongside the rest. The sub-section headings have been removed because they were unnecessary, useless, and confusing.

Comment 4: "Section 'Summary, Future Research, & Conclusion' to remain only 'Conclusion'. The rest should be transferred to the previous 'Discussion' section. They may also be separated into a separate chapter 'Future Research'. Summary is assumed to have been made in the Discussion section and does not need to be redone. In the 'Conclusions' section, authors should in telegraph-style list/note the most important things they did in their research without repeating the abstract."
Response 4: Mostly in agreement here. I have renamed the final section as just 'Conclusion' because the other items should indeed appear in the prior section. The conclusion has been slightly modified to accommodate this, but I do not believe a terse bullet-point list is necessary for the conclusion of the paper since the conclusion is by no means enormous, misleading, or incomprehensible.

Comment 5: "The used references are very old. It should be replaced with a newer one from the last 4-5 years."
Response 5: Mostly agree here too. Since VBA is targeting a very well-known (and considerably 'old') issue, the stale references are still just as valid. This is because VBA is presented as an alternative solution to this longstanding spoofing problem. Some places across the article (most especially Section 2.4) have been updated to include some more recent references about NDP, NDP issues, and NDP security research.

 

I hope to have adequately addressed all of your concerns with the article. Again, thank you for your contribution and your valuable and thorough review. All the best!

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The authors addressed my comments.

Author Response

Thank you for your time, attention, and valuable feedback.

Reviewer 3 Report

Comments and Suggestions for Authors

Thanks for the updating, but the comment 6 has not addressed properly and the authors miss considering the following paper to bring in section 2.2 and rest of the paper:
a) Blockchain-enabled authentication handover with efficient privacy protection in SDN-based 5G networks
b) An efficient packet parser architecture for software-defined 5G networks
c) Increasing the performance of reactive routing protocol using the load balancing and congestion control mechanism in manet

Author Response

Hello,

 

Yes, we have considered the articles you suggested by title. I see why you might offer these works as being relevant, but they are too distant from the main points of our summarized and condensed paper to be added. All suggested papers are written by the same author who is an expert in a different sub-specialization of networking; each paper focusing on non-adjacent topics.

a.) This paper regards 5G authentication handovers and user privacy preservation when moving between cells. There is no reference to IPv6 or NDP, and VBA is not concerned with the specifics of 5G networking (nor does it need to be). I do not see how this relates specifically to the problem that VBA solves.

b.) This paper discusses packet parsing architecture for SDN in 5G networks. Unfortunately, I fail to see what the relevance is to VBA outside of both articles being in the 'networking' category. IPv6 is not a topic of discussion and there is also no information about Neighbor Discovery Protocol. VBA focuses on address generation and verification during NDP: it has little to do with SDN or 5G (specifically), and packet parsing is a very foundational and broad topic which shares no direct relation here.

c.) This paper discusses routing performance in mobile ad-hoc networks. VBA has nothing to do with routing, routing performance, mobile ad-hoc networking, routing algorithms, etc. The NDP Address Resolution process occurs between any neighboring nodes on generic, local IPv6-based networks. The keyword being 'generic' because IPv6 can be carried across any networking medium (including the specifics of 5G). I unfortunately do not understand what general relevance there is for this work as well.

 

Apologies for not being able to find a way to incorporate your suggested works into this paper. Thank you again for your valuable feedback, time, and attention. It is appreciated.

Reviewer 4 Report

Comments and Suggestions for Authors

1. The "Conclusion" section has not been edited at all. Only the section title has been changed, but not the section content. Lines 1023 to 1033 are appropriate to remain for the section. The rest of the text is not needed - these are summaries suitable for the "Discussion" section. They can be deleted or moved to appropriate places in the "Discussion" section.

2. Subsection 2.4 would be nice to end with a short analysis/comment showing how the presented work by the authors differs from the considered work of other authors.

Author Response

Greetings,

 

Comment 1: "The 'Conclusion' section has not been edited at all. Only the section title has been changed, but not the section content. Lines 1023 to 1033 are appropriate to remain for the section. The rest of the text is not needed - these are summaries suitable for the 'Discussion' section. They can be deleted or moved to appropriate places in the 'Discussion' section."
Response 1: Mostly agreed. I would rather not decimate the entire concluding statement, so I have opted to move most of the Conclusion text up into a new Discussion "Summary" subsection. The penultimate paragraph stating the intent of the research as well as listing a few details about future developments does not really justify a "Future Works" subsection under Discussion: I have left it in the Conclusion since the cadence of the writing is more conclusive than it is descriptive.

Comment 2: "Subsection 2.4 would be nice to end with a short analysis/comment showing how the presented work by the authors differs from the considered work of other authors."
Response 2: Strongly agreed. I have subsequently amended the end of Section 2.4 to include a comprehensive comment about why VBA satisfies the ideals of the paper where the other works do not.

 

Thank you for your time, attention, and valuable feedback. It is appreciated.