Hi Antonie,
Let me try to answer the question. In general, I am trying to find a way
to do path verification for internal attack. If there is a way that will
not increase the size of the packet and also can simplify the hardware
requirement on encryption/decryption would be perfect.
See my comments inline with [fyang2].
在 2025-04-22 20:36, Antoine FRESSANCOURT 写道:
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]
The hash would becomputed like this on each node. Node1: y1 =
H_1(SID_1);Node2: y2 = H_2(SID_2) + H_2(y1);Node3: y3 = H_3(SID_3) +
H_3(y2);Node4: y4 = H_3(SID_4) + H_4(y3). The "y" will be carried by the
packet and updatedon each hop. In this way, nodes not allowed to be
bypassed will have fingerpint in the "y". Agree that the linear
expression form is not sufficient.
> [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> 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>
Sent: Monday, April 7, 2025 2:24 PM
To: Antoine FRESSANCOURT <antoine.fressanco...@huawei.com>;
linchangwang <linchangwang.04...@h3c.com>; spring@ietf.org;
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; 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
--
BR,
Feng Yang （杨锋）
--
BR,
Feng Yang （杨锋）
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
