What’s the cost of HMAC computation wrt that SID in each Hop and its
impact overall traffic latency ?
/keshava
*From:*Feng Yang <yangf...@chinamobile.com>
*Sent:* 27 April 2025 11:22
*To:* Antoine FRESSANCOURT <antoine.fressanco...@huawei.com>;
刘鹏辉<liupenghui1...@163.com>
*Cc:* linchangwang <linchangwang.04...@h3c.com>; spring@ietf.org;
n...@ietf.org
*Subject:* [spring] Re: [nasr] Re: Re: Seeking feedback on the SRv6
Path Verification draft [draft-yang-spring-srv6-verification-00]
[*CAUTION*: This email originated from outside of *Tejas*. Do not
click links or open attachments unless you recognize the sender and
know the content is safe]
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> <mailto: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 updated on 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
<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fhtml%2fdraft-iannone-spring-srv6-pot-00&c=E,1,uN9-TQGJnmC8iBzpdD0fO_BA3ToYTWp3sh3-xQUDj28JUj40O_G3SlC4Jnc_o1zv3Gh79RnVXVnpEdyWmzXJKbys41CY_Fdb9we4STK56RE,&typo=1>).
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/
<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-yang-spring-srv6-verification%2f&c=E,1,voilJFu79Y8EP6js9EJodCOYaNrVaU-HovR_dPy4kOHou53IHMmuuzA6Aa4tGyomP8mhLs5Qsqx-OfEzwpGCKzRGBuT6mINMRSETnsHA4Dw,&typo=1>
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-spring-srv6-path-verification-01.pdf
<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fmeeting%2f122%2fmaterials%2fslides-122-spring-srv6-path-verification-01.pdf&c=E,1,sF9LDX7JQjNxyBeLvMUwCr7wPyc3PAC-tkZCXsThoni3Qr6x0zGFJ_i23jDmAK6ZaKKPdeZNM6l48eVB8dSyRb8ZgpiBsql8FiO1ml6NcyIpyw,,&typo=1>
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（杨锋）
_______________________________________________________________________________________________________________________
Tejas Networks Limited (Tejas Networks) is committed to safeguard your
privacy. Read the appropriate Privacy Notice
(https://www.tejasnetworks.com/privacy-notice) applicable to you to
know more about how Tejas Networks collects, uses and stores your
personal data. Please visit our Privacy Policy
(https://www.tejasnetworks.com/privacy-policy) available on our
website www.tejasnetworks.com for more information about our
commitment towards data privacy under applicable data protection laws.
This email may contain confidential or privileged information for the
intended recipient(s). If you are not the intended recipient, please
do not use or disseminate the information, notify the sender and
delete it from your system.
