Hi, Apologies for not replying in time. There may be some deviations in our statements.
We design this mechanism for inter-domain Source Address Validation (SAV). Relying on RPKI alone cannot guarantee the authenticity of the source address in the packet, a data-plane mechanism like IPsec is needed to guarantee that the source address cannot be spoofed. The overhead of using IPsec directly among ASes on a large scale is unaffordable, so we design the extension mechanism of IPsec to meet the SAV requirements inter-domain. It could be more like site-to-site mode, but the `site` here is an Autonomous System (AS) range. The following figure is the overview of this mechanism as shown at draft-xu-risav-00. This would work at the ASBR（AS Border Router）other than the end host. As shown below, all the processes are taken place at the ACS which is a special host or just an ASBR. > +--------------+ > | IANA | > +--------------+ > |------------------------+ > V | > +--------------+ | > | RIR | | > +--------------+ | > / \-----------------+-1. signed CA > V V | certificate > +--------------+ +--------------+ | > | LIR1 | | LIR2 | | > +--------------+ +--------------+ | > / \-+ > V +------ 2. signed EE certificate -------+ V > +--------------+ | | +--------------+ > | | | -------------------------------- | | | > | | | 3. IKE negotiation | | | > | AS A | | -------------------------------- | | AS B | > | | V V | | > | ######## -------------------------------- ######## | > | ACS A # ASBR # 4. SA Deliver # ASBR # ACS B | > | ######## -------------------------------- ######## | > | | | Prefix Y | > | Prefix X | +++++++++++++++++++++++++++++++++ | Public Key B | > | Public Key A | 5. data transmission | | > | | using IPsec AH | | > | | +++++++++++++++++++++++++++++++++ | | > +--------------+ +--------------+ > > THIS FIG may be unfortunately displayed unformatted. You could get it from > fig1 > of draft-xu-risav at https://datatracker.ietf.org/doc/draft-xu-risav. > With what node does IKE negotiate? 1. The IKE negotiates between the ACS (AS Control Server) in every AS to ensure that the source address is not forged. The ACS may be an AS Border Router (ASBR) or a special server. > Where is the AH introduced? > In IPv4, whether we can introduce new headers is up for debate. > For IPv6, it is not. 2. We don't introduce a new header or a new protocl. We have designed and implemented this mechanism at the IPv6 range only with IPv6 destination extension header. You could refer to these links as follows. But we believe that using IPsec as a base can further reduce the complexity of the mechanism. The IPsec AH we use is a new one with a special SPI or special SPI prefix/suffix indicated and is used in transport mode. - https://datatracker.ietf.org/doc/draft-xu-savax-control/ - https://datatracker.ietf.org/doc/draft-xu-savax-data/ - https://datatracker.ietf.org/doc/draft-xu-savax-protocol/ > If we could asymmetrically sign every packet with a new AH protocol that used > an assymetric key, that would be awesome. I've wanted to do this forever, > but it's just not affordable. 3. If we negotiate asymmetric keys for each data stream and perform packet-by- packet encryption, the overhead of this operation is really unaffordable. Our design is to maintain cryptographic relationships at the AS level rather than at the host level, and we can use s/keys to reduce the number of negotiations, hoping that the above efforts will make the operational overhead affordable between AS pairs that are expected to have SAV capabilities. RFC 2289 A One-Time Password System https://www.rfc-editor.org/info/std61 RFC 1760 The S/KEY One-Time Password System https://www.rfc-editor.org/info/rfc1760 > What if we signed some small percentage (%0.01) of packets... would there be > some way this could be useful for SAV? 4. Source address validation at a certain percentage could be an open discussion, which would obviously provide better forwarding efficiency, although we are also concerned that lower availability may affect deployment incentives. > 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. 5. Indeed, making any adjustments to a mature and well-designed system will face many challenges. The only difference we did is to add a Prefix Length field and a SIG Length field to the AH header format. Also, this mechanism works at the ASBR, so there should be nothing change with the end host. This particular AH would be added at the source ASBR and removed at the destination ASBR. In addition, we believe that this mechanism can be turned off between ASes that do not require SAV. > Additionally, AH works poorly over NAT. Would there be a chance that > the two AS'es have to communicate via a NAT? 6. As this is designed for inter-domain layer SAV, it may not concern the NAT sceneries. > The drafts keep mentioning the "significant performance" difference. > Has there been any benchmarking / testing of this with real numbers? 7. We have conducted preliminary experiments on commercial routers that have 100Gbps common interfaces. We use native IPv6 with crc32 and the result shows that it could complete packet-by-packet hash with a Negligible increased latency and throughput loss. We would share further experimental instructions if required. > 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 ? 8. In the inter-domain SAV scenario, the traffic sent by one AS may forge the source address belonging to another AS, and when the destination AS receives the packet, it cannot judge whether the src in the packet is real or not, and we do not want something like this to happen from a security perspective. We need a mechanism to guarantee the destination AS has the ability to verify the authenticity of SRC from the data-plane, instead of directly believing the SRC shown in the current packet, thus making it impossible for the malicious AS to spoof the source address of other AS. Best regards, Yangfei Guo. ============================================================ From: Michael Richardson Date: 2022-09-19 22:17 To: Paul Wouters; ipsec CC: guoyang...@zgclab.edu.cn Subject: Re: [IPsec] FW: New Version Notification for draft-xu-erisav-00.txt and draft-xu-risav-00.txt Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
