Hello, Thanks a lot for your clarifications. Please see some additional remarks prefixed with [AFT2] inline.
Best regards, Antoine Fressancourt From: 刘鹏辉 <liupenghui1...@163.com> > [AFT] > Let me please clarify the notation so we are on the same page. > Let’s denote H_N(x) the hash of byte string x keyed by the key specific to > node N. Besides, let’s denote SID_N the SID designating node N in the SID > list. > Then can you confirm that your first formula is : > H(4321) = H_4 (H_4 (SID_4) + H_3 (H_3 (SID_3) + H_2 (H_2 (SID_2) + H_1 > (SID_1)))) > If this holds, and considering that the hash is secure, then it should not > be possible to denote H(4321) as a linear expression of H_1 (SID_1), H_2 > (SID_2), H_3 (SID_3) and H_4 (SID_4). > Besides, my point is that if nodes 1, 2, 3 and 4 share the same key, then any > on path node can compute elements in your expression, so any node can fake > the verification of a path > comprising nodes sharing the same group key. >[/AFT] [PHLIU] actually, each node can have a different MAC key. [/PHLIU] [AFT2] The purpose of having H_1, H_2, H_3 and H_4 was to indicate that the hash function is keyed by a different key at each node: H_1(x) = H(k1, x), H_2(x) = H(k2, x) etc. Thus my request for clarification was whether I associated the proper key to each hash in the equation written. [/AFT2] > [AFT] > If you want the target to determine easily which node has been bypassed in a > secure way, my recording of the academic state of the art mechanisms is that > you have to include each > intermediate result in the header, at the expense of overhead. > I agree that faking a path and computing the hashes to be included in a > header from an attacker will increase complexity, but this increase in > complexity is not exponential: the additional cost for > faking a shortcut is linear in the number of the bypassed node. While this is > an increase, this is not expensive enough to be infeasible for an attacker in > my point of view. > [/AFT] [PHLIU] In my initial idea, each intermediate routing node could directly communicate with the orchestrator, which could obtain the running status of each node and the configuration of business operations at any time. These could be used as evidence for further forensic, and there was no need to add too much information in the business header (a small amount of necessary information could be added). the prerequisites are that all routing nodes must be certified and authenticated, such as with SECURE BOOT, TPM, TEE etc。 [/PHLIU] [AFT2] If this is the setup you have in mind, then I am wondering why you even carry a signed field in the first place: if every node communicates with a central entity to get the path validated, then the node can pass a signature of the SID list to the orchestrator to make sure that the list has not been altered in transit. In my mind, carrying a field used for path validation makes sense if the entity enforcing the path and the entity validating the path are different. If you are in a centralized deployment in which nodes communicate with an orchestrator in charge of validating the path, then each node only needs to compute a packet / path signature and send it to the orchestrator for validation. [/AFT2] At 2025-04-18 00:50:57, "Antoine FRESSANCOURT" <antoine.fressancourt=40huawei....@dmarc.ietf.org<mailto:antoine.fressancourt=40huawei....@dmarc.ietf.org>> wrote: Hello, Sorry for my delayed answer. I have some additional questions or clarifications, prefixed with [AFT]. Best regards, Antoine Fressancourt From: Feng Yang <yangf...@chinamobile.com<mailto:yangf...@chinamobile.com>> Sent: Monday, April 7, 2025 2:24 PM To: Antoine FRESSANCOURT <antoine.fressanco...@huawei.com<mailto:antoine.fressanco...@huawei.com>>; linchangwang <linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com>>; spring@ietf.org<mailto:spring@ietf.org>; n...@ietf.org<mailto:n...@ietf.org> Subject: Re: [spring] Re: Seeking feedback on the SRv6 Path Verification draft [draft-yang-spring-srv6-verification-00] Hi Antoine, Thanks for your questions. See my comments inline. 在 2025-04-04 21:31, Antoine FRESSANCOURT 写道: Hello, I read your draft with a lot of interest. It comes as a complement of previously proposed mechanisms. As a disclaimer, I am a co-author of the now expired draft-iannone-spring-srv6-pot-00 (https://datatracker.ietf.org/doc/html/draft-iannone-spring-srv6-pot-00). First I have a clarification question: - In your draft, the PoT validation mechanism uses a combine operation: what is this operation exactly? From a performance / execution time perspective, how does it compare to the computation of a keyed HMAC? [fyang]: The expected algorithm is recursive HMAC as well. For example, if a packet passes through four nodes numbered 4, 3, 2, and 1, the HMAC value can be calculated as follows. H(4321) = H(H(4) + H(H(3) + H(H(2) + H(1)))). For ease of reading, the key is not put into the formula. Possibly, it can be simplified. H(4321) = a*H(4) + b*H(3) + c*H(2) + d*H(1), where the a/b/c/d can be set to 1 if collision is not high. [AFT] Let me please clarify the notation so we are on the same page. Let’s denote H_N(x) the hash of byte string x keyed by the key specific to node N. Besides, let’s denote SID_N the SID designating node N in the SID list. Then can you confirm that your first formula is : H(4321) = H_4 (H_4 (SID_4) + H_3 (H_3 (SID_3) + H_2 (H_2 (SID_2) + H_1 (SID_1)))) If this holds, and considering that the hash is secure, then it should not be possible to denote H(4321) as a linear expression of H_1 (SID_1), H_2 (SID_2), H_3 (SID_3) and H_4 (SID_4). Besides, my point is that if nodes 1, 2, 3 and 4 share the same key, then any on path node can compute elements in your expression, so any node can fake the verification of a path comprising nodes sharing the same group key. [/AFT] Then, I have some remarks: - In the mechanism you describe, the combined result is incrementally computed by the intermediate nodes until the tail node. But from the verification of the combined result, the tail node is not certain that the SID list is the one that was intended by the head node. Indeed, given that at a given intermediate node, the validation is based on the combined result of previous verification made by previous nodes and on the hash of the current SID, nothing prevents this intermediate node to add SIDs afterwards to tamper with the SID list. The integrity of the SID list can be assured by the HMAC computed by the head node, but this HMAC needs to be keyed by a different set of keys to avoid this SID list modification attack from an intermediate node. [fyang]: My understanding is that, in the scenario where the SRH header is modified, it can only be done by an internal attacker. Some attacks might not change the SRH but still route the packet through specific SRv6 nodes, such as through a Route Policy. If one needs to know whether unwanted nodes have been added to the path, the simplest method is to configure all SRv6 nodes to leave their fingerprints in the packet. [AFT] It would not be sufficient. To avoid any on path node from modifying the SID list, the SID list needs to be signed somehow with a key specific to each traversed node. I agree that SRH header modification is done by an internal attacker, my whole point is that such an attack should be covered in a path verification system. [/AFT] - I am skeptical about the fact that the mechanism you have designed seems to be using a group key shared by all the nodes on the path (at least this is my understanding of the text). If the HMACs are computed by the intermediate nodes using the same group key, then it is possible for two cooperating nodes on the path to exchange the packet directly without using the path described by the SID list. In this attack, the attacking node that is closer to the destination can compute the validation proof on behalf of the skipped nodes and relay the packet with a valid proof of transit. Note that if in your design specific keys are used by each intermediate node, the mechanism you are describing is very similar to the one presented in draft-iannone-spring-srv6-pot-00. [fyang]: The key can be configured to be different for each node. A potential advantage of this combination method is that it is easy to detect which node has been bypassed. Of course, if a large number of nodes are bypassed, the computational complexity will increase. [AFT] If you want the target to determine easily which node has been bypassed in a secure way, my recording of the academic state of the art mechanisms is that you have to include each intermediate result in the header, at the expense of overhead. I agree that faking a path and computing the hashes to be included in a header from an attacker will increase complexity, but this increase in complexity is not exponential: the additional cost for faking a shortcut is linear in the number of the bypassed node. While this is an increase, this is not expensive enough to be infeasible for an attacker in my point of view. [/AFT] Thanks in advance for your clarifications ! Best regards, Antoine From: linchangwang <linchangwang.04...@h3c.com><mailto:linchangwang.04...@h3c.com> Sent: mardi 1 avril 2025 07:42 To: spring@ietf.org<mailto:spring@ietf.org>; n...@ietf.org<mailto:n...@ietf.org> Subject: [nasr] Seeking feedback on the SRv6 Path Verification draft [draft-yang-spring-srv6-verification-00] Dear SPRINGWG and NASRWG, This document proposes a path verification mechanism for SRv6, which adopts a hop-by-hop cryptographic computation on the destination segment identifier at each node, combined with an end-to-end verification at the last hop. Link: https://datatracker.ietf.org/doc/draft-yang-spring-srv6-verification/ Slides: https://datatracker.ietf.org/meeting/122/materials/slides-122-spring-srv6-path-verification-01.pdf Any feedback or comments are more than welcome. Thanks, Changwang ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ spring mailing list -- spring@ietf.org<mailto:spring@ietf.org> To unsubscribe send an email to spring-le...@ietf.org<mailto:spring-le...@ietf.org> -- BR, Feng Yang （杨锋） [https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_99cff20a6ced36f6859dd97ac29c0f0f]
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
