On Fri, 16 Sep 2022, guoyang...@zgclab.edu.cn wrote:
Source Address Validation (SAV) is a problem that can be partially solved by using IPsec or other approaches. However, IPsec AH needs to hash the whole changeless fileds of the length-vairable packet and IPsec ESP needs to encrypt the whole packet. Therefore the AH or ESP are too costly and heavily to implement the source address validation. We design a new tech mechanism that uses RPKI and IPsec to solve the inter-domain SAV problem.
I am a bit confused why the source address needs to be cryptographically verified to make SAV based decisions. What would be the scenarios of inter AS communication where the packet is maliciously modified between the two ASes but in such a way that RPKI wouldn't already reject the packet with a bad src/dst ?
This new mechanism needs to define a new type of IPsec SA using together with RPKI to validate the inter-domain layer source address. As it only needs to choose a little fields to protect but not the whole packet, this will dramaticaly decrease the computation cost compared with the original IPsec AH or ESP. Thus it may be used globally in the Internet.
I am not convinced a modified IPsec AH is the best choice. A new protocol as this would be, would take quite some time to be widely supported. With IPsec, there are already two failures in this space, BEET (BTNS) and wrapped ESP (wESP). I know that the Linux IPsec maintainers are very conservative adding more complexity to the IPsec code. Additionally, AH works poorly over NAT. Would there be a chance that the two AS'es have to communicate via a NAT? The drafts keep mentioning the "significant performance" difference. Has there been any benchmarking / testing of this with real numbers? I guess I am not fully understanding how this fits into the model of the two ASes exchanging packets and how looking directly at those src/dst would not be good enough? Would there be an attacker on the switch connecting the two ASes ? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
