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./
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.
/
- 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./
Thanks in advance for your clarifications !
Best regards,
Antoine
*From:*linchangwang <linchangwang.04...@h3c.com>
*Sent:* mardi 1 avril 2025 07:42
*To:* spring@ietf.org; 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
To unsubscribe send an email tospring-le...@ietf.org
--
BR,
Feng Yang （杨锋）
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
