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?
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.
- 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.
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 to spring-le...@ietf.org
