On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Based upon conversations on the list, this proposal might not even > be IPsec. > > At least, it's not proto=50(ESP)/51(AH), as they are asking for a new > > extension header type. > Nit: RISAV in tunnel mode uses proto=50. Only transport mode requests a new protocol number. > > The proposal would require allocation of a SPI for a destination > address > > which is not the receiving system of the SA. > > It would be negotiated with IKEv2, but that part seems neither here > nor > > there. > > Ben, I asked on an (CDN) IX list if anyone supported >1500 byte packets. > Thanks! > Even if you have the slimest possible pseudo-AH header, it will take at > least > a dozen bytes for the authentication data, which means at least 1520 byte > packets or so. None of them support >1500. > That's fine. We don't need 1500+24 bytes. We just need 1280+24 bytes, (or 1280+73 in tunnel mode), so that the end-to-end MTU is IPv6-compliant. If you think we need 1500 bytes of end-to-end MTU, I would be interested to hear why. Now, private peering could certainly arrange 1600 byte packets, and I'll bet > that many IXs could be persuaded to up their port limits, but this is a > definite concern. > > ip-tfs lets you slice/dice packets so that they all fit into 1500, and > maybe > that would be a good option to consider. Different flows could have > different treatments, all arranged by IKEv2. > I think I roughly understand the IP-TFS idea. I think that IP-TFS would be preferable if it is easy to deploy, but I worry that it's not practical, for two reasons: 1. Scalability and efficiency. Compared to RISAV, IP-TFS would require * a much larger number of IKEv2 handshakes (one for each pair of communicating routers, vs. 1 for the whole AS pair) * a larger amount of connection state (to hold all the different SAs) * a much larger amount of IP buffer memory (for fragment reassembly) * a somewhat larger amount of MTU overhead 2. Routing interference and configuration RISAV-AH doesn't alter packet routing at all. The source and dest IPs are unchanged, so packets flow along exactly the same paths as they would without RISAV. RISAV in tunnel mode changes the destination IP to one IP for the whole receiving AS, but that IP can be anycast across all ASBRs, so routing should be similar to non-RISAV routing, and configuration is straightforward. IP-TFS requires each sending ASBR to pick a specific receiving ASBR. This creates a form of "source routing" that bypasses much of the usual BGP pathfinding. Recreating the baseline routing paths could be difficult or impossible, and might require O(N^2) active tunnels, for a pair of ASes with N ASBRs each. The simple RISAVAnnouncement that goes in the RPKI database would have to be replaced by a much larger configuration object that enumerates all the ASBRs and explains who should use which one. You mentioned earlier that this form of "source routing" might be desirable in some use cases. That's an intriguing idea, but I would like for ASes to be able to activate RISAV with a minimum of additional complexity, maintenance, and risk.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
