Hi Vasilenko, Sorry for getting back to you this late. Please see zzh> below.
Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang Sent: Tuesday, August 6, 2024 9:17 AM To: Vasilenko Eduard <vasilenko.eduard=40huawei....@dmarc.ietf.org> Subject: RE: The multicast necessity with a big enough scope for draft-zzhang-rtgwg-router-info Hi Vasilenko, Thanks for your comments and suggestions. I took some time off after IETF and am still catching up on emails. I will get back to you as soon as possible. Jeffrey From: Vasilenko Eduard <vasilenko.eduard=40huawei....@dmarc.ietf.org<mailto:vasilenko.eduard=40huawei....@dmarc.ietf.org>> Sent: Tuesday, July 30, 2024 5:22 AM To: draft-zzhang-rtgwg-router-i...@ietf.org<mailto:draft-zzhang-rtgwg-router-i...@ietf.org> Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> Subject: The multicast necessity with a big enough scope for draft-zzhang-rtgwg-router-info [External Email. Be cautious of content] Hi Authors, I see that you care about security - I see an authentication header in the proposed packet. The currently adopted way is to use hash. Hash MUST be slow by design (at least a few milliseconds, better tens) or else it would be easy to break it. If the hash is becoming fast (because of hardware improvement) - it must be replaced by a new algorithm that would become slow again (or else there would be no security). It is the reason why "packet design" had always measured hundreds of milliseconds for LSP propagation through small IGP (3-4 hops) because every control plane must calculate hash twice to check/sign routing update. If I understand the purpose of your draft - it is not tolerable to distribute the load information with a sub-second delay. It is what you may get for this protocol too. It is possible to use symmetric encryption (something like AES) instead of hash. It would greatly improve the latency (to tens of milliseconds), but it would not eliminate the control plane processing time per hop. As we remember a few milliseconds was a tough target for BFD implemented in the control plane. Hence, I believe that you have no choice except to use multi-hop multicast (normal multicast). Zzh> If I understand it correctly, you're saying that the authentication will slow down the processing and defeat the purpose of fast flooding, therefore multi-hop multicast has to be used. Zzh> Thanks for pointing out the issue with the authentication - very valuable information. Zzh> However, the intention of the flooding is *not* to distribute the information to every node in the network. It is only for one-hop flooding and no re-flooding is expected. Zzh> The draft does mention that remote unicast/multicast-based flooding can be used. That is still one "overlay" hop (e.g., flooding among PEs). I understand how scary is the proposition to develop multicast for DC, but looking at the target application - I believe you have no choice, you need to bypass the control plane of intermediate routers for message delivery. The update should go at the same time (through the data plane) for all routers in the domain. Zzh> In the simple case of DC underlay routing, we only need to flood the information on the local link, so this is not an issue. There are scenarios where multicast would be useful, and we do need to spell out security concerns and measures. Moreover, limiting the multicast scope on the network perimeter (filtering at "limited domain" is so much a trend), you may completely omit authentication - simplify the solution a little bit. Services are in overlay anyway - the untrusted traffic is isolated. Zzh> Indeed, this would be used in a walled garden so authentication may not be necessary. Zzh> Thanks! Zzh> Jeffrey Best Regards Eduard Vasilenko Senior Architect Network Algorithm Laboratory Tel: +7(985) 910-1105
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
