Re: [IPsec] FW: New Version Notification for draft-xu-erisav-00.txt and draft-xu-risav-00.txt
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
Re: [IPsec] FW: New Version Notification for draft-xu-erisav-00.txt and draft-xu-risav-00.txt
Paul Wouters wrote: > 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 ? I'm also confused by this proposal. But, imagine if you will, that the RPKI is unable to transitively address all of the transit points. There are a lot of corner cases that the SAV WG(s) have been unable to come to consensus about. I think that a lot of them work out to that many solutions only work if all operators conform to specific network topology patterns. But, if the originating AS is able to sign the packet in such a way that a receiving AS is able to verify the traffic came from the originating AS. This would definitely be a win, right? How would this be possible to do, well. There are ways that I can imagine it might be made to work, but it seems very difficult to do at speed, in practice. One thought is that I wonder if there is some value if one could only verify some small percentage of packets... with some consequence if the check fails such that we probablistically catch violators and put them into some ACL. > 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 wasn't it BEEP? BEEP is not really related to BTNS. BEEP mode is really related to HIP, but, yes, BTNS could benefit from it. wESP is, I agree, a total failure. > Additionally, AH works poorly over NAT. Would there be a chance that > the two AS'es have to communicate via a NAT? Probably not. BGP4 just doesn't do NAT44. but, if it were a problem... IPv6 would still benefit. If ASs can benefit from DDoS protection by agressively switching to IPv6, then that might be a win-win. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
